The OpenNET Project / Index page

[ новости /+++ | форум | теги | ]



Вариант для распечатки  
Пред. тема | След. тема 
Форум Разговоры, обсуждение новостей
Режим отображения отдельной подветви беседы [ Отслеживать ]

Оглавление

Один из разработчиков MySQL раскритиковал проект и рекомендовал использовать PostgreSQL, opennews (??), 06-Дек-21, (0) [смотреть все]

Сообщения [Сортировка по времени | RSS]


42. "Один из разработчиков MySQL раскритиковал проект и рекомендо..."  –3 +/
Сообщение от Ilya Indigo (ok), 06-Дек-21, 13:06 
Уделывает он только по физическому занимаемому месту для эквивалентных данных! (жрёт гораздо больше)
А так в нём нет ни unsigned, не int1 и int3, и даже ALTER TABLE ... ADD ... AFTER ...; нету.
Альтернативных движков нету, и, возможно, сжатия табличного пр-ва единственного движка тоже нету!
Ох уж эти мамкины уделыватели по всем фронтам...
Ответить | Правка | К родителю #2 | Наверх | Cообщить модератору

56. "Один из разработчиков MySQL раскритиковал проект и рекомендо..."  –4 +/
Сообщение от Наме (?), 06-Дек-21, 13:34 
> Уделывает он только по физическому занимаемому месту для эквивалентных данных! (жрёт гораздо
> больше)
> А так в нём нет ни unsigned, не int1 и int3, и
> даже ALTER TABLE ... ADD ... AFTER ...; нету.
> Альтернативных движков нету, и, возможно, сжатия табличного пр-ва единственного движка
> тоже нету!
> Ох уж эти мамкины уделыватели по всем фронтам...

Ильюшинька, Слон реляционный MVCC (честная реализация всех уровней изоляции транзакций), а Дельфин по умолчанию ISAM (транзакций и WAL-а нет, но бывают задачи где это всё лишняя нагрузка). Это как ткацкий станок сравнивать с вязальными спицами -- каждый хорош для своих задач.

Ответить | Правка | Наверх | Cообщить модератору

62. "Один из разработчиков MySQL раскритиковал проект и рекомендо..."  –2 +/
Сообщение от Ilya Indigo (ok), 06-Дек-21, 13:50 
> Ильюшинька, Слон реляционный MVCC (честная реализация всех уровней изоляции транзакций),

Вы не поверите, InnoDB тоже!
> а Дельфин по умолчанию ISAM

MySQL уже более 10-ти лет по умолчанию InnoDB использует, а там где нужна быстрая вставка можно и MyISAM использовать в той же самой БД!

Ответить | Правка | Наверх | Cообщить модератору

65. "Один из разработчиков MySQL раскритиковал проект и рекомендо..."  –2 +/
Сообщение от Наме (?), 06-Дек-21, 14:01 
>> Ильюшинька, Слон реляционный MVCC (честная реализация всех уровней изоляции транзакций),
> Вы не поверите, InnoDB тоже!
>> а Дельфин по умолчанию ISAM
> MySQL уже более 10-ти лет по умолчанию InnoDB использует, а там где
> нужна быстрая вставка можно и MyISAM использовать в той же самой
> БД!

Это под вендой. Но Инно тоже Слону не конкурент. Совершенно разного масштаба явления.

Ответить | Правка | Наверх | Cообщить модератору

70. "Один из разработчиков MySQL раскритиковал проект и рекомендо..."  +1 +/
Сообщение от funny.falcon (?), 06-Дек-21, 14:22 
Это вы зря. Сам InnoDB довольно продвинут. Но это лишь слой хранения.
Ответить | Правка | Наверх | Cообщить модератору

76. "Один из разработчиков MySQL раскритиковал проект и рекомендо..."  –1 +/
Сообщение от Ilya Indigo (ok), 06-Дек-21, 14:33 
> Это вы зря. Сам InnoDB довольно продвинут. Но это лишь слой хранения.

Да уже по первому комментарию и так понятно что аноним совершенно не понимает о чём пишет, а когда его аргументы мною разбиты пишет снова глупость, не понятно зачем вообще упоминая оффтопик, и просит просто поверить ему.

Ответить | Правка | Наверх | Cообщить модератору

93. "Один из разработчиков MySQL раскритиковал проект и рекомендо..."  –11 +/
Сообщение от Наме (?), 06-Дек-21, 15:57 
Ильюша, ты пишешь на пэхэпэ. Эти всё сказано о твоим интеллектуальных способностях и общей профессиональной эрудии.

Ответить | Правка | Наверх | Cообщить модератору

166. "Один из разработчиков MySQL раскритиковал проект и рекомендо..."  –1 +/
Сообщение от Аноньимъ (ok), 07-Дек-21, 03:00 
Мамин илитарий, угомонись.
ПХП программисты ничем не хуже сишников и сипипишников.
Специалисты и профаны есть везде.
Ответить | Правка | Наверх | Cообщить модератору

167. "Один из разработчиков MySQL раскритиковал проект и..."  +/
Сообщение от arisu (ok), 07-Дек-21, 03:06 
> ПХП программисты ничем не хуже сишников и сипипишников.

ну да, почти как люди: две руки, две ноги, две задницы… в одну они едят.

Ответить | Правка | Наверх | Cообщить модератору

186. "Один из разработчиков MySQL раскритиковал проект и рекомендо..."  –1 +/
Сообщение от Наме (?), 07-Дек-21, 10:42 
> Мамин илитарий, угомонись.
> ПХП программисты ничем не хуже сишников и сипипишников.
> Специалисты и профаны есть везде.

Я о том, что пэхэпёр вряд ли в свой профессиональной жизни плотно сталкивается с потрохами разных СУБД. Ему это просто не надо.

Ответить | Правка | К родителю #166 | Наверх | Cообщить модератору

85. "Один из разработчиков MySQL раскритиковал проект и рекомендо..."  +4 +/
Сообщение от vitalif (ok), 06-Дек-21, 15:18 
Под какой виндой, что ты несёшь?

Никто уже нигде лет 15 не использует MyISAM. А InnoDB тоже MVCC, причём что важно - там нет грёбаного вакуума)

Ответить | Правка | К родителю #56 | Наверх | Cообщить модератору

94. "Один из разработчиков MySQL раскритиковал проект и рекомендо..."  –1 +/
Сообщение от Наме (?), 06-Дек-21, 15:59 
> Под какой виндой, что ты несёшь?
> Никто уже нигде лет 15 не использует MyISAM. А InnoDB тоже MVCC,
> причём что важно - там нет грёбаного вакуума)

Практически везде. Просто в силу того, что ISAM для многих задач достаточен.

Ответить | Правка | Наверх | Cообщить модератору

95. "Один из разработчиков MySQL раскритиковал проект и рекомендо..."  +/
Сообщение от Наме (?), 06-Дек-21, 16:05 
> Под какой виндой, что ты несёшь?
> Никто уже нигде лет 15 не использует MyISAM. А InnoDB тоже MVCC,
> причём что важно - там нет грёбаного вакуума)

Ты можешь объяснить, чем "вакуум" хуже/лучше отдельных UNDO-сегментов или писанины в tempdb?

Ответить | Правка | К родителю #85 | Наверх | Cообщить модератору

185. "Один из разработчиков MySQL раскритиковал проект и рекомендо..."  –1 +/
Сообщение от _hide_ (ok), 07-Дек-21, 10:39 
> Ты можешь объяснить, чем "вакуум" хуже/лучше отдельных UNDO-сегментов или писанины в tempdb?

Это может сделать любой. Это хорошо отсутствием блокировок и гарантированной прозрачностью операций. Пишем в лог, читаем из данных и лога (причем все проблемы синхронизации и доступности решает движок БД, разве не классно?). Когда не Hello World, а 300 клиентов пишут/читают единовременно из одного набора данных, такие вопросы вызывают лишь улыбку.
И да ISAM-кие движки всегда были ReadOnly after write? Или были какие-то решения для обхода ограничений?


Ответить | Правка | Наверх | Cообщить модератору

187. "Один из разработчиков MySQL раскритиковал проект и рекомендо..."  +/
Сообщение от Наме (?), 07-Дек-21, 10:47 
> Это может сделать любой. Это хорошо отсутствием блокировок и гарантированной прозрачностью
> операций. Пишем в лог, читаем из данных и лога (причем все
> проблемы синхронизации и доступности решает движок БД, разве не классно?).

Каких ещё блокировок? Вот есть у тебя ряд реализаций MVCC, одна хранит историю в виде исходных строк в том же месте, где они были до удаления/изменения, другая пишет, условно, диффы в другое место, а на прежнем месте городит сложную структуру из цепных ссылок, третья делает что-то среднее между первым и вторым -- какие-то удалённые строки держит на прежнем месте, какие-то выносит в отдельную помойку, а какие-то изменения просто хранит в виде инструкций в журнале изменений. Какой способ лучше?

Ответить | Правка | Наверх | Cообщить модератору

194. "Один из разработчиков MySQL раскритиковал проект и рекомендо..."  +/
Сообщение от _hide_ (ok), 07-Дек-21, 11:06 
> Каких ещё блокировок?

Мы скоро обсуждать будем ассемблерные вставки? Кто это пишет дифы? Никто никаких дифов в набор данных не пишет (да и в логи пишутся отнють не дифы, а новые значение полей): либо переписывает измененный набор данных/релоцирует его и пишет заново, помечая старые данные как свободное место (MySQL), либо пишет весь блок отдельно и отмечает это в метазаписях как ожидающий вакуума (PG).
VACUUM блокирует часть данных при релокации. MySQL-у Optimize Table нужен как таковой, только при использовании запросов вне индекса (при сканировании), PG требует этого "для обслуживания".

> какие-то изменения просто хранит в виде инструкций в журнале изменений

Хранить инструкции в журнале? Что за бред, такое было когда-то в InnoDB, но уже давно всплыло, а если журнал будет повреждён? Конец атомарности, разрушены внешние ссылки и вообще ахтунг и ручное восстановление.

> Какой способ лучше?

Для пользователей и разработчик-прикладников, лучше именно гибридный способ с повторным использованием освободившегося места (и фрагментацией как проблемой), потому что это даёт серьезный прирост к скорости (путем нагрузки на CPU и контроллер, но не на IO), нежели полное копирование всех данных при обновлении.
Если брать разработчиков этих СУБД, то второй способ хорош тем, что его можно очень качественно отладить и оптимизировать, тем самым заняв нишу систем с низкой степенью отказа.

Ответить | Правка | Наверх | Cообщить модератору

199. "Один из разработчиков MySQL раскритиковал проект и рекомендо..."  +/
Сообщение от Наме (?), 07-Дек-21, 11:33 
Оракл, например, пишет "диффы" (образно выражаясь, там что-то вроде инструкций разностных). Но не всегда. Если у тебя строка огромная, а поменял ты в ней один символ, то могилить (как делает Слон и Инно тоже) её как-то не слишком рационально. Тогда пишется такой "дифф" и этим экономится и пространство хранение и оперативное.
Ответить | Правка | Наверх | Cообщить модератору

201. "Один из разработчиков MySQL раскритиковал проект и рекомендо..."  +/
Сообщение от _hide_ (ok), 07-Дек-21, 11:42 
> Оракл, например, пишет "диффы" (образно выражаясь, там что-то вроде инструкций разностных).
> Но не всегда. Если у тебя строка огромная, а поменял ты
> в ней один символ, то могилить (как делает Слон и Инно
> тоже) её как-то не слишком рационально. Тогда пишется такой "дифф" и
> этим экономится и пространство хранение и оперативное.

Это микрооптимизация поверх определенных типов данных, которая даёт существенный прирост на синтетике. С практической т.з., если запись изменилась, то перезапись выгоднее, как минимум, своей простотой, да и частая посимвольная замена в строке говорит о проблемах совсем другого рода при проектировании приложения.

ЗЫ Но да, прикольно, не знал про это

Ответить | Правка | Наверх | Cообщить модератору

103. "Один из разработчиков MySQL раскритиковал проект и рекомендо..."  +2 +/
Сообщение от Аноним (103), 06-Дек-21, 16:48 
Конечно-конечно, никакого вакуума. Только православный optimize table! Ну и что что это те же яйца даже не в профиль.
Ответить | Правка | К родителю #85 | Наверх | Cообщить модератору

109. "Один из разработчиков MySQL раскритиковал проект и рекомендо..."  +/
Сообщение от Наме (?), 06-Дек-21, 17:13 
> Конечно-конечно, никакого вакуума. Только православный optimize table! Ну и что что это
> те же яйца даже не в профиль.

Нет, это и близко не одни и те же "яйца". Одна чистит БД от призраков и освобождает счётчик транзакций (изменений), другая проводит пересортировку таблиц.

Ответить | Правка | Наверх | Cообщить модератору

188. "Один из разработчиков MySQL раскритиковал проект и рекомендо..."  +/
Сообщение от _hide_ (ok), 07-Дек-21, 10:48 
> другая проводит пересортировку таблиц.

Какую еще "пересортировку"? Из таблицы удаляются осиротевшие или невалидные данные (совсем не осиротевшие :-) ), а в освободившееся пространство (высокая скорость записи имеет свою цену и одна из них -- большое количество мертвых данных) заполняется сортированным для чтения набором данных и пересчитанными индексами (после релокейта деток, приходится и индексы пересчитывать)

> освобождает счётчик транзакций (изменений)

В том контексте, которые используется мной, такие действия выполняются при коммите транзакции (или перед остановкой БД, если за атомарность у нас отвечает бесперебойник)

Ответить | Правка | Наверх | Cообщить модератору

197. "Один из разработчиков MySQL раскритиковал проект и рекомендо..."  +/
Сообщение от Наме (?), 07-Дек-21, 11:30 
>> другая проводит пересортировку таблиц.
> Какую еще "пересортировку"? Из таблицы удаляются осиротевшие или невалидные данные (совсем
> не осиротевшие :-) ), а в освободившееся пространство (высокая скорость записи
> имеет свою цену и одна из них -- большое количество мертвых
> данных) заполняется сортированным для чтения набором данных и пересчитанными индексами
> (после релокейта деток, приходится и индексы пересчитывать)
>> освобождает счётчик транзакций (изменений)
> В том контексте, которые используется мной, такие действия выполняются при коммите транзакции
> (или перед остановкой БД, если за атомарность у нас отвечает бесперебойник)

Ты не в курсе. У Слона счётчик циркулярный, ещё и "меридианный". Уроборос этакий. Без вакуума он заканчивается и всё фризится.

Ну и чем тогда пурген отличается от вакуума(кроме чистки счётчика)? Риторический вопрос. В действительности, ни одна из реализаций не лучше другой. Это очередная Кока-кола против Пепси-колы.
И не коммите, а фиксации.

Ответить | Правка | Наверх | Cообщить модератору

192. "Один из разработчиков MySQL раскритиковал проект и рекомендо..."  +/
Сообщение от Аноним (192), 07-Дек-21, 10:56 
А вот это в корне не так, если говорить о б-жественном InnoDB. InnoDB не поддерживает OPTIMIZE напрямую, вместо этого все данные из таблицы копируются во временную таблицу, которая потом замещает оригинальную.
Ответить | Правка | К родителю #109 | Наверх | Cообщить модератору

136. "Один из разработчиков MySQL раскритиковал проект и рекомендо..."  +/
Сообщение от Онаним (?), 06-Дек-21, 20:58 
Если InnoDB не наполнять очень хитрым образом - необходимости в OPTIMIZE TABLE обычно не существует.
Ответить | Правка | К родителю #103 | Наверх | Cообщить модератору

189. "Один из разработчиков MySQL раскритиковал проект и рекомендо..."  +/
Сообщение от Аноним (192), 07-Дек-21, 10:49 
Точнее сказать - если не удалять из нее данные)
Ответить | Правка | Наверх | Cообщить модератору

190. "Один из разработчиков MySQL раскритиковал проект и рекомендо..."  –1 +/
Сообщение от Онаним (?), 07-Дек-21, 10:51 
Перепутали с постгрёй и вакуумом.
InnoDB - это не постгря, она умеет заполнять освобождённые страницы при добавлении данных.
Ответить | Правка | Наверх | Cообщить модератору

207. "Один из разработчиков MySQL раскритиковал проект и рекомендо..."  +/
Сообщение от Аноним (207), 07-Дек-21, 12:29 
Вообще-то умеет. но чтобы это узнать надо прочитать документацию.
Ответить | Правка | Наверх | Cообщить модератору

250. "Один из разработчиков MySQL раскритиковал проект и рекомендо..."  +/
Сообщение от www2 (??), 22-Дек-21, 07:30 
>Никто уже нигде лет 15 не использует MyISAM. А InnoDB тоже MVCC, причём что важно - там нет грёбаного вакуума)

А вакуум над ibdata1 не помешал бы. Полное резервное копирование с последующим восстановлением из резервной копии - так себе альтернатива для вакуума. Но тем, у кого полная резервная копия делается за полчаса, а перерыв в работе в несколько часов не особо критичен, MySQL пойдёт.

Ответить | Правка | К родителю #85 | Наверх | Cообщить модератору

122. "Один из разработчиков MySQL раскритиковал проект и рекомендо..."  +2 +/
Сообщение от Catwoolfii (ok), 06-Дек-21, 20:08 
У мускула определенно есть некоторые плюсы в сравнении со слоном, но только не язык запросов. Такой огрызок еще поискать надо...
Ответить | Правка | К родителю #42 | Наверх | Cообщить модератору

124. "Один из разработчиков MySQL раскритиковал проект и рекомендо..."  –2 +/
Сообщение от Ilya Indigo (ok), 06-Дек-21, 20:17 
> У мускула определенно есть некоторые плюсы в сравнении со слоном, но только
> не язык запросов. Такой огрызок еще поискать надо...

Я хоть от одного мамкиного слонёнка конкретику услышу с примерами и пруфами, или только один глупый и необоснованный детский бред!?

Ответить | Правка | Наверх | Cообщить модератору

182. "Один из разработчиков MySQL раскритиковал проект и рекомендо..."  +1 +/
Сообщение от fuggy (ok), 07-Дек-21, 10:28 
> нет ни unsigned, не int1 и int3

unsigned нет в SQL стандарте. int1 это для тех кто не умеет boolean. int3 вообще какая-то эзотерика, никому не нужная. smallint достаточно. Ну уж в количестве типов тягаться с PostgreSQL не стоит. Там есть array, intrange, daterange, xml, json, inet, геометрические типы. Даже банального uuid нет.

> ALTER TABLE ... ADD ... AFTER ...

В стандарте у колонок нету порядка. Да функция удобная, но без неё можно прожить.
Про CONSTRAINT CHECK ничего не хочешь сказать? Он как бы есть, но его нет.

И уж сравнивать по фичам MySQL не стоит. Подключаемые движки, это единственное что пока есть. Они хороши только для определённой нагрузки. Зато нет набора типов индексов, с помощью которых можно улучшить некоторые операции.

Ответить | Правка | К родителю #42 | Наверх | Cообщить модератору

191. "Один из разработчиков MySQL раскритиковал проект и рекомендо..."  +/
Сообщение от Онаним (?), 07-Дек-21, 10:53 
Зато есть отсутствие vacuum, которое автоматически улучшает куда больше, чем тот самый набор индексов. Кстати индексы по (даже не хранимым) вычисляемым полям в MariaDB давно можно делать, и поэтому ряд вещей таким способом и решается. Но соглашусь, маразм с отсутствием DESC индексов решён пока только в ванильной восьмёрке.
Ответить | Правка | Наверх | Cообщить модератору

216. "Один из разработчиков MySQL раскритиковал проект и рекомендо..."  +1 +/
Сообщение от fuggy (ok), 07-Дек-21, 14:26 
Вакуум это лишь отложенное амортизированное время операции на вставку/удаление, за счёт чего это операции эти операции выполняются быстро без необходимости копировать строки в REDO. То есть устаревшие версии строк хранятся в самой таблице и раздувают её, что конечно плохо. Вся лишь разница где хранятся старые версии строк и если вакуум выполняется регулярно, то будет лишь небольшой процент мёртвого места. Но вакуум выполняется в фоне и не занимает основной поток операций.

Функциональные индексы и PostgreSQL есть, недавно появились и покрывающие индексы, а кроме того там ещё есть полезные частичные индексы, что в разы уменьшает размер индекса. Частичные индексы позволяют проиндексировать только нужные значения для выборки, не включая оставшиеся ненужные строки. А что касается типов индексов, то кроме банального B-tree, есть и более интересные вроде BRIN, Bloom. Гео индексы тоже есть, но они не всем нужны.

Ответить | Правка | Наверх | Cообщить модератору

Архив | Удалить

Рекомендовать для помещения в FAQ | Индекс форумов | Темы | Пред. тема | След. тема




Партнёры:
PostgresPro
Inferno Solutions
Hosting by Hoster.ru
Хостинг:

Закладки на сайте
Проследить за страницей
Created 1996-2024 by Maxim Chirkov
Добавить, Поддержать, Вебмастеру