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

"Один из разработчиков MySQL раскритиковал проект и рекомендовал использовать PostgreSQL"	+/–
Сообщение от opennews (??), 06-Дек-21, 11:21
Штайнар Гундерсон (Steinar H. Gunderson), один из авторов библиотеки сжатия Snappy и участник разработки IPv6, объявил о возвращении в компанию Google, в которой в своё время занимался разработкой сервисов поиска по изображениям и offline-картами, но теперь будет вовлечён в разработку браузера Chrome. До этого Штайнар в течение пяти лет работал в Oracle над модернизацией оптимизатора СУБД MySQL. Заметка Штайнара примечательна критическим отношением к перспективам MySQL и рекомендацией переходить на PostgreSQL... Подробнее: https://www.opennet.dev/opennews/art.shtml?num=56287
Ответить | Правка | Cообщить модератору

Сообщения

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

1. "Один из разработчиков MySQL раскритиковал проект и рекомендо..."	–1 +/–
Сообщение от Аноним (1), 06-Дек-21, 11:21
всегда использовал слоника заместо вот этого вот детища оракула
Ответить | Правка | Наверх | Cообщить модератору

	4. "Один из разработчиков MySQL раскритиковал проект и рекомендо..."	+21 +/–
	Сообщение от _hide_ (ok), 06-Дек-21, 11:25
	>>> всегда использовал слоника Тот, кто так говорит, явно не мог его использовать 12+ лет назад. Значит использует лет 5 от силы, т.е. для проектов однодневок. Возможно в этом и причины их мимолетности. >>> детища оракула Ну это полностью подтверждает сказанное выше
	Ответить | Правка | Наверх | Cообщить модератору

	14. "Один из разработчиков MySQL раскритиковал проект и рекомендо..."	+9 +/–
	Сообщение от Аноним (1), 06-Дек-21, 11:51
	с 2011, мистер Холмс, сэр
	Ответить | Правка | Наверх | Cообщить модератору

	80. "Один из разработчиков MySQL раскритиковал проект и рекомендо..."	–5 +/–
	Сообщение от проект однодневка (?), 06-Дек-21, 14:49
	> для проектов однодневок Я аж в голос с этого клоуна!
	Ответить | Правка | К родителю #4 | Наверх | Cообщить модератору

	90. "Один из разработчиков MySQL раскритиковал проект и рекомендо..."	–5 +/–
	Сообщение от лютый жабби__ (?), 06-Дек-21, 15:31
	>Тот, кто так говорит, явно не мог его использовать 12+ лет назад бред, помню, даже в 2000-м году делал пару поделок на постгресе и уже тогда витало аналогичное мнение: слон медленнее мускуля только в кривых руках, а по фичам даже 21 года назад постгрес был лучше. хотя для 2021 оба мусор, тк монга рулит )
	Ответить | Правка | К родителю #4 | Наверх | Cообщить модератору

	106. "Один из разработчиков MySQL раскритиковал проект и рекомендо..."	+5 +/–
	Сообщение от _hide_ (ok), 06-Дек-21, 17:00
	> бред, помню, даже в 2000-м году делал пару поделок на постгресе и > уже тогда витало аналогичное мнение: слон медленнее мускуля только в кривых > руках, а по фичам даже 21 года назад постгрес был лучше. Всё зависит от того, чем Вы занимаетесь. При обновлении 10-15 ГБ с ПГ Вы упираетесь в IO и уже можете наращивать скорость только за линейно, у MySQL имеется возможность такие проблемы отсрочить. > хотя для 2021 оба мусор, тк монга рулит ) Вот всегда хотел спросить, сколько полезных проектов на Монге есть сейчас, старше 5-8 лет? Просто мой поиск мне даёт очень интересные результаты. Ну и википедия подсказывает, что Монга это... Ну в общем, не база данных, хотя может заменить некоторые простые её функции.
	Ответить | Правка | Наверх | Cообщить модератору

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

	174. "Один из разработчиков MySQL раскритиковал проект и рекомендо..."	+4 +/–
	Сообщение от _ (??), 07-Дек-21, 08:15
	Чат для котегафф!?
	Ответить | Правка | Наверх | Cообщить модератору

	165. "Один из разработчиков MySQL раскритиковал проект и рекомендо..."	+/–
	Сообщение от Аноньимъ (ok), 07-Дек-21, 02:49
	>слон медленнее мускуля только в кривых руках В переводе с опеннетского это видимо означает, что нужна команда высококлассных специалистов чтобы его базово настроить. Мускл же меня никогда не подводил и работал сразу из коробки.
	Ответить | Правка | К родителю #90 | Наверх | Cообщить модератору

	126. "Один из разработчиков MySQL раскритиковал проект и рекомендо..."	+/–
	Сообщение от michelle (??), 06-Дек-21, 20:40
	В 2004 делал проект биллинга провайдера на постгресе
	Ответить | Правка | К родителю #4 | Наверх | Cообщить модератору

	215. "Один из разработчиков MySQL раскритиковал проект и рекомендо..."	+1 +/–
	Сообщение от cadmi (?), 07-Дек-21, 13:46
	Когда Вадиму Михееву (работал в соседнем здании и был с ним знаком) в 1995 году понадобилось написать телефонный биллинг для МГТС в Красноярске, он написал половину тогдашнего постгреса :)
	Ответить | Правка | Наверх | Cообщить модератору

	157. "Один из разработчиков MySQL раскритиковал проект и рекомендо..."	+1 +/–
	Сообщение от Аноним (157), 06-Дек-21, 23:26
	Postgres сравнялся по скорости работы с MySQL на простых запросах где-то с 8-й версии. А в многопоточке он всегда работал быстрее (гугл и другие крупные конторы делали свои патчи, чтобы у них MySQL не тормозил на параллельных запросах, эти патчи потом вошли и в Машку и в Перкону). Была даже статья с названием типа "Нет больше медленных слонов" (только я ее не нашел). Произошло это больше 12-ти лет назад. До этого Postgres с его транзакционностью был медленнее MySQL с его MyISAM без какой либо атомарности. IMHO чуть ли не единственная причина, почему MySQL не закапали еще лет 10 назад - WordPress работает только с ним и армия php'шников использовала преимущественно MySQL. А так как веб разработка есть почти в любом проекте и эта сфера довольно большая - то MySQL до сих пор широко распространен (в средней конторе админу проще поддерживать одну базу - MySQL, чем две MySQL для веба и Postgres для остального). Кроме того, Postgres нужно настраивать, чтобы он работал быстро, а в MySQL с этим попроще. Еще в MySQL раньше были менее жесткие требования к соблюдению синтаксиса запросов (Posqtgres настолько кривые запросы вообще не выполнял, а MySQL позволял довольно широкие отклонения). Щас с России по статистике Posqtgres занимает нишу больше, чем MySQL. У буржуинов противоположная ситуация.
	Ответить | Правка | К родителю #4 | Наверх | Cообщить модератору

	158. "Один из разработчиков MySQL раскритиковал проект и рекомендо..."	+/–
	Сообщение от YetAnotherOnanym (ok), 06-Дек-21, 23:36
	> армия php'шников использовала преимущественно MySQL > в MySQL раньше были менее жесткие требования к соблюдению синтаксиса запросов Чувствуется какая-то связь между этими наблюдениями...
	Ответить | Правка | Наверх | Cообщить модератору

	161. "Один из разработчиков MySQL раскритиковал проект и рекомендо..."	+1 +/–
	Сообщение от _hide_ (ok), 07-Дек-21, 00:32
	> Postgres сравнялся по скорости работы с MySQL на простых запросах где-то с > 8-й версии. Это Вы про скороть чтения на одинаковом железе или сравниваете корпоративный сервер от именитых поставщиков с шаред хостингами? > А в многопоточке он всегда работал быстрее (гугл и > другие крупные конторы делали свои патчи, чтобы у них MySQL не > тормозил на параллельных запросах, эти патчи потом вошли и в Машку > и в Перкону). Вы про что опять? У MySQL всегда была большая проблема с планировщиком, а многопточность -- это требование от больших дядь на чтение во время записи, которое не имеет ничего общего с реальной многопоточностью при выборке данных (её как таковой нет ни в Мускуле, ни в ПГ) > Была даже статья с названием типа "Нет больше > медленных слонов" (только я ее не нашел). Произошло это больше 12-ти > лет назад. До этого Postgres с его транзакционностью был медленнее MySQL > с его MyISAM без какой либо атомарности. Да, что-то вспоминаю, сравнивали MyISAM и PG? Сейчас это очень своевременно и да, не имеет никакого отношения к скорости, ПГ НИКОГДА НЕ СРАВНИТСЯ ПО СКОРОСТИ, просто это стоит намного дороже в плане проектирования (планировщик у него работает почти идеально, но Вы же не можете гарантировать наличие индексов всегда? Вот и упретесь в то, что если железка не может хранить все индексы в памяти и с ними играться, то ни о каком сравнении с MySQL-ом речи быть не может). И опять же, на ПГ только искать? Для этого есть совсем другие решения, а при записи он посасывает. > IMHO чуть ли не единственная причина, почему MySQL не закапали еще лет > 10 назад - WordPress работает только с ним и армия php'шников > использовала преимущественно MySQL. А так как веб разработка есть почти в > любом проекте и эта сфера довольно большая - то MySQL до > сих пор широко распространен (в средней конторе админу проще поддерживать одну > базу - MySQL, чем две MySQL для веба и Postgres для > остального). Кроме того, Postgres нужно настраивать, чтобы он работал быстро, а > в MySQL с этим попроще. Еще в MySQL раньше были менее > жесткие требования к соблюдению синтаксиса запросов (Posqtgres настолько кривые запросы > вообще не выполнял, а MySQL позволял довольно широкие отклонения). Очень субъективно, но, на мой взгляд, тут не синтаксис сыграл свое (а он местами просто уг), а то, что на 64МБ оперативки он вполне себя живенько чувствовал. > Щас с России по статистике Posqtgres занимает нишу больше, чем MySQL. У > буржуинов противоположная ситуация. Он занимает нишу Оракла, а сайтовая ниша для MySQL-а у нас просто намного меньше.
	Ответить | Правка | К родителю #157 | Наверх | Cообщить модератору

	180. "Один из разработчиков MySQL раскритиковал проект и рекомендо..."	+/–
	Сообщение от моррут (?), 07-Дек-21, 09:44
	>Еще в MySQL раньше были менее жесткие требования к соблюдению синтаксиса запросов (Posqtgres настолько кривые запросы вообще не выполнял, а MySQL позволял довольно широкие отклонения). при этом вполне синтаксически корректные конструкции в запросе MySQL  вполне может сожрать без каких-либо замечаний, но ничего при этом не сделать.
	Ответить | Правка | К родителю #157 | Наверх | Cообщить модератору

	228. "Один из разработчиков MySQL раскритиковал проект и рекомендо..."	+/–
	Сообщение от Анонимус314 (?), 08-Дек-21, 21:58
	Вот откуда берется это про "нужно настраивать"? Там все основные настройки в конфиге откомментированы и интуитивно понятны, насколько помню (2 года настройкой СУБД не занимался).
	Ответить | Правка | К родителю #157 | Наверх | Cообщить модератору

	222. "Один из разработчиков MySQL раскритиковал проект и рекомендо..."	+/–
	Сообщение от анон ессно (?), 07-Дек-21, 15:54
	С Postgre95.
	Ответить | Правка | К родителю #4 | Наверх | Cообщить модератору

	232. "Один из разработчиков MySQL раскритиковал проект и рекомендо..."	+/–
	Сообщение от Аноним (232), 09-Дек-21, 05:30
	Postgres95
	Ответить | Правка | Наверх | Cообщить модератору

	18. "Один из разработчиков MySQL раскритиковал проект и рекомендо..."	+1 +/–
	Сообщение от Ян Злобин (ok), 06-Дек-21, 11:57
	>  всегда использовал слоника заместо вот этого вот детища оракула Ничего вы, батенька, не понимаете в залепухах для прачечных!
	Ответить | Правка | К родителю #1 | Наверх | Cообщить модератору

	51. "Один из разработчиков MySQL раскритиковал проект и рекомендо..."	+9 +/–
	Сообщение от Аноним (51), 06-Дек-21, 13:25
	Зелёного?
	Ответить | Правка | К родителю #1 | Наверх | Cообщить модератору

	117. "Один из разработчиков MySQL раскритиковал проект и рекомендо..."	+11 +/–
	Сообщение от Аноним (117), 06-Дек-21, 19:14
	> детища оракула Вот и выросло поколение... Хоть википедию бы почитали бы
	Ответить | Правка | К родителю #1 | Наверх | Cообщить модератору

2. "Один из разработчиков MySQL раскритиковал проект и рекомендо..."	+7 +/–
Сообщение от AleksK (ok), 06-Дек-21, 11:22
Вот кстати тоже не понимаю зачем нужен MySQL если есть Postgres, который уделывает его по всем параметрам.
Ответить | Правка | Наверх | Cообщить модератору

	5. "Один из разработчиков MySQL раскритиковал проект и рекомендо..."	+7 +/–
	Сообщение от _hide_ (ok), 06-Дек-21, 11:27
	>>> уделывает его По каким параметрам? >>> по всем А мне казалось, что применение PG -- это очень взвешенное и обоснованное решение.
	Ответить | Правка | Наверх | Cообщить модератору

	6. "Один из разработчиков MySQL раскритиковал проект и рекомендо..."	+8 +/–
	Сообщение от funny.falcon (?), 06-Дек-21, 11:30
	Не по всем. Я, как любитель PostgreSQL, ответственно заявляю. Причины, по которым Uber возвращался с PostgreSQL на MySQL, в основном ещё актуальны.
	Ответить | Правка | К родителю #2 | Наверх | Cообщить модератору

	11. "Один из разработчиков MySQL раскритиковал проект и рекомендо..."	–3 +/–
	Сообщение от AleksK (ok), 06-Дек-21, 11:40
	> Причины, по которым Uber возвращался с PostgreSQL на MySQL, в основном ещё > актуальны. Если они изначально делали все под MySQL, то не удивительно. А так по моему опыту использования Postgres и MySQL с рельсами, Postgres даже на глаз быстрее работает.
	Ответить | Правка | Наверх | Cообщить модератору

	17. "Один из разработчиков MySQL раскритиковал проект и рекомендо..."	+/–
	Сообщение от Gemorroj (ok), 06-Дек-21, 11:55
	миграция на более новые версии у mysql на порядок проще. мультимастер (galera в mysql). некоторый синтаксический сахар (работа с enum, например).
	Ответить | Правка | Наверх | Cообщить модератору

	21. "Один из разработчиков MySQL раскритиковал проект и рекомендо..."	–9 +/–
	Сообщение от AleksK (ok), 06-Дек-21, 12:02
	Когда работаешь с ORM вообще пофиг.
	Ответить | Правка | Наверх | Cообщить модератору

	22. "Один из разработчиков MySQL раскритиковал проект и рекомендо..."	+2 +/–
	Сообщение от x3who (?), 06-Дек-21, 12:06
	ORM там вообще перпендикулярен к тем проблемам, о которых вам говорят.
	Ответить | Правка | Наверх | Cообщить модератору

	23. "Один из разработчиков MySQL раскритиковал проект и рекомендо..."	–8 +/–
	Сообщение от AleksK (ok), 06-Дек-21, 12:13
	> ORM там вообще перпендикулярен к тем проблемам, о которых вам говорят. Вот именно, я работаю со своей объектной моделью, мне пофиг на то что там происходит под капотом. Но с Posgtres для меня все работает быстрее, и админить его ИМХО проще и удобнее.
	Ответить | Правка | Наверх | Cообщить модератору

	137. "Один из разработчиков MySQL раскритиковал проект и рекомендо..."	–1 +/–
	Сообщение от Онаним (?), 06-Дек-21, 21:00
	Понятно. Упёрся в кривую ORM, свалил всё на RDBMS.
	Ответить | Правка | Наверх | Cообщить модератору

	153. "Один из разработчиков MySQL раскритиковал проект и рекомендо..."	–2 +/–
	Сообщение от AleksK (ok), 06-Дек-21, 23:07
	> Понятно. Упёрся в кривую ORM, свалил всё на RDBMS. Понятное дело если бы ты её писал то она бы летала и была бы сделана идеально. Эх жаль мир потерял такого специалиста.
	Ответить | Правка | Наверх | Cообщить модератору

	154. "Один из разработчиков MySQL раскритиковал проект и рекомендо..."	–1 +/–
	Сообщение от Онаним (?), 06-Дек-21, 23:15
	Не переживай, не потерял.
	Ответить | Правка | Наверх | Cообщить модератору

	26. "Один из разработчиков MySQL раскритиковал проект и рекомендо..."	+1 +/–
	Сообщение от keydon (ok), 06-Дек-21, 12:19
	Когда работаешь с patroni - тоже
	Ответить | Правка | К родителю #21 | Наверх | Cообщить модератору

	40. "Один из разработчиков MySQL раскритиковал проект и рекомендо..."	+/–
	Сообщение от Аноним (40), 06-Дек-21, 12:55
	>более новые версии а есть менее новые? Ну или хотя бы более лучшие.
	Ответить | Правка | К родителю #17 | Наверх | Cообщить модератору

	47. "Один из разработчиков MySQL раскритиковал проект и рекомендо..."	–1 +/–
	Сообщение от Ilya Indigo (ok), 06-Дек-21, 13:15
	> (работа с enum, например). enum в постгресе одна из немногих вещей которая мне понравилась. В MariaDB я его никогда не использую, так как есть более эффективный tinyint unsigned, а соответствия можно в php массивом в константе класса сохранить. Но в посгресе нет ни tinyint ни unsigned но можно определить 1 раз enum и вставлять его в 2 и более таблицы, а если нужно модифицировать то делается это 1 раз.
	Ответить | Правка | К родителю #17 | Наверх | Cообщить модератору

	204. "Один из разработчиков MySQL раскритиковал проект и рекомендо..."	+/–
	Сообщение от Аноним (204), 07-Дек-21, 11:57
	>> Причины, по которым Uber возвращался с PostgreSQL на MySQL, в основном ещё >> актуальны. >Если они изначально делали все под MySQL, то не удивительно. А так по моему опыту использования >Postgres и MySQL с рельсами, Postgres даже на глаз быстрее работает. Я мог конечно не так понять, но вроде обоснования были такие. Там вроде одна из проблем была - массированные обновления строк. У постгреса с этим не очень хорошо (по крайней мере было, как сейчас - не знаю), тормозил нещадно по сравнению с мускулем. Поясню. У других БД (оракл, мускуль...) строка обновляется на том же месте, где валяется (in-place), т.е. ее физическое положение в блоках не меняется, кроме редких случаев. А постгря вместо редактирования старой строки тупо добавляет измененнную новую. Вроде должно быть даже быстрее, типа некий аналог Copy-on-write. Проблемы возникают, когда на таблицу навешаны индексы. Индекс - упорядоченная последовательность значений, где с каждой строчкой индекса хранится ссылка на исходную строку в таблице, в каких блоках она находится по каким смещениям. В оракле-мускуле, если в строке обновляются поля, не входящие в индекс, индекс не редактируется (адрес строки в таблице не поменялся). А вот в постгре даже при обновлении не-индексных полей надо каждый раз искать в индексе и обновлять на адрес новой, обновленной строки - там уже другой адрес, уже в других блоках ошивается строка, т.е в индексе хранится фигня, надо исправить. Т.е. представь, в таблице у тебя один-два-три индекса, для поисков, а ты 24/7 массированно меняешь поля, не входящие в индекс - и совершается куча лишней (в сравнении с мускулем) работы по обновлению индексов, да еще и куча мусора остается в виде старых исключенных строк, которые какой-нибудь автовакуум подобрать должен, периодически внося свои тормоза и задержки.
	Ответить | Правка | К родителю #11 | Наверх | Cообщить модератору

	249. "Один из разработчиков MySQL раскритиковал проект и рекомендо..."	+/–
	Сообщение от www2 (??), 22-Дек-21, 07:25
	В MySQL можно одновременно читать одну и ту же запись, а читать и обновлять - нет. Набегающие толпы читающих клиентов могут надолго заблокировать запись для обновления. А в PostgreSQL каждый читающий клиент будет читать эту запись внутри своей транзакции, а в рамках другой транзакции эта запись будет обновлена, так что следующие читающие клиенты начнут новые транзакции и прочитают уже обновлённую запись. https://ru.wikipedia.org/wiki/PostgreSQL#%D0%9C�...) В общем, для сайтиков, где данные обновляются не так часто, а чаще читаются, MySQL, наверное, подойдёт лучше. Если же данные чаще обновляются, чем читаются, то PostgreSQL подойдёт лучше.
	Ответить | Правка | Наверх | Cообщить модератору

	253. "Один из разработчиков MySQL раскритиковал проект и рекомендо..."	+/–
	Сообщение от Всем Анонимам Аноним (?), 28-Янв-22, 15:03
	Вы, наверное, про MyISAM? В MySQL разные движки.
	Ответить | Правка | Наверх | Cообщить модератору

	34. "Один из разработчиков MySQL раскритиковал проект и рекомендо..."	+/–
	Сообщение от Cykooz (ok), 06-Дек-21, 12:27
	Насколько помню они вернулись не в совсем обычный MySQL, а в какую-то свою кастомизацию, с помощью которой они из MySQL сделали Key-Value базу данных. Вероятно тогда это было легче сделать в MySQL, т.к. там есть поддержка разных движков для хранения данных. В Postgres она появилась только недавно. Поэтому не совсем корректно говорить, что они вернулись именно в MySQL, т.к. они фактически перешли на совершенно другой тип базы данных.
	Ответить | Правка | К родителю #6 | Наверх | Cообщить модератору

	69. "Один из разработчиков MySQL раскритиковал проект и рекомендо..."	+/–
	Сообщение от funny.falcon (?), 06-Дек-21, 14:19
	Нет. Key-value у них - это слой абстракции сверху, а не движок.
	Ответить | Правка | Наверх | Cообщить модератору

	77. "Один из разработчиков MySQL раскритиковал проект и рекомендо..."	+/–
	Сообщение от Cykooz (ok), 06-Дек-21, 14:35
	> Нет. Key-value у них - это слой абстракции сверху, а не движок. А, ну да. Но тем не менее они сделали "костыль" поверх MySQL, т.к. именно его движок хорошо показал себя с этим "костылём". С тем же успехом они могли взять готовую Key-Value базу, если бы была в тот момент подходящая под требования. Поэтому не очень корректно приводить пример Uber-а, т.к. они MySQL использовали довольно специфично. Примерно как сравнивать Postgres с Redis.
	Ответить | Правка | Наверх | Cообщить модератору

	121. "Один из разработчиков MySQL раскритиковал проект и рекомендо..."	+2 +/–
	Сообщение от Catwoolfii (ok), 06-Дек-21, 20:05
	В текущей версии postgres половина названных проблем уже не актуальна.
	Ответить | Правка | К родителю #6 | Наверх | Cообщить модератору

	147. "Один из разработчиков MySQL раскритиковал проект и..."	+/–
	Сообщение от arisu (ok), 06-Дек-21, 21:53
	> Причины, по которым Uber возвращался с PostgreSQL на MySQL, в основном ещё > актуальны. так причина «мы не хотим платить специалистам, поэтому наберём макак по объявлениям» всегда будет актуальна.
	Ответить | Правка | К родителю #6 | Наверх | Cообщить модератору

	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ообщить модератору

	87. "Один из разработчиков MySQL раскритиковал проект и рекомендо..."	+/–
	Сообщение от minonA (?), 06-Дек-21, 15:27
	Так, на вскидку, а есть ли в PostgreSQL аналог MEMORY таблицы? Вообще проблема оптимизатора MySQL преувеличена. Да, в Postgres он умнее. Но и в MySQL можно добиться схожих результатов немного подкрутив. А если говорить о простых запросах, что наиболее частый юзер-кейс, MySQL вообще ничем не хуже.
	Ответить | Правка | К родителю #2 | Наверх | Cообщить модератору

	102. "Один из разработчиков MySQL раскритиковал проект и рекомендо..."	–1 +/–
	Сообщение от AleksK (ok), 06-Дек-21, 16:45
	Я сужу по тому как работал мой проект на рельсах. Загрузка базы в проект из yaml ну просто в разы быстрее при использовании postgres, да и отзывчивость в общем получше. Я не проводил специальных тестов просто общие впечатления от работы на одном и на другом.
	Ответить | Правка | Наверх | Cообщить модератору

	135. "Один из разработчиков MySQL раскритиковал проект и рекомендо..."	+3 +/–
	Сообщение от Онаним (?), 06-Дек-21, 20:57
	Ну, на рельсах можно и постгрю, хуже уже не будет.
	Ответить | Правка | Наверх | Cообщить модератору

	116. "Один из разработчиков MySQL раскритиковал проект и рекомендо..."	–1 +/–
	Сообщение от А где же каменты (?), 06-Дек-21, 18:56
	Постгрес нравится, но девелопер похож на обиженку- видимо чего-то недодали.
	Ответить | Правка | К родителю #2 | Наверх | Cообщить модератору

3. "Один из разработчиков MySQL раскритиковал проект и рекомендо..."	+4 +/–
Сообщение от Аноним (3), 06-Дек-21, 11:22
> рекомендовал использовать PostgreSQL дак я уже
Ответить | Правка | Наверх | Cообщить модератору

	44. "Один из разработчиков MySQL раскритиковал проект и рекомендо..."	+1 +/–
	Сообщение от Аноним (44), 06-Дек-21, 13:11
	А я никогда мускуль и не использовал.
	Ответить | Правка | Наверх | Cообщить модератору

	234. "Один из разработчиков MySQL раскритиковал проект и рекомендо..."	+1 +/–
	Сообщение от Аноним (234), 09-Дек-21, 06:46
	А я его еще больше ку. (c)
	Ответить | Правка | Наверх | Cообщить модератору

8. "Один из разработчиков MySQL раскритиковал проект и рекомендо..."	+7 +/–
Сообщение от Перастерос (ok), 06-Дек-21, 11:35
Сейчас будет холивар? Я за Postgres! )
Ответить | Правка | Наверх | Cообщить модератору

	24. "Один из разработчиков MySQL раскритиковал проект и рекомендо..."	+1 +/–
	Сообщение от Аноним (1), 06-Дек-21, 12:13
	так вы женщина??
	Ответить | Правка | Наверх | Cообщить модератору

	54. "Один из разработчиков MySQL раскритиковал проект и рекомендо..."	+1 +/–
	Сообщение от Аноним (-), 06-Дек-21, 13:31
	у тащмайора спроси, тут поди процентов 80
	Ответить | Правка | Наверх | Cообщить модератору

	168. "Один из разработчиков MySQL раскритиковал проект и рекомендо..."	+2 +/–
	Сообщение от Анончик (?), 07-Дек-21, 03:57
	тут пока одни капитаны
	Ответить | Правка | Наверх | Cообщить модератору

10. "Один из разработчиков MySQL раскритиковал проект и рекомендо..."	–13 +/–
Сообщение от flexagoon (ok), 06-Дек-21, 11:40
> MySQL сильно устарел и не эффективен, при том, что большинство пользователей и разработчиков считают, что всё в порядке, не утруждая себя сравнением с другими СУБД, которые давно ушли вперёд Они тут слово "My" нечаянно перед "SQL" добавили
Ответить | Правка | Наверх | Cообщить модератору

	169. "Один из разработчиков MySQL раскритиковал проект и рекомендо..."	–1 +/–
	Сообщение от Прохожий (??), 07-Дек-21, 05:36
	И какая альтернатива, о великий эксперт?
	Ответить | Правка | Наверх | Cообщить модератору

	223. "Один из разработчиков MySQL раскритиковал проект и рекомендо..."	–1 +/–
	Сообщение от flexagoon (ok), 08-Дек-21, 11:36
	Да любые NoSQL БД
	Ответить | Правка | Наверх | Cообщить модератору

	251. "Один из разработчиков MySQL раскритиковал проект и рекомендо..."	+/–
	Сообщение от www2 (??), 22-Дек-21, 07:42
	На SQL по крайней мере стандарт есть и даже те, кто его не придерживается, изображают что-то более-менее одно и то же. Оптимизатор SQL-запросов способен учитывать статистику данных в таблицах, наличие индексов по нужным полям и налету может изменить порядок соединения таблиц. При изменении данных в базе SQL проверяются ограничения, ссылочная целостность. В SQL есть полноценные транзакции с возможностью откатиться до промежуточной контрольной точки. А вот на NoSQL никаких стандартов нет, каждый выдумывает что-то своё. И похоже всё это на закат солнца вручную.
	Ответить | Правка | Наверх | Cообщить модератору

	254. "Один из разработчиков MySQL раскритиковал проект и рекомендо..."	+/–
	Сообщение от Всем Анонимам Аноним (?), 28-Янв-22, 15:06
	Все зависит от цели. Когда много данных и нужна скорость, но целостность - не проблема, то почему бы нет. Хотя я согласен, Гугл даже строит новую базу себе типа SQL, называется Spanner. Вначале думали да, все проблемы можно возложить на код, но потом пришли к выводу, что проще чтобы база данных этим все-таки занималась.
	Ответить | Правка | Наверх | Cообщить модератору

12. "Один из разработчиков MySQL раскритиковал проект и рекомендо..."	–17 +/–
Сообщение от Аноним (12), 06-Дек-21, 11:42
Использовал и то и другое, особой разницы не заметил. Для малых и средних сайтов MySQL - идеальное решение, поскольку там лучше дока и больше туторов. А высоконагруженный сайт postgress со всеми своими "продвинутыми" алгоритмами и оптимизациями банально не потянет.
Ответить | Правка | Наверх | Cообщить модератору

	15. "Один из разработчиков MySQL раскритиковал проект и рекомендо..."	+5 +/–
	Сообщение от Аноним (15), 06-Дек-21, 11:52
	Рукожоп.
	Ответить | Правка | Наверх | Cообщить модератору

	16. "Один из разработчиков MySQL раскритиковал проект и рекомендо..."	+6 +/–
	Сообщение от Аноним (16), 06-Дек-21, 11:55
	Не знаю чем там сильно отличаются туториалы для малых и средних сайтов, так как для малых и средних сайтов база всё равно считается детской по структуре. А вот для более серьёзных проектов (веб/десктоп, АРМ, и тд) всё таки более гибкая в проектировании PostgreSQL я считаю. Логику делать очень удобно. И как раз таки нормальная дока по нему в целом.
	Ответить | Правка | К родителю #12 | Наверх | Cообщить модератору

	33. "Один из разработчиков MySQL раскритиковал проект и рекомендо..."	+/–
	Сообщение от Аноним (33), 06-Дек-21, 12:26
	Вывод ты делаешь малые и средние сайты. Больше из твоего комментария нечего почерпнуть.
	Ответить | Правка | К родителю #12 | Наверх | Cообщить модератору

	148. "Один из разработчиков MySQL раскритиковал проект и..."	+2 +/–
	Сообщение от arisu (ok), 06-Дек-21, 21:58
	> А высоконагруженный сайт postgress со всеми своими "продвинутыми" алгоритмами > и оптимизациями банально не потянет. потянет и это. просто надо применить Секретную Оптимизацию: выгнать на мороз тебя и тебе подобных «специалистов».
	Ответить | Правка | К родителю #12 | Наверх | Cообщить модератору

13. "Один из разработчиков MySQL раскритиковал проект и рекомендо..."	+3 +/–
Сообщение от Аноним (-), 06-Дек-21, 11:48
Ну всё, мария не торт, мускуль не торт, постгрес не торт, и раст нас не спасёт, потому что там тоже все paзocpaлиcь.
Ответить | Правка | Наверх | Cообщить модератору

	29. "Один из разработчиков MySQL раскритиковал проект и рекомендо..."	+3 +/–
	Сообщение от Rev (?), 06-Дек-21, 12:21
	> там тоже все paзocpaлиcь Кто "все"? Модераторы CoC? Ах, увольте...
	Ответить | Правка | Наверх | Cообщить модератору

	81. "Один из разработчиков MySQL раскритиковал проект и рекомендо..."	+2 +/–
	Сообщение от topin89 (ok), 06-Дек-21, 14:51
	Если бы всё было так просто. Один из ключевых разработчиков забросил Rust Wasm, но активно отказывался передавать управление другим ключевым разработчикам после множества просьб. Пользуясь полномочиями ключевого разраба, он активно банил неугодных порой без причин. Да и сам оказался в составе core team, потому что знакомый протащил. До этого работал в npm, где пытался турнуть некоего Рода Вагга, но не прокатило, и турнули его самого. Добавим к этому активную SJW-позицию на всё про всё. Высказывание "убить всех мужиков" и было причиной для бана, вот только у модера нет прав банить. Модераторский состав, с другой стороны, состоит преимущественно из прикладников на rust. В частности, инициатором бойкота выступил не непонятный SJW'шник, а автор ripgrep. Разработчика зовут Эшли Уильямс, подробности тут: https://news.ycombinator.com/item?id=28515306 Так что всё гораздо хуже, чем SJW-модеров уволили. Они там уже в составе разрабов. Грустно, надеюсь, таки турнут эту Эшли.
	Ответить | Правка | Наверх | Cообщить модератору

	113. "Один из разработчиков MySQL раскритиковал проект и рекомендо..."	+/–
	Сообщение от Kuromi (ok), 06-Дек-21, 17:56
	Отличная ссылочка. Читается на одном дыхании как один большой анекдот. Только это все реальность. Хотя если честно я не понимаю что мешает Rust Core Team обратиться к админам гитхаба и попросить передать им права, в конце концов речь идет не о группе анонимов из даркнета, а официально существующей организации.
	Ответить | Правка | Наверх | Cообщить модератору

	31. "Один из разработчиков MySQL раскритиковал проект и рекомендо..."	+1 +/–
	Сообщение от Аноним (33), 06-Дек-21, 12:25
	Всегда остаётся Хаскель!
	Ответить | Правка | К родителю #13 | Наверх | Cообщить модератору

	41. "Один из разработчиков MySQL раскритиковал проект и рекомендо..."	–2 +/–
	Сообщение от Аноним (41), 06-Дек-21, 12:57
	Вся надежда на Монго
	Ответить | Правка | К родителю #13 | Наверх | Cообщить модератору

	53. "Один из разработчиков MySQL раскритиковал проект и рекомендо..."	+2 +/–
	Сообщение от Аноним (-), 06-Дек-21, 13:30
	..умерла в далеком 11м году
	Ответить | Правка | Наверх | Cообщить модератору

	73. "Один из разработчиков MySQL раскритиковал проект и рекомендо..."	–1 +/–
	Сообщение от funny.falcon (?), 06-Дек-21, 14:28
	Очень зря. MongoDB вполне себе надёжная и удобная в эксплуатации база в наши дни. Я имею в виду эксплуатацию с точки зрения администрирования. Правда, консистентный бэкап шардированного кластера сделали платной фичей. Его можно повторить руками, но минимум несколько месяцев интенсивной разработки обойдётся. Но у кого он вообще есть - бесплатный консистентный бэкап шардированного кластера? Знаю, у TiDB. У кого ещё?
	Ответить | Правка | Наверх | Cообщить модератору

	92. "Один из разработчиков MySQL раскритиковал проект и рекомендо..."	–1 +/–
	Сообщение от лютый жабби__ (?), 06-Дек-21, 15:54
	>Правда, консистентный бэкап шардированного кластера сделали платной фичей первая же ссылка https://github.com/Percona-Lab/mongodb_consistent_backup сам не использовал
	Ответить | Правка | Наверх | Cообщить модератору

19. "Один из разработчиков MySQL раскритиковал проект и рекомендо..."	+/–
Сообщение от Простоник (ok), 06-Дек-21, 11:58
MySQL всегда был игрушкой для небольших сайтов. Для определённого масштаба вполне подходит.
Ответить | Правка | Наверх | Cообщить модератору

	30. "Один из разработчиков MySQL раскритиковал проект и рекомендо..."	+3 +/–
	Сообщение от Аноним (33), 06-Дек-21, 12:24
	Ты ведь сейчас вордпресс имел ввиде и что УГ, да? И правильно сделал.
	Ответить | Правка | Наверх | Cообщить модератору

	38. "Один из разработчиков MySQL раскритиковал проект и рекомендо..."	–4 +/–
	Сообщение от Простоник (ok), 06-Дек-21, 12:39
	(Зевая) Я не знаю что там хранит вордпресс и в каком виде, но хранить в подобной базе большое количество таблиц особенно со сложной структурой и сложными запросами я бы не стал. А так пяток таблиц для блога подойдёт.
	Ответить | Правка | Наверх | Cообщить модератору

	115. "Один из разработчиков MySQL раскритиковал проект и рекомендо..."	+3 +/–
	Сообщение от mamba (?), 06-Дек-21, 18:44
	Alibaba так не считает https://www.youtube.com/watch?v=4Yhn2Zq3mHA
	Ответить | Правка | К родителю #19 | Наверх | Cообщить модератору

	171. "Один из разработчиков MySQL раскритиковал проект и рекомендо..."	+/–
	Сообщение от ddd2 (?), 07-Дек-21, 06:36
	у них свое ответвление MySQL с 2008-2009 года. Там от родного MySQL только названия.
	Ответить | Правка | Наверх | Cообщить модератору

	172. "Один из разработчиков MySQL раскритиковал проект и рекомендо..."	+/–
	Сообщение от Простоник (ok), 07-Дек-21, 07:44
	Админ у них просто героический. Для hi load эта штука не имеет необходимых механизмов. Амбразуры, похоже, приходится закрывать собственным  телом(пристройкой сарайчиков и землянок).
	Ответить | Правка | Наверх | Cообщить модератору

	175. "Один из разработчиков MySQL раскритиковал проект и рекомендо..."	–2 +/–
	Сообщение от funny.falcon (?), 07-Дек-21, 08:28
	Думаю, их «сарайчики и землянки» больше походят на Форд-Нокс
	Ответить | Правка | Наверх | Cообщить модератору

	219. "Один из разработчиков MySQL раскритиковал проект и рекомендо..."	+2 +/–
	Сообщение от Аноним (219), 07-Дек-21, 15:08
	это чо за тачка?
	Ответить | Правка | Наверх | Cообщить модератору

	134. "Один из разработчиков MySQL раскритиковал проект и рекомендо..."	–2 +/–
	Сообщение от Онаним (?), 06-Дек-21, 20:56
	Ну вот то есть мои полтерабайта биллинговой информации - это небольшой сайт. Окей.
	Ответить | Правка | К родителю #19 | Наверх | Cообщить модератору

	149. "Один из разработчиков MySQL раскритиковал проект и..."	+3 +/–
	Сообщение от arisu (ok), 06-Дек-21, 22:01
	> Ну вот то есть мои полтерабайта биллинговой информации - это небольшой сайт. > Окей. вообще-то так и есть. но ты этого всё равно не поймёшь, что очевидно по глупости твоего комментария.
	Ответить | Правка | Наверх | Cообщить модератору

	224. "Один из разработчиков MySQL раскритиковал проект и рекомендо..."	+/–
	Сообщение от anonymous (??), 08-Дек-21, 12:23
	> MySQL всегда был игрушкой для небольших сайтов. Для определённого масштаба вполне подходит. Небольших сайтов вроде FB.com и pinterest
	Ответить | Правка | К родителю #19 | Наверх | Cообщить модератору

20. "Один из разработчиков MySQL раскритиковал проект и рекомендо..."	+5 +/–
Сообщение от kai3341 (ok), 06-Дек-21, 12:00
Блин. InnoDB интересен своей ораклиной структурой данных -- кластерный первичный ключ. Реализация MVCC не гадит себе под ноги, необходимость богомерзкого autovacuum отсутствует. Когда БД корректно остановлена, она не содержит мусора. InnoDB -- это топовый OLTP движок Претензии есть. Реализация fulltext очень грустная, не поддерживает партиционирования. То есть если вы индексируете, например, новости, которые есть временной ряд -- поиск с указанием временных рамок будет крайне грустненьким PS: У постгреса другие сильные стороны. Например, бесплатный rollback
Ответить | Правка | Наверх | Cообщить модератору

	57. "Один из разработчиков MySQL раскритиковал проект и рекомендо..."	+/–
	Сообщение от Ilya Indigo (ok), 06-Дек-21, 13:34
	> Реализация fulltext очень грустная Ну так если нужно нормальный, то для этого Sphinx есть. А то что есть это просто что бы было кому лень со сфинксом заморачиваться.
	Ответить | Правка | Наверх | Cообщить модератору

	58. "Один из разработчиков MySQL раскритиковал проект и рекомендо..."	+1 +/–
	Сообщение от Наме (?), 06-Дек-21, 13:46
	> Блин. InnoDB интересен своей ораклиной структурой данных -- кластерный первичный ключ. > Реализация MVCC не гадит себе под ноги, необходимость богомерзкого autovacuum отсутствует. > Когда БД корректно остановлена, она не содержит мусора. InnoDB -- это > топовый OLTP движок > Претензии есть. Реализация fulltext очень грустная, не поддерживает партиционирования. > То есть если вы индексируете, например, новости, которые есть временной ряд > -- поиск с указанием временных рамок будет крайне грустненьким > PS: У постгреса другие сильные стороны. Например, бесплатный rollback Попутал ты всё. Какой "кластерный первичный ключ"? Это в МС Сиквеле типично отношение реализуют "кластерным индексом", в Оракле типично куча, хотя с 12-той версии появилась возможность реализовывать индексно-организованными таблицами (но редко кто так делает). Какая разница куда "гадим" MVCC? Когда нет необходимости каждый раз плодить UNDO-данные и таскать их из одного ТП в другое это банально быстрее, но больше места жрёт в локальной перспективе времени. Тут уж надо выбирать, что ценнее пространство или время ЦП и память. В чём богомерзкость вакуума? При адекватной настройке всё просто работает. Проблемы возникают, когда в одном кластере много БД и в них сильно разные по длительности транзакции -- 31-однобитного счётчика банально начинает не хватать. Ну так это нужно учитывать при развёртывании. Инно хорошая академическая лабораторная работа, к проду не пригодная по ряду причин, вроде того, что вектор UNDO не попадает в WAL, что при краше приводит к развалу БД.
	Ответить | Правка | К родителю #20 | Наверх | Cообщить модератору

	75. "Один из разработчиков MySQL раскритиковал проект и рекомендо..."	+/–
	Сообщение от funny.falcon (?), 06-Дек-21, 14:31
	А можно ссылочки на развал БД при краше?
	Ответить | Правка | Наверх | Cообщить модератору

	96. "Один из разработчиков MySQL раскритиковал проект и рекомендо..."	–2 +/–
	Сообщение от Наме (?), 06-Дек-21, 16:10
	> А можно ссылочки на развал БД при краше? Разверни. Запусти длительную транзакцию, не завершая её выруби питание. Т.к. данные UNDO скорее всего в полном объёме не попадут в журнал, то при обратном проигрывании при восстановлении получить несогласованную БД. Тут должны, конечно, звёзды сойтись. Чтобы грязные блоки уже попали на диск, но при этом вектор UNDO ещё нет. Но во "взрослых" СУБД это принципиально невозможно, а в Инно вполне под рабочей нагрузкой. Хотя это практически, объективно говоря, маловероятно, но при случае проблем при восстановлении добавит.
	Ответить | Правка | Наверх | Cообщить модератору

	119. "Один из разработчиков MySQL раскритиковал проект и рекомендо..."	+/–
	Сообщение от nik (??), 06-Дек-21, 19:57
	че за бред ?? -- все изменения в данных и в том же UNDO сохраняются в REDO, и пофиг длинная там транзакция или короткая, при сбросе питания все откатится до последнего COMMIT, а то что "не успело" -- вернется в пред. состояние из UNDO.
	Ответить | Правка | Наверх | Cообщить модератору

	141. "Один из разработчиков MySQL раскритиковал проект и рекомендо..."	+/–
	Сообщение от Мимо_проходил (?), 06-Дек-21, 21:09
	> че за бред ?? -- все изменения в данных и в том > же UNDO сохраняются в REDO, и пофиг длинная там транзакция или > короткая, при сбросе питания все откатится до последнего COMMIT, а то > что "не успело" -- вернется в пред. состояние из UNDO. Нет, это не так. Возможны состояния, когда UNDO не оказалось в REDO, а изменённые блоки уже на диске.
	Ответить | Правка | Наверх | Cообщить модератору

	133. "Один из разработчиков MySQL раскритиковал проект и рекомендо..."	+/–
	Сообщение от Онаним (?), 06-Дек-21, 20:55
	Бред. Ну или эксплуатация на системе, не умеющей в write barrier - там что угодно развалится, не только InnoDB.
	Ответить | Правка | К родителю #96 | Наверх | Cообщить модератору

	139. "Один из разработчиков MySQL раскритиковал проект и рекомендо..."	+/–
	Сообщение от Мимо_проходил (?), 06-Дек-21, 21:07
	> Бред. > Ну или эксплуатация на системе, не умеющей в write barrier - там > что угодно развалится, не только InnoDB. Словья-то какие воспроизводим. Ещё бы знали, что это значит )))) Write barrier тут вообще не причём. Причём тут то, что Inno не обеспечивает WAL для UNDO. Вот и всё. Сделано это из соображений, да, скорости. И, в общем, имеет право на жизнь.
	Ответить | Правка | Наверх | Cообщить модератору

	140. "Один из разработчиков MySQL раскритиковал проект и рекомендо..."	+/–
	Сообщение от Онаним (?), 06-Дек-21, 21:08
	Короче я не знаю, как ты умудрился InnoDB развалить - у меня за долгие годы не получилось.
	Ответить | Правка | Наверх | Cообщить модератору

	195. "Один из разработчиков MySQL раскритиковал проект и рекомендо..."	+/–
	Сообщение от 1 (??), 07-Дек-21, 11:21
	У тебя просто не было длинных транзакций ... А так разваливается и при резком выключении питания (гасится ИБП) так и при нехватке свободного места ... гасится мониторингом. А так ... Ну что спорить-то какой нож лучше ?
	Ответить | Правка | Наверх | Cообщить модератору

	220. "Один из разработчиков MySQL раскритиковал проект и рекомендо..."	+/–
	Сообщение от Онаним (?), 07-Дек-21, 15:28
	Ну короче да, смысла спорить нет - я хз как вы умудряетесь InnoDB развалить, видимо руки должны быть правильно заточены.
	Ответить | Правка | Наверх | Cообщить модератору

	142. "Один из разработчиков MySQL раскритиковал проект и рекомендо..."	+/–
	Сообщение от Онаним (?), 06-Дек-21, 21:10
	И что значит при чём тут WB. Когда двиг выставляет fsync()/fdatasync()/sync_file_range(), он ожидает, что на диске к моменту завершения будет всё, что он отписал, и заказал. Если WB нет - с энной вероятностью хрен оно будет на диске вовремя, и рандомное выключение приведёт к интересному.
	Ответить | Правка | К родителю #139 | Наверх | Cообщить модератору

	143. "Один из разработчиков MySQL раскритиковал проект и рекомендо..."	+/–
	Сообщение от Онаним (?), 06-Дек-21, 21:20
	Ну и да, какой WAL для UNDO вы вообще собрались писать, если к моменту коммита в REDO данные только в REDO. Далее его флашим в таблицу как придётся, когда по нагрузке посвободнее например, даже если что-то отвалится, делаем рефлаш. Двойная нагрузка на флаш, ещё и с чтением из REDO, если из буфера вылетело, выйдет только когда REDO заполнен. Это две разные парадигмы - либо пишем в REDO и флашим в таблицу потом, либо сразу пишем в таблицу и далее начинаются пляски с UNDO: мы либо переносим, и тогда получаем двойную нагрузку в момент транзакции, либо как в постгресном, пишем CoW'ом, и тогда надо вакуумить. Если у нас UNDO есть, REDO уже не нужен.
	Ответить | Правка | К родителю #139 | Наверх | Cообщить модератору

	144. "Один из разработчиков MySQL раскритиковал проект и рекомендо..."	+/–
	Сообщение от Онаним (?), 06-Дек-21, 21:26
	Могу ещё подсказать как без WB редо развалить. Всё не просто, а очень просто: мы флашим редо, выставляем синк на таблицу, выставляем синк на поинтеры редо. Если таблица на диск не попала, а поинтеры внезапно попали - имеем лютый 3.14ц, в таблице старые данные, в редо уже ничего. С андо попроще, с андо корова конечно решает, но зато корову вакуумить надо регулярно.
	Ответить | Правка | К родителю #139 | Наверх | Cообщить модератору

	155. "Один из разработчиков MySQL раскритиковал проект и рекомендо..."	+/–
	Сообщение от Онаним (?), 06-Дек-21, 23:18
	Похоже как раз на частичный коммит REDO в отсутствии WB.
	Ответить | Правка | К родителю #96 | Наверх | Cообщить модератору

	156. "Один из разработчиков MySQL раскритиковал проект и рекомендо..."	+/–
	Сообщение от Онаним (?), 06-Дек-21, 23:18
	Ну или fsync кто-то бездумно выключил xD
	Ответить | Правка | К родителю #96 | Наверх | Cообщить модератору

	86. "Один из разработчиков MySQL раскритиковал проект и рекомендо..."	–1 +/–
	Сообщение от penetrator (?), 06-Дек-21, 15:24
	в MSSQL некластерный первичный индекс (если речь не про Azure) появился очень очень давно (задолго до появления самого Azure)
	Ответить | Правка | К родителю #58 | Наверх | Cообщить модератору

	98. "Один из разработчиков MySQL раскритиковал проект и рекомендо..."	–1 +/–
	Сообщение от Наме (?), 06-Дек-21, 16:12
	> в MSSQL некластерный первичный индекс (если речь не про Azure) появился очень > очень давно (задолго до появления самого Azure) Не некластерный, а кластерный. Кластерней некуда. Но это всё словоблудие майковское.
	Ответить | Правка | Наверх | Cообщить модератору

	101. "Один из разработчиков MySQL раскритиковал проект и рекомендо..."	–1 +/–
	Сообщение от penetrator (?), 06-Дек-21, 16:45
	>> в MSSQL некластерный первичный индекс (если речь не про Azure) появился очень >> очень давно (задолго до появления самого Azure) > Не некластерный, а кластерный. Кластерней некуда. Но это всё словоблудие майковское. некластерный, heap или как хочешь еще, и он там есть и есть очень давно PK в MSSQL может быть 2 типов с пробуждением
	Ответить | Правка | Наверх | Cообщить модератору

	105. "Один из разработчиков MySQL раскритиковал проект и рекомендо..."	–1 +/–
	Сообщение от Наме (?), 06-Дек-21, 16:59
	>>> в MSSQL некластерный первичный индекс (если речь не про Azure) появился очень >>> очень давно (задолго до появления самого Azure) >> Не некластерный, а кластерный. Кластерней некуда. Но это всё словоблудие майковское. > некластерный, heap или как хочешь еще, и он там есть и есть > очень давно > PK в MSSQL может быть 2 типов > с пробуждением Heap это, пардон, куча. Т.е. когда данные хранятся вообще вне всякой упорядоченной структуры, а просто страницы в цепочку выделяются по IAM. В Сибэйсе хренелион лет назад решили, что коль уникальный индекс практически всегда создаётся, то логично в структуре этого индекса хранить и все прочие данные, которые не входят в индексный ключ, а не отдельно кучу и отдельно би-три с листами с индексным ключом. Ну и сделали такою смесь верблюда с носорогом -- сверху служебные структуры би-три, а на листах все данные. Ну вот, эту хрень и назвали кластерным индексом. В принципе, логичное решение, но проблема в том, что одного индекса в типичных условиях никогда не бывает достаточно, а хранение всех данных в структуре какого-то одного индекса зачастую приводит к смещению статистик распределения со всеми печальными последствиями. Поэтому тот же Оракл такого не делал. Я уж не помню, когда они ввели что-то подобное, по-моему, с 12-той версии. В Слоне тоже такого не было.
	Ответить | Правка | Наверх | Cообщить модератору

	152. "Один из разработчиков MySQL раскритиковал проект и рекомендо..."	+/–
	Сообщение от penetrator (?), 06-Дек-21, 22:53
	https://www.red-gate.com/simple-talk/databases/sql-server/t-.../ Heaps are tables without a clustered index. Я вообще не собирался лезть в детали, я про то что в MSSQL ЕСТЬ КУЧИ. Это онли про "Это в МС Сиквеле типично отношение реализуют "кластерным индексом", в Оракле типично куча" Куча вполне себе возможна, доступна и используется в MSSQL. Это то, что я имел ввиду. Куча возможна если нет ниодного кластерного индекса, которым обычно и является первичный ключ (первый и часто единственный кандидат). Никакие нюансы терминологии меня в душе не ебали в тот момент. Я только вернул кучи назад в MSSQL Server! С этим же все согласны? Ну вот и отлично.
	Ответить | Правка | Наверх | Cообщить модератору

	202. "Один из разработчиков MySQL раскритиковал проект и рекомендо..."	+/–
	Сообщение от Наме (?), 07-Дек-21, 11:43
	Не серчай. Вокруг этой темы перебор всякой терминологии. У многих в результате каша. Я просто попытался немного ситуацию прояснить. Так что, PK (первичный ключ) это Ограничение и оно НИКОГДА не реализуется кучей. Реализуется "кластерным" (исходная куча тю-тю, если была) или доп. (некластерным) индексом (доп. в смысле дополнительным к исходной куче, которая в этом случае никуда не девается, просто по данным этой кучи строится В-древо, которое эти данные структурирует, что и упрощает с одной стороны поиск, с другой -- создаёт основу для реализации условия уникальности).
	Ответить | Правка | Наверх | Cообщить модератору

	107. "Один из разработчиков MySQL раскритиковал проект и рекомендо..."	–1 +/–
	Сообщение от Наме (?), 06-Дек-21, 17:01
	> PK в MSSQL может быть 2 типов Как бы, PK это не индекс, а Constrain -- ограничение первичного ключа. Который реализуется, под капотом, созданием уникального кластерного уже Индекса, если явно не заказать создавать не кластерный индекс, а дополнительный.
	Ответить | Правка | К родителю #101 | Наверх | Cообщить модератору

	108. "Один из разработчиков MySQL раскритиковал проект и рекомендо..."	–1 +/–
	Сообщение от Наме (?), 06-Дек-21, 17:07
	> некластерный, heap или как хочешь еще, и он там есть и есть > очень давно > PK в MSSQL может быть 2 типов Маленький бесплатный ликбез. В МС Сиквеле данные отношения могут хранится либо в куче, либо в би-три, организованном по значению уникального ключа (сортировки). PK же (Primary Key) это одно из видов Ограничений, которое реализуется либо тем, что все данные отношения помещаются в структуру индекса, либо тем, что создаётся куча, а куче создаётся би-три-структура доп. индекса, в которой на листах хранятся данные индексного ключа и ссылки на страницы кучи, где хранится оригинальная индексируемая строка.
	Ответить | Правка | К родителю #101 | Наверх | Cообщить модератору

	110. "Один из разработчиков MySQL раскритиковал проект и рекомендо..."	+/–
	Сообщение от Наме (?), 06-Дек-21, 17:18
	> Маленький бесплатный ликбез. В МС Сиквеле данные отношения могут хранится либо в > куче, либо в би-три, организованном по значению уникального ключа (сортировки). PK > же (Primary Key) это одно из видов Ограничений, которое реализуется либо > тем, что все данные отношения помещаются в структуру индекса, либо тем, > что создаётся куча, а куче создаётся би-три-структура доп. индекса, в которой > на листах хранятся данные индексного ключа и ссылки на страницы кучи, > где хранится оригинальная индексируемая строка. Хотя, малыши, я тут несколько ошибся. Когда заказываешь PK к существующему уже отношению, в котором есть данные, то данные из кучи перемещаются в это би-три, а исходная куча удаляется, если же заказать PK при создании отношения, то и не будет создаваться, а сразу будет создано би-три, в который данные отношения и будут писаться. Если же создать PK и явно указать, что ограничение должно реализоваться доп. индексом, то будет к куче создан доп. индекс в виде би-три. Вот и всё.
	Ответить | Правка | Наверх | Cообщить модератору

	159. "Один из разработчиков MySQL раскритиковал проект и рекомендо..."	+1 +/–
	Сообщение от kai3341 (ok), 06-Дек-21, 23:42
	> Попутал ты всё. Какой "кластерный первичный ключ"? https://dev.mysql.com/doc/refman/8.0/en/innodb-index-types.html Each InnoDB table has a special index called the clustered index that stores row data. Typically, the clustered index is synonymous with the primary key. Не попутал.
	Ответить | Правка | К родителю #58 | Наверх | Cообщить модератору

	206. "Один из разработчиков MySQL раскритиковал проект и рекомендо..."	+/–
	Сообщение от Наме (?), 07-Дек-21, 12:15
	>> Попутал ты всё. Какой "кластерный первичный ключ"? > https://dev.mysql.com/doc/refman/8.0/en/innodb-index-types.html > Each InnoDB table has a special index called the clustered index that > stores row data. Typically, the clustered index is synonymous with the > primary key. > Не попутал. Кластерный индекс это... хм... индекс. А Первичный ключ это... ограничение. Просто в силу того, что в МС Сиквеле (и в Инно) зачастую разраб при определении отношения сразу пишет требование ограничения PK (причём, по умолчанию оно реализуется именно кластерным индексом), то ему и невдомёк, что Ограничение и Индекс это не одно и тоже. Совсем.
	Ответить | Правка | Наверх | Cообщить модератору

	210. "Один из разработчиков MySQL раскритиковал проект и рекомендо..."	+/–
	Сообщение от kai3341 (ok), 07-Дек-21, 13:12
	> Each InnoDB table has a special index called the clustered index Я настоятельно рекомендую использовать терминологию официальной документации, а не вашу собственную
	Ответить | Правка | Наверх | Cообщить модератору

	211. "Один из разработчиков MySQL раскритиковал проект и рекомендо..."	+/–
	Сообщение от Наме (?), 07-Дек-21, 13:35
	Читать умеешь? clustered index это кластерный индекс (структура данных такая). Primary key это constraint (инструкция такая). Разницу между Constraint и Index способен уловить? Нет? Это типично. Дальше и написано, что коль практически всегда PK реализуется с использование кластерного индекса, то их можно использовать как синонимы. Так вот, нельзя. Это не синонимы и близко. Кластерный индекс можно создать и не создавая ограничения PK. Как и ограничение PK можно реализовать некластерным доп. индексом.
	Ответить | Правка | Наверх | Cообщить модератору

	212. "Один из разработчиков MySQL раскритиковал проект и рекомендо..."	+/–
	Сообщение от Наме (?), 07-Дек-21, 13:35
	Читать умеешь? clustered index это кластерный индекс (структура данных такая). Primary key это constraint (инструкция такая). Разницу между Constraint и Index способен уловить? Нет? Это типично. Дальше и написано, что коль практически всегда PK реализуется с использование кластерного индекса, то их можно использовать как синонимы. Так вот, нельзя. Это не синонимы и близко. Кластерный индекс можно создать и не создавая ограничения PK. Как и ограничение PK можно реализовать некластерным доп. индексом.
	Ответить | Правка | К родителю #210 | Наверх | Cообщить модератору

	235. "Один из разработчиков MySQL раскритиковал проект и рекомендо..."	+/–
	Сообщение от Онаним (?), 10-Дек-21, 09:19
	У пользователей MSSQL проблемы с тем, что они умудряются мешать индексы с констрейнтами, при этом их механически разделяя :D
	Ответить | Правка | К родителю #210 | Наверх | Cообщить модератору

	64. "Один из разработчиков MySQL раскритиковал проект и рекомендо..."	+/–
	Сообщение от Аноним (64), 06-Дек-21, 13:58
	> необходимость богомерзкого autovacuum отсутствует. Документация с тобой не согласна: https://dev.mysql.com/doc/refman/8.0/en/optimize-table.html
	Ответить | Правка | К родителю #20 | Наверх | Cообщить модератору

	184. "Один из разработчиков MySQL раскритиковал проект и рекомендо..."	+/–
	Сообщение от kai3341 (ok), 07-Дек-21, 10:38
	> Документация с тобой не согласна: https://dev.mysql.com/doc/refman/8.0/en/optimize-table.html Ознакомьтесь с документацией. Между optimize table и autovacuum есть огромная разница. Начиная с того, что optimize table -- это опция, которую можно не запускать никогда, а вот autovacuum отключать очень не рекомендуется Ещё раз -- это разница между демоном, который в норме должен работать постоянно, и опцией, которую можно годами не запускать
	Ответить | Правка | Наверх | Cообщить модератору

	233. "Один из разработчиков MySQL раскритиковал проект и рекомендо..."	+/–
	Сообщение от Аноним (232), 09-Дек-21, 05:40
	Зависит от типа нагрузки, с одной без optimize table у вас диск переполнится, а с другой можно и автоваккум отключить.
	Ответить | Правка | Наверх | Cообщить модератору

	236. "Один из разработчиков MySQL раскритиковал проект и рекомендо..."	+/–
	Сообщение от Онаним (?), 10-Дек-21, 09:21
	Каким образом "переполнится диск" без optimize table, если innodb прекрасно умеет писать данные в освободившиеся страницы, не потрудитесь объяснить? Нет, есть там пара очень специфичных случаев, но вы их вряд ли приведёте, с ними мало кто сталкивается.
	Ответить | Правка | Наверх | Cообщить модератору

	68. "Один из разработчиков MySQL раскритиковал проект и рекомендо..."	+1 +/–
	Сообщение от Аноним (68), 06-Дек-21, 14:18
	> необходимость богомерзкого autovacuum отсутствует Богомерзкое - это писать логи. А автовакуум это красота.
	Ответить | Правка | К родителю #20 | Наверх | Cообщить модератору

	237. "Один из разработчиков MySQL раскритиковал проект и рекомендо..."	+/–
	Сообщение от Онаним (?), 10-Дек-21, 09:26
	У вас MVCC уже без лога работает? И даже с индексами? На самом деле нет. Постгря всё так же прекрасно пишет redo log, просто его назвали wal.
	Ответить | Правка | Наверх | Cообщить модератору

	238. "Один из разработчиков MySQL раскритиковал проект и рекомендо..."	+/–
	Сообщение от Онаним (?), 10-Дек-21, 09:27
	Тьфу плин MVCC. ACID, конечно же.
	Ответить | Правка | Наверх | Cообщить модератору

25. "Один из разработчиков MySQL раскритиковал проект и рекомендо..."	–1 +/–
Сообщение от Аноним (33), 06-Дек-21, 12:17
Местные Аноноимы опускают MySQL уже 20-ый год. Но только сейчас до одного из разработчиков MySQL дошло что он занимается фигнёй.
Ответить | Правка | Наверх | Cообщить модератору

	36. "Один из разработчиков MySQL раскритиковал проект и рекомендо..."	+1 +/–
	Сообщение от Аноним (-), 06-Дек-21, 12:34
	Если копры его забросят - получится отличный и стабильный продукт. Надеемся что не начнут хотеть переписать на раст или что-то.
	Ответить | Правка | Наверх | Cообщить модератору

	37. "Один из разработчиков MySQL раскритиковал проект и рекомендо..."	+/–
	Сообщение от Аноним (37), 06-Дек-21, 12:38
	Стагнация ещё ни один проект до добра не доводила.
	Ответить | Правка | Наверх | Cообщить модератору

	46. "Один из разработчиков MySQL раскритиковал проект и рекомендо..."	+1 +/–
	Сообщение от Аноним (-), 06-Дек-21, 13:14
	Пральна, раздать все копрам, и сосать лапу. Иначе же стогнация, нелицензионность и прочая протухаемость.
	Ответить | Правка | Наверх | Cообщить модератору

	104. "Один из разработчиков MySQL раскритиковал проект и рекомендо..."	+/–
	Сообщение от Аноним (103), 06-Дек-21, 16:56
	Ой, да ладно! Составит компанию Firebird, делов-то.
	Ответить | Правка | К родителю #37 | Наверх | Cообщить модератору

	45. "Один из разработчиков MySQL раскритиковал проект и рекомендо..."	+5 +/–
	Сообщение от th3m3 (ok), 06-Дек-21, 13:11
	Наконец-то мы были услышаны! Ждём осознания в станах Вордпресса, пехепешников.
	Ответить | Правка | К родителю #25 | Наверх | Cообщить модератору

	55. "Один из разработчиков MySQL раскритиковал проект и рекомендо..."	+1 +/–
	Сообщение от Аноним (55), 06-Дек-21, 13:33
	Не ждите - у них там религиозный культ.
	Ответить | Правка | Наверх | Cообщить модератору

	74. "Один из разработчиков MySQL раскритиковал проект и рекомендо..."	+/–
	Сообщение от 123 (??), 06-Дек-21, 14:29
	В станах "Вордпресса" давно предлагают использовать MariaDB.
	Ответить | Правка | К родителю #45 | Наверх | Cообщить модератору

27. "Один из разработчиков MySQL раскритиковал проект и рекомендо..."	+1 +/–
Сообщение от devkornev (ok), 06-Дек-21, 12:20
С новыми проектами - ок, выбор за Postgres. Но что делать, где уже MySQL. Обновление с 5 на 8 выливается в существенное замедление.
Ответить | Правка | Наверх | Cообщить модератору

	50. "Один из разработчиков MySQL раскритиковал проект и рекомендо..."	+/–
	Сообщение от Аноним (33), 06-Дек-21, 13:22
	Масштабироваться причем вертикально. Горизонтально не каждый сможет.
	Ответить | Правка | Наверх | Cообщить модератору

28. "Один из разработчиков MySQL раскритиковал проект и рекомендо..."	–1 +/–
Сообщение от Кондратий Карлович (?), 06-Дек-21, 12:21
А как там у постгресс с вакуумом  ??
Ответить | Правка | Наверх | Cообщить модератору

	32. "Один из разработчиков MySQL раскритиковал проект и рекомендо..."	+3 +/–
	Сообщение от анонимчик (?), 06-Дек-21, 12:25
	он идет
	Ответить | Правка | Наверх | Cообщить модератору

	66. "Один из разработчиков MySQL раскритиковал проект и рекомендо..."	+/–
	Сообщение от Аноним (64), 06-Дек-21, 14:01
	А как у MySql с optimize table?
	Ответить | Правка | К родителю #28 | Наверх | Cообщить модератору

	131. "Один из разработчиков MySQL раскритиковал проект и рекомендо..."	+/–
	Сообщение от Онаним (?), 06-Дек-21, 20:52
	Тут два вопроса: 1) Зачем конкретно? В большинстве случаев вообще не требуется. Единственное исключение - компактинг избыточно разлапистого индекса. 2) OPTIMIZE TABLE uses online DDL for regular and partitioned InnoDB tables, which reduces downtime for concurrent DML operations. The table rebuild triggered by OPTIMIZE TABLE is completed in place. An exclusive table lock is only taken briefly during the prepare phase and the commit phase of the operation. During the prepare phase, metadata is updated and an intermediate table is created. During the commit phase, table metadata changes are committed.
	Ответить | Правка | Наверх | Cообщить модератору

	132. "Один из разработчиков MySQL раскритиковал проект и рекомендо..."	+/–
	Сообщение от Онаним (?), 06-Дек-21, 20:53
	Точнее второе даже не вопрос. Онлайновая операция это ныне на InnoDB, которая допускает DML во время выполнения.
	Ответить | Правка | К родителю #66 | Наверх | Cообщить модератору

	221. "Один из разработчиков MySQL раскритиковал проект и рекомендо..."	+/–
	Сообщение от cadmi (?), 07-Дек-21, 15:32
	А как там у mysql с ddl в транзакциях? Научились уже? :)
	Ответить | Правка | К родителю #28 | Наверх | Cообщить модератору

35. "Один из разработчиков MySQL раскритиковал проект и рекомендо..."	+1 +/–
Сообщение от Аноним (-), 06-Дек-21, 12:32
> всё в порядке, не утруждая себя сравнением с другими СУБД, которые давно ушли вперёд Ну ушли себе и ушли, это их проблемы.
Ответить | Правка | Наверх | Cообщить модератору

39. "Один из разработчиков MySQL раскритиковал проект и рекомендо..."	–1 +/–
Сообщение от An (??), 06-Дек-21, 12:50
А ну ребятишки, расскажите про маленькие и средние проекты, когда мускул тащил на себе адсенс гугла, метрику и директ яндекса. А? Это говорит о том, что вы, господа - рукожопы. И не умеете готовить мускул.
Ответить | Правка | Наверх | Cообщить модератору

	43. "Один из разработчиков MySQL раскритиковал проект и рекомендо..."	+4 +/–
	Сообщение от Аноним (41), 06-Дек-21, 13:10
	На маленьком проекте использовал гугл адсенс. Подключил скрипт JS и всё. Базу не использовал вообще. Путь к скрипту лежал в файлике. Значит можно мускуль заменить на файлик.
	Ответить | Правка | Наверх | Cообщить модератору

	48. "Один из разработчиков MySQL раскритиковал проект и рекомендо..."	+/–
	Сообщение от Аноним (48), 06-Дек-21, 13:15
	Про MySQL в Google Adsense - это миф, никогда он там не использовался. Вы видимо с Facebook путайте.
	Ответить | Правка | К родителю #39 | Наверх | Cообщить модератору

	49. "Один из разработчиков MySQL раскритиковал проект и рекомендо..."	+/–
	Сообщение от Аноним (33), 06-Дек-21, 13:19
	В mail.ru используют джангу вместе с MySQL и им норм. Но это совершенно не значит что так надо делать всем.
	Ответить | Правка | К родителю #39 | Наверх | Cообщить модератору

	61. "Один из разработчиков MySQL раскритиковал проект и рекомендо..."	–2 +/–
	Сообщение от Наме (?), 06-Дек-21, 13:49
	> А ну ребятишки, расскажите про маленькие и средние проекты, когда мускул тащил > на себе адсенс гугла, метрику и директ яндекса. А? Это говорит > о том, что вы, господа - рукожопы. И не умеете готовить > мускул. Вряд ли. ISAM хорош, когда надо много писать в хвост и не нужны транзакции. Например, в какой-нибудь системе не слишком ответственного логирования, где источник сообщений сам имеет надёжное хранилище.
	Ответить | Правка | К родителю #39 | Наверх | Cообщить модератору

	130. "Один из разработчиков MySQL раскритиковал проект и рекомендо..."	+/–
	Сообщение от Онаним (?), 06-Дек-21, 20:47
	На самом деле уже давно нет. И даже для логов нет. Потому что при обрыве записи эти гигасы вылетят на LOCK+REPAIR, и будет прелесть. InnoDB очень шустр ныне. Годится и для write-mostly в т.ч. Объёмы итоговые только негуманные, но со сжатием терпимо.
	Ответить | Правка | Наверх | Cообщить модератору

	67. "Один из разработчиков MySQL раскритиковал проект и рекомендо..."	+1 +/–
	Сообщение от Аноним (67), 06-Дек-21, 14:08
	+1 Пусть еще расскажут как замечательно мигрировать без данутайма базу на другой хост. Или делать шардинг. Все что касается административной части то у слоника все печально.
	Ответить | Правка | К родителю #39 | Наверх | Cообщить модератору

	82. "Один из разработчиков MySQL раскритиковал проект и рекомендо..."	–1 +/–
	Сообщение от Наме (?), 06-Дек-21, 14:53
	> +1 > Пусть еще расскажут как замечательно мигрировать без данутайма базу на другой хост. > Или делать шардинг. > Все что касается административной части то у слоника все печально. Ну Слоника со всем всё прекрасно. Ещё бы кластеризацию запилили и вообще было бы прекрасно.
	Ответить | Правка | Наверх | Cообщить модератору

	84. "Один из разработчиков MySQL раскритиковал проект и рекомендо..."	+/–
	Сообщение от Аноним (67), 06-Дек-21, 15:02
	Расскажи как будешь большую базу нагруженного приложения мигрировать на другой хост без даунтайма
	Ответить | Правка | Наверх | Cообщить модератору

	99. "Один из разработчиков MySQL раскритиковал проект и рекомендо..."	–2 +/–
	Сообщение от Наме (?), 06-Дек-21, 16:16
	> Расскажи как будешь большую базу нагруженного приложения мигрировать на другой хост без > даунтайма А в чём сложность? Ну не RAC, конечно, но вполне можно довести до приемлемого уровня.
	Ответить | Правка | Наверх | Cообщить модератору

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

	163. "Один из разработчиков MySQL раскритиковал проект и рекомендо..."	+/–
	Сообщение от Аноним (67), 07-Дек-21, 00:45
	Именно. Или пусть расскажет как будет восстанавливать X траназакций котоые удалили спустя 10-15 секунд PITR. Хотя что такое 200 потерянных транзакций и кому это может быть интересно.
	Ответить | Правка | Наверх | Cообщить модератору

	100. "Один из разработчиков MySQL раскритиковал проект и рекомендо..."	+/–
	Сообщение от Alexander (ok), 06-Дек-21, 16:41
	уже давно запилили: https://netpoint-dc.com/blog/mariadb-galera-3-node-cluster/
	Ответить | Правка | К родителю #82 | Наверх | Cообщить модератору

	112. "Один из разработчиков MySQL раскритиковал проект и рекомендо..."	+/–
	Сообщение от Наме (?), 06-Дек-21, 17:37
	> уже давно запилили: https://netpoint-dc.com/blog/mariadb-galera-3-node-cluster/ Ну это Мария. А это всё тот же ISAM, только навороченный. Но я не пробовал, ничего сказать не могу.
	Ответить | Правка | Наверх | Cообщить модератору

	123. "Один из разработчиков MySQL раскритиковал проект и рекомендо..."	+1 +/–
	Сообщение от Alexander (ok), 06-Дек-21, 20:14
	>> уже давно запилили: https://netpoint-dc.com/blog/mariadb-galera-3-node-cluster/ > Ну это Мария. А это всё тот же ISAM, только навороченный. Но > я не пробовал, ничего сказать не могу. Вы что-то путаете: --- Конечно, помимо достоинств у кластера Galera есть и ограничения (перевод фрагмента с официального сайта MariaDB):     Репликация поддерживается только для таблиц в формате InnoDB; --- Да, я тоже не пробовал :)
	Ответить | Правка | Наверх | Cообщить модератору

	239. "Один из разработчиков MySQL раскритиковал проект и рекомендо..."	+/–
	Сообщение от Онаним (?), 10-Дек-21, 09:32
	Какой ISAM, о чём вы. InnoDB к ISAM вообще отношения не имеет, это продукт Innobase, причём эту компаху Oracle купила задолго до санок с MySQL.
	Ответить | Правка | К родителю #112 | Наверх | Cообщить модератору

52. "Один из разработчиков MySQL раскритиковал проект и рекомендо..."	–7 +/–
Сообщение от Аноним (-), 06-Дек-21, 13:27
лишь бы не брать монгу
Ответить | Правка | Наверх | Cообщить модератору

	59. "Один из разработчиков MySQL раскритиковал проект и рекомендо..."	+2 +/–
	Сообщение от Аноним (-), 06-Дек-21, 13:47
	Действительно, когда нужен скуль почему же не взять монгу, хмм.
	Ответить | Правка | Наверх | Cообщить модератору

60. "Один из разработчиков MySQL раскритиковал проект и рекомендовал использовать PostgreSQL"	–2 +/–
Сообщение от Наме (?), 06-Дек-21, 13:47
Совет в духе "переходите с кефира на джек дениэлс".
Ответить | Правка | Наверх | Cообщить модератору

63. "Один из разработчиков MySQL раскритиковал проект и рекомендо..."	–2 +/–
Сообщение от Аноним (63), 06-Дек-21, 13:51
Дык мускуль и задуман как бесплатная поделка для студентов. Никто никогда и не говорил, что он пригоден для коммерческих продуктов. Так что я не знаю, кого он там пугает.
Ответить | Правка | Наверх | Cообщить модератору

	78. "Один из разработчиков MySQL раскритиковал проект и рекомендо..."	+/–
	Сообщение от ыы (?), 06-Дек-21, 14:41
	очень любопытная мысль... не хотите ее развить? Расскажите нам для чего был задуман PHP, Линукс, автомобиль, колесо...
	Ответить | Правка | Наверх | Cообщить модератору

	89. "Один из разработчиков MySQL раскритиковал проект и рекомендо..."	+/–
	Сообщение от Аноним (89), 06-Дек-21, 15:31
	Пусть с себя начнет
	Ответить | Правка | Наверх | Cообщить модератору

	208. "Один из разработчиков MySQL раскритиковал проект и рекомендо..."	+/–
	Сообщение от InuYasha (??), 07-Дек-21, 12:40
	вот как рыз вы в кучу мешаете носки с помидорами. PHP был задуман для добавления динамики в хоумпаги, а большой спрос и низкая квалификация родили монстра.
	Ответить | Правка | К родителю #78 | Наверх | Cообщить модератору

	229. "Один из разработчиков MySQL раскритиковал проект и рекомендо..."	+/–
	Сообщение от ыы (?), 08-Дек-21, 22:15
	>а большой спрос и низкая квалификация кто же такой умный задумывал его для хоумпегов которые будут верстаться при низком спросе и высокой квалификации? какие такие хоумпеги имелись в виду?
	Ответить | Правка | Наверх | Cообщить модератору

	240. "Один из разработчиков MySQL раскритиковал проект и рекомендо..."	–1 +/–
	Сообщение от Онаним (?), 10-Дек-21, 09:33
	Интернет задумывался как сеть для оборонного ведомства, а 640кб в своё время хватало всем. Windows 1.0 тоже был очередным унылым файловым менеджером для DOS.
	Ответить | Правка | К родителю #208 | Наверх | Cообщить модератору

	241. "Один из разработчиков MySQL раскритиковал проект и рекомендо..."	+/–
	Сообщение от Онаним (?), 10-Дек-21, 09:34
	(вещи, которые оказались удобны и востребованы - имеют свойство перерастать себя)
	Ответить | Правка | Наверх | Cообщить модератору

	242. "Один из разработчиков MySQL раскритиковал проект и рекомендо..."	+/–
	Сообщение от Онаним (?), 10-Дек-21, 09:37
	Freax тоже когда-то был личной поделкой под себя любимого, просто чтобы миних на 386 не пользовать.
	Ответить | Правка | К родителю #240 | Наверх | Cообщить модератору

71. "Один из разработчиков MySQL раскритиковал проект и рекомендо..."	–1 +/–
Сообщение от ыы (?), 06-Дек-21, 14:22
> не выделяет должных ресурсов, что мешает поддержанию его в виде конкурентоспособного продукта. Опенсорс в полный рост... А как же разработка сообществом? Где миллион волонтеров пишущих код оптимизатора?
Ответить | Правка | Наверх | Cообщить модератору

	97. "Один из разработчиков MySQL раскритиковал проект и рекомендо..."	+/–
	Сообщение от Аноним (-), 06-Дек-21, 16:12
	Не хотят Орацлу земные поклоны отбивать.
	Ответить | Правка | Наверх | Cообщить модератору

	150. "Один из разработчиков MySQL раскритиковал проект и..."	+1 +/–
	Сообщение от arisu (ok), 06-Дек-21, 22:10
	> Где миллион волонтеров давно используют постгрес и довольны. а кто в постгрес нормально не смог… ну, я не уверен, что это хороший вариант для MySQL.
	Ответить | Правка | К родителю #71 | Наверх | Cообщить модератору

88. "Один из разработчиков MySQL раскритиковал проект и рекомендо..."	–1 +/–
Сообщение от minonA (?), 06-Дек-21, 15:30
А всем ли нужен мощный оптимизатор запросов?
Ответить | Правка | Наверх | Cообщить модератору

	91. "Один из разработчиков MySQL раскритиковал проект и рекомендо..."	+/–
	Сообщение от Простоник (ok), 06-Дек-21, 15:53
	Хороший вопрос. Ответ зависит от того, сколько этот оптимизатор будет стоить.
	Ответить | Правка | Наверх | Cообщить модератору

	151. "Один из разработчиков MySQL раскритиковал проект и..."	+1 +/–
	Сообщение от arisu (ok), 06-Дек-21, 22:12
	> А всем ли нужен мощный оптимизатор запросов? да. потому что сделать из мощного хреновый просто, а вот наоборот — очень сложно.
	Ответить | Правка | К родителю #88 | Наверх | Cообщить модератору

111. "Один из разработчиков MySQL раскритиковал проект и рекомендо..."	+/–
Сообщение от Аноним (111), 06-Дек-21, 17:27
"но в общем виде работа оценивается как доведение его до уровня технологий начала 2000-х годов" И вот что ему не нравится. Технологию (пусть и старую) ДОВОДЯТ ДО УМА! А что постгресс? Конфетка уже?
Ответить | Правка | Наверх | Cообщить модератору

114. "Один из разработчиков MySQL раскритиковал проект и рекомендо..."	+/–
Сообщение от bsdun (?), 06-Дек-21, 18:42
А что никто не говорит про Group Replication в MySQL из каропки, которой в PostgreSQL и в помине нет. Чёт не догоняю чем она отстаёт...
Ответить | Правка | Наверх | Cообщить модератору

118. "Один из разработчиков MySQL раскритиковал проект и рекомендо..."	–1 +/–
Сообщение от Имя (?), 06-Дек-21, 19:31
Вот когда постгрес предложит мне мультимастер из коробки, встроенный колоночный движок и миллион приблуд вокруг потому что протокол мускуля знают все сто лет, тогда я подумаю слезть с марии. Всему свое, нет серебрянной пули (ну конечно если вы разработкой заняты а не чтением блогов).
Ответить | Правка | Наверх | Cообщить модератору

	120. "Один из разработчиков MySQL раскритиковал проект и рекомендо..."	+/–
	Сообщение от leap42 (ok), 06-Дек-21, 19:59
	>> ...когда постгрес предложит мне мультимастер из коробки... Опять 25... Зачем нужен мультимастер? Почти любая СУБД тормозит при записи на диск. Если у вас есть другой мастер, то с ним надо реплицироваться. Данные второго мастера тож надо писать другими словами. Производительность НЕ увеличивается. Это работало только с MySQL который всё тянул на одном(!) ядре процессора и иногда упирался в него. Убогий костыль для масштабирования по процу. Postgres уже лет 15 умеет в многоядерность, ему этот бред ни к чему.
	Ответить | Правка | Наверх | Cообщить модератору

	128. "Один из разработчиков MySQL раскритиковал проект и рекомендо..."	+/–
	Сообщение от Онаним (?), 06-Дек-21, 20:44
	Мультимастер - это не про производительность. Это про возможность продолжить писать в условиях полного отказа одного из мастеров. Пусть даже и с потерей части транзакций. А для бОльших гарантий есть синхронный мультимастер, Galera Cluster называется.
	Ответить | Правка | Наверх | Cообщить модератору

	138. "Один из разработчиков MySQL раскритиковал проект и рекомендо..."	+1 +/–
	Сообщение от ыы (?), 06-Дек-21, 21:01
	>Это про возможность продолжить писать в условиях полного отказа одного из мастеров В самом деле? Кто бы мог подумать ... На самом деле все транзакции писавшиеся на отказавшем мастере откатываются... и все что не дошло до другого мастера тоже откатывается. Вы же не зафиксируете половину атомарной записи, правда? :) Поэтому с точки зрения "продолжать писать при отказе" - мультимастер ничем не отличается от обычного переключения слэйва на праймори...
	Ответить | Правка | Наверх | Cообщить модератору

	145. "Один из разработчиков MySQL раскритиковал проект и рекомендо..."	–1 +/–
	Сообщение от Онаним (?), 06-Дек-21, 21:41
	Э-э-э, вы точно себе представляете, как репликация работает? Я вижу, что нет.
	Ответить | Правка | Наверх | Cообщить модератору

	176. "Один из разработчиков MySQL раскритиковал проект и рекомендо..."	+1 +/–
	Сообщение от funny.falcon (?), 07-Дек-21, 08:35
	Какая репликация? Синхронная? Асинхронная? Синхронная с кворумом? На протоколе консенсуса?
	Ответить | Правка | Наверх | Cообщить модератору

	178. "Один из разработчиков MySQL раскритиковал проект и рекомендо..."	–1 +/–
	Сообщение от Онаним (?), 07-Дек-21, 09:24
	Та, которая обсуждается. Но это слишком сложно, понимаю.
	Ответить | Правка | Наверх | Cообщить модератору

	181. "Один из разработчиков MySQL раскритиковал проект и рекомендо..."	+/–
	Сообщение от funny.falcon (?), 07-Дек-21, 09:47
	Видимо, для вас действительно сложно.
	Ответить | Правка | Наверх | Cообщить модератору

	146. "Один из разработчиков MySQL раскритиковал проект и рекомендо..."	–1 +/–
	Сообщение от Онаним (?), 06-Дек-21, 21:47
	Ну и я же не зря написал: с потерей части транзакций. Если потеря части данных не вызывает проблем. Для всякой негарантированной статистики - более чем. Если у нас нет строгих требований к упорядоченности - мы ещё и на любой мастер писать можем, да, будет лаг синхронизации, но см. в начало строчки. Если нам нужен мульти-мастер с синхронностью и откатом - берём галеру. Там да, не завершённая транзакция откатывается со всех узлов. Но при этом нам не нужно ничего "переключать" - как только транзакция упавшего мастера откатится, следующие будут выполнены. Более того, мы можем на любой мастер писать.
	Ответить | Правка | К родителю #138 | Наверх | Cообщить модератору

	213. "Один из разработчиков MySQL раскритиковал проект и рекомендо..."	+/–
	Сообщение от Наме (?), 07-Дек-21, 13:37
	Если нужен "мультимастер", то берём Oracle RAC, а БД размещаем поверх ceph.
	Ответить | Правка | Наверх | Cообщить модератору

	173. "Один из разработчиков MySQL раскритиковал проект и рекомендо..."	+2 +/–
	Сообщение от leap42 (ok), 07-Дек-21, 08:06
	>> Мультимастер - это не про производительность. Это про возможность продолжить писать в условиях полного отказа одного из мастеров. Пусть даже и с потерей части транзакций. Вы не слушайте того кто вам такое говорит, он вообще не шарит.  Когда primary отказывает, ближайший standby становится мастером сам. Всё. Почему это лучше мультимастера? - Очень легко избежать split brain. С асинхронным мультимастером избежать split brain вообще не всегда возможно - вопрос только "когда". Синхронный мультимастер ставит на колени производительность при географическом удалении нод в 100%, и почти всегда даже если они рядом.
	Ответить | Правка | К родителю #128 | Наверх | Cообщить модератору

	177. "Один из разработчиков MySQL раскритиковал проект и рекомендо..."	+/–
	Сообщение от funny.falcon (?), 07-Дек-21, 08:41
	Согласен на 99.99% Мультимастер действительно более живуч. Но действительно тормознее. Практически ни кому живучесть мультимастера не нужна. Время переключения реплики - обычно меньше 1 минуты (чаше всего, 10-20 секунд). Пять переключений в год - это доступность 99.999%. Этого достаточно даже для маркетплейсов и банков (хоть они и заявляют шесть девяток, но рады и пяти девяткам).
	Ответить | Правка | Наверх | Cообщить модератору

	214. "Один из разработчиков MySQL раскритиковал проект и рекомендо..."	–2 +/–
	Сообщение от Наме (?), 07-Дек-21, 13:39
	Наоборот мульти-мастер это про производительность. Просто единственный реализованный нормальный мультимастер это RAC, где энное кол-во экземпляров работают с одним набором файлов данных (которые сами могут быть пространственно размазаны поверх сетевой фс). А галера эта муть какая-то.
	Ответить | Правка | Наверх | Cообщить модератору

125. "Один из разработчиков MySQL раскритиковал проект и рекомендо..."	+1 +/–
Сообщение от Аноним (125), 06-Дек-21, 20:35
GOOGLE vs ORACLE Мужик-же просто отрабатывает подъемные у нового (старого) работодателя. Все, увы, банально и старо, как мир. :)
Ответить | Правка | Наверх | Cообщить модератору

127. "Один из разработчиков MySQL раскритиковал проект и рекомендо..."	–2 +/–
Сообщение от Онаним (?), 06-Дек-21, 20:43
Што, мужику отказали в возможности безальтернативный VACUUM в MySQL добавить? Так не приживётся он там, без него хорошо.
Ответить | Правка | Наверх | Cообщить модератору

160. "Один из разработчиков MySQL раскритиковал проект и рекомендо..."	–2 +/–
Сообщение от Фан (?), 07-Дек-21, 00:04
MySQL будучи карманной игрушкой Oracle по определению не может быть конкурентноспособной РСУБД, по причини наличия у Oracle своей собственной РСУБД Слон же не принадлежит никому и поэтому искуственных палок в колеса ему не вставляют, есть еще Firebird, но это классическая РСУБД без новомодных приблуд, к слову очень хорошая
Ответить | Правка | Наверх | Cообщить модератору

	179. "Один из разработчиков MySQL раскритиковал проект и рекомендо..."	–1 +/–
	Сообщение от Аноньимъ (ok), 07-Дек-21, 09:38
	А натуральные вставляют? Должен ли велик быть обязательно чьим-то чтобы вставлять ему палки в колёса?
	Ответить | Правка | Наверх | Cообщить модератору

	183. "Один из разработчиков MySQL раскритиковал проект и рекомендо..."	–1 +/–
	Сообщение от Старший аноним (?), 07-Дек-21, 10:31
	У вас какой уровень IQ, вьюноша? Oracle взял свистоподелку и слепил из нее нормальный продукт. Но если изначально были родовые травмы, то от них очень трудно избавиться.
	Ответить | Правка | К родителю #160 | Наверх | Cообщить модератору

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

	196. "Один из разработчиков MySQL раскритиковал проект и рекомендо..."	+/–
	Сообщение от ыы (?), 07-Дек-21, 11:28
	1 миллиард долларов США если интересно :)
	Ответить | Правка | Наверх | Cообщить модератору

	198. "Один из разработчиков MySQL раскритиковал проект и рекомендо..."	+/–
	Сообщение от ыы (?), 07-Дек-21, 11:30
	к половине сайтов в интернете надо еще прибавить небольшую социальную сеточку...
	Ответить | Правка | К родителю #193 | Наверх | Cообщить модератору

	205. "Один из разработчиков MySQL раскритиковал проект и..."	+/–
	Сообщение от arisu (ok), 07-Дек-21, 12:08
	> к половине сайтов в интернете надо еще прибавить небольшую социальную сеточку... не надо. там от продукта жизнедеятельности монти осталось примерно столько же, сколько в их компиляторе php от оригинального php.
	Ответить | Правка | Наверх | Cообщить модератору

	225. "Один из разработчиков MySQL раскритиковал проект и рекомендо..."	+/–
	Сообщение от Фан (?), 08-Дек-21, 20:55
	В чем смысл коммерческой корпорации Oracle вкладывать в MySQL в ущерб своей Oracle? Или Oracle Corporation уж стал Oracle Foundation? И не разрабатывает MySQL по остаточном признаку
	Ответить | Правка | К родителю #183 | Наверх | Cообщить модератору

	230. "Один из разработчиков MySQL раскритиковал проект и рекомендо..."	+/–
	Сообщение от ыы (?), 08-Дек-21, 22:18
	Мускул ниразу не конкурент ораклу. Совершенно разные целевые сегменты... мускулем они закрывают нишу... и делают совершенно правильно.
	Ответить | Правка | Наверх | Cообщить модератору

	252. "Один из разработчиков MySQL раскритиковал проект и рекомендо..."	+/–
	Сообщение от www2 (??), 23-Дек-21, 13:12
	Версий много и все они могут быть правдивы как по отдельности, так и вместе: - диверсифицируют риски, - расширяют количество потенциальных клиентов, - предоставляют полный сервис по решению проблем клиента в комплексе, а не ограничиваются задачей впарить один конкретный продукт всем подряд.
	Ответить | Правка | К родителю #225 | Наверх | Cообщить модератору

162. "Один из разработчиков MySQL раскритиковал проект и рекомендо..."	+/–
Сообщение от Аноним (162), 07-Дек-21, 00:33
Выглядит как чувак не смог (занимался оптимизацией, которая по итогу оказалась на уровне 2000-х), ему сказали "и за что тебе платить?", он обидился, свалил и решил нагадить под дверь ораклам.
Ответить | Правка | Наверх | Cообщить модератору

170. "Один из разработчиков MySQL раскритиковал проект и рекомендо..."	+/–
Сообщение от Виктор (??), 07-Дек-21, 05:45
Используйте инструменты по назначению, да не везде будут фишки остальных баз. Но свои функции для сайтов вполне справляется, если ты не фирма гигант конечно же!
Ответить | Правка | Наверх | Cообщить модератору

200. "Один из разработчиков MySQL раскритиковал проект и рекомендо..."	+/–
Сообщение от 1 (??), 07-Дек-21, 11:41
Не вижу комментариев - зачем они нужны, когда есть SQLite ?
Ответить | Правка | Наверх | Cообщить модератору

	203. "Один из разработчиков MySQL раскритиковал проект и рекомендо..."	+/–
	Сообщение от ыы (?), 07-Дек-21, 11:47
	Это настолько самособой разумеется, что даже холиварить повода нет...
	Ответить | Правка | Наверх | Cообщить модератору

	218. "Один из разработчиков MySQL раскритиковал проект и рекомендо..."	+/–
	Сообщение от Аноним (219), 07-Дек-21, 15:06
	зачем нужны комментарии?
	Ответить | Правка | К родителю #200 | Наверх | Cообщить модератору

209. "Один из разработчиков MySQL раскритиковал проект и рекомендо..."	+/–
Сообщение от InuYasha (??), 07-Дек-21, 12:45
> Oracle не выделяет должных ресурсов Смешно. Не то чтобы они купили май для захоронения, но вообще Oracle скатывает всё в помойную яму, какапывая тоннами лицензий, контрактов, подписок и поливая вендорлоками.
Ответить | Правка | Наверх | Cообщить модератору

226. "Один из разработчиков MySQL раскритиковал проект и рекомендо..."	–3 +/–
Сообщение от Аноним (226), 08-Дек-21, 20:59
Что первое что второе - детские погремушки на фоне того же mssql.
Ответить | Правка | Наверх | Cообщить модератору

	231. "Один из разработчиков MySQL раскритиковал проект и рекомендо..."	+/–
	Сообщение от ыы (?), 08-Дек-21, 22:19
	mssql на линухе уже научилась через шаред мемори работать?
	Ответить | Правка | Наверх | Cообщить модератору

	243. "Один из разработчиков MySQL раскритиковал проект и рекомендо..."	+/–
	Сообщение от Онаним (?), 10-Дек-21, 09:40
	В MSSQL особо убивает стохастика оптимизатора - финальный план запроса может меняться 100500 раз при просто последовательном выполнении одного и того же запроса. Мало того без профайлера не разгребёшь, где засада, так ещё и каждый запуск выливается в разные планы, и результаты профайлера не бьются друг с другом. Наши виндодевелоперы с ним трахаются с завидной регулярностью.
	Ответить | Правка | К родителю #226 | Наверх | Cообщить модератору

	244. "Один из разработчиков MySQL раскритиковал проект и..."	+/–
	Сообщение от arisu (ok), 10-Дек-21, 11:02
	как удивительно: сервер видит повторяющиеся паттерны — и оптимизирует под них. вот же гад какой, а!
	Ответить | Правка | Наверх | Cообщить модератору

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

	246. "Один из разработчиков MySQL раскритиковал проект и..."	+/–
	Сообщение от arisu (ok), 10-Дек-21, 12:18
	ну. пробует разные планы, ведёт статистику. в принципе, нормальный метод оптимизации — для реальных нагрузок, где несколько плохих планов нивелируются последующими выигрышами. вполне логично, что при таких раскладах бенчмарки имеют такой же смысл, как и любая другая ИБД.
	Ответить | Правка | Наверх | Cообщить модератору

	247. "Один из разработчиков MySQL раскритиковал проект и..."	+/–
	Сообщение от Онаним (?), 10-Дек-21, 12:31
	Ды там дело не в бенчмарке. Там проблема проблему трекнуть. Оно на половине его стохастики допустим где-то костыляется, и вместо 0.01 сек выдаёт 2-3 сек на том же запросе, при _отсутствии_ параллельных запросов - в идеальном сферическом тесте в вакууме. При этом план совершенно другой, чем вызвано - никто не объясняет, как фиксить - непонятно.
	Ответить | Правка | Наверх | Cообщить модератору

	248. "Один из разработчиков MySQL раскритиковал проект и..."	+/–
	Сообщение от Онаним (?), 10-Дек-21, 12:33
	(точнее понятно, и уже зафиксили) Разбили запрос на три и объединение через хранимку, в итоге вместо 0.01-2.6 стали почти стабильные 0.07-0.14, плохо, но лучше, чем вот та задница.
	Ответить | Правка | Наверх | Cообщить модератору

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

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