article

1 2 3

Чем плох MySQL.

	От:	Maxim S. Shatskih mvp
	Дата:	16.07.07 16:06
	Оценка:	45 (10)

MySQL может использовать один из двух основных низкоуровневых движков — InnoDB или MyISAM.

InnoDB вроде как развитый. Только медленнее MyISAM раза в 2.5 — 3, а уж если сравнивать MySQL 4.0 c MSSQLServer 7 (делал такое году в 2004) на одинаковом железе — то Microsoft будет быстрее примерно втрое на паттерне "куча мелких апдейтов".

В общем, не знаю, имеет ли смысл пользоваться InnoDB, что с ним стало в "пятерке", и решает ли он хотя бы часть из нижеперечисленных проблем MyISAM. Если да — то, возможно, имеет смысл даже простить такое уменьшение производительности.

Теперь о MyISAM.

1. Только table-level locking. Чудовищные тормоза в апликации. Все ждут, пока кто-то один внесет изменения. Крайне забавно, например, для форумного движка со всеми сообщениями в одной таблице.
2. Отсутствие средства автовосстановления целостности по логу транзакций при старте базы. У MSSQLServer это было с рождения — с начала 90х. После крахов реально пропадают строки из таблиц. Лично видел.
3. Отсутствие полноценных средств бэкапа. Их всего два а) остановить демона, и скрутить базы в tgz б) mysqldump, который не бэкап, а экспорт в текст на языке SQL, и который — урааа! — накладывает лок длительностью во всю операцию.
4. Отвратительная имплементация ORDER BY, см. файл filesort.cc. Что они делают? выгружают ключи к результату (а то и сам результат) в _2 временных файла_, которые даже не являются MyISAMовскими таблицами. Аллоцируют временный буфер в памяти, нарезают его на кусочки, потом покусочечно читают туда первый временный файл, и пишут во второй, делая по ходу merge sort. В пределах кусочков используется qsort.

Почему это отвратительно? ну, то, что файлы растут, что при работе с ними используются обычные кэширующие syscalls — это полбеды. Беда в другом. Беда в аллокации этого самого sort_buffer на каждый запрос с ORDER BY. Если юзерей у системы много, а размер буфера велик — то реально исчерпать все 3GB юзерского адресного пространства во FreeBSD и получить облом в malloc(). Более того, там явно стоит цикл вида "а если malloc обломался — то пробуем буфер в 2 раза меньше".

Естественно, при такой нагрузке на heap malloc() начинает обламываться не только в filesort, но и в любом другом месте. И тут вступает в силу пятый пункт:

5. Некоторые обломы malloc() не проверяются в коде, и приводят к краху mysqld по сигналу 11.

Что, в свою очередь по пункту 2 иногда приводит к исчезновению строк из таблиц.

Как ORDER BY сделан в нормальных базах данных? SELECT INTO во временную таблицу с индексом, и потом SELECT уже из нее. Временная таблица создается в том же page cache, что и основная база данных, при этом у этих страниц ставится атрибут "слив на диск в последнюю очередь", что бережет disk IO. При исполнении ORDER BY не используется malloc() больших размеров.

Да, можно уменьшить в конфиге параметр sort_buffer_size. И получить стабильные тормоза раза в 4 медленнее, зато практически без крахов.

Насколько я понимаю, этот же движок сортировки используется и для InnoDB. В исходниках есть почти такой же код, который специфичен для MyISAM — но он используется в CREATE INDEX, а не в ORDER BY.

Выводы:
— при разработке приложений под MySQL нужно думать о том, как обойти эту проблему с ORDER BY, вплоть до выгрузки результата в таблицу (на деле временную) с индексом по атрибуту сортировки.
— иначе — на единицах гигабайт базы и сотнях пользователей — крах за крахом.
— обязательны "узкие композиты" при использовании таблиц с BLOBами, нужно добиваться того, чтобы EXPLAIN SELECT показывал Using index — т.е. полное неприкосновение к самой таблице с полным исполнением запроса по композиту.
— возможно, имеет смысл на коленке сделанный table partitioning.

Повторю еще раз — для приложений с ощутимой нагрузкой и ощутимыми размерами базы _нужно принимать специальные меры при разработке приложения, чтобы обойти MySQL misdesigns_.

Занимайтесь LoveCraftом, а не WarCraftом!

Re: Чем плох MySQL.

	От:	MasterZiv
	Дата:	17.07.07 07:02

Maxim S. Shatskih пишет:

> MySQL может использовать один ...
Эх, если б только этим он был плох ...

Posted via RSDN NNTP Server 2.1 beta

Re[2]: Чем плох MySQL.

	От:	Дм.Григорьев
	Дата:	17.07.07 07:39
	Оценка:

Здравствуйте, MasterZiv, Вы писали:

MZ>Maxim S. Shatskih пишет:

>> MySQL может использовать один ...
MZ>Эх, если б только этим он был плох ...

И вообще боян.

... << RSDN@Home 1.1.4 stable SR1 rev. 568>>

http://dimgel.ru/lib.web — thin, stateless, strictly typed Scala web framework.

Re[2]: Чем плох MySQL.

	От:	_d_m_
	Дата:	17.07.07 07:48

Здравствуйте, MasterZiv, Вы писали:

MZ>Maxim S. Shatskih пишет:

>> MySQL может использовать один ...
MZ>Эх, если б только этим он был плох ...

"Чем плох" — слишком объемная и развернутая тема. Лучше так: "чем он, собственно, хорош". Или: "а на хрена он нужен?"

Re[3]: Чем плох MySQL.

	От:	MasterZiv
	Дата:	17.07.07 07:54

_d_m_ пишет:
> "Чем плох" — слишком объемная и развернутая тема. Лучше так: "чем он,
> собственно, хорош". Или: "а на хрена он нужен?"

Расскажи об этом хостерам.

Posted via RSDN NNTP Server 2.1 beta

Re[4]: Чем плох MySQL.

	От:	_d_m_
	Дата:	17.07.07 07:58

Здравствуйте, MasterZiv, Вы писали:

MZ>_d_m_ пишет:
>> "Чем плох" — слишком объемная и развернутая тема. Лучше так: "чем он,
>> собственно, хорош". Или: "а на хрена он нужен?"

MZ>Расскажи об этом хостерам.

Хорош для хостеров?

Re[5]: Чем плох MySQL.

	От:	Maxim S. Shatskih mvp
	Дата:	17.07.07 08:35

Здравствуйте, _d_m_, Вы писали:

___>Здравствуйте, MasterZiv, Вы писали:

MZ>>_d_m_ пишет:
>>> "Чем плох" — слишком объемная и развернутая тема. Лучше так: "чем он,
>>> собственно, хорош". Или: "а на хрена он нужен?"

MZ>>Расскажи об этом хостерам.

___>Хорош для хостеров?

Конечно. Халявностью.

Занимайтесь LoveCraftом, а не WarCraftом!

Re[3]: Чем плох MySQL.

	От:	Maxim S. Shatskih mvp
	Дата:	17.07.07 08:37

___>"Чем плох" — слишком объемная и развернутая тема. Лучше так: "чем он, собственно, хорош". Или: "а на хрена он нужен?"

Здесь начинает возникать вопрос о том, не является ли Microsoft Jet Database Engine (ODBCJT32.DLL) — чем-то лучшим, чем MySQL.

Я вон смотрю, кто-то играется с MySQL под виндами. А не лучше ли Jet? Там и база данных создается легко из ODBC Administrator

Занимайтесь LoveCraftом, а не WarCraftом!

Re[6]: Чем плох MySQL.

	От:	LuciferArh
	Дата:	17.07.07 09:18

Здравствуйте, Maxim S. Shatskih, Вы писали:

___>>Хорош для хостеров?

MSS>Конечно. Халявностью.

Да ну... Есть, например, FB. Гораздо более привлекательный и удобный сервер, нежели MySQL. И точно так же совсем бесплатен.

Планета бибисяка: пива нэт, ФидоHэт, населена юзвеpями

Re[7]: Чем плох MySQL.

	От:	Maxim S. Shatskih mvp
	Дата:	17.07.07 11:07

LA>Да ну... Есть, например, FB. Гораздо более привлекательный и удобный сервер, нежели MySQL. И точно так же совсем бесплатен.

Давайте сравним FB и MySQL.

— table-level locking есть или нет?
— полноценные средства бэкапа есть или нет?
— журнал транзакций с автовосстановлением по нему есть или нет?
— валится ли? есть ли угребищные глупости, типа MySQLного ORDER BY?
— производительность?
— работа на базах в единицы гигабайт с нагрузкой в сотню коннектов?

На этом фоне такие вещи, как наличие или отсутствие stored proc, это просто пустяки.

Занимайтесь LoveCraftом, а не WarCraftом!

Re[8]: Чем плох MySQL.

	От:	LuciferArh
	Дата:	17.07.07 11:23

Здравствуйте, Maxim S. Shatskih, Вы писали:

MSS>Давайте сравним FB и MySQL.
Ок. Всего не помню, так как давно не работаю с FB. Может, что и поменялось...

MSS>- table-level locking есть или нет?
А надо? FB — версионник. Со всеми прелестями. Ну и недостатками тоже.
MSS>- полноценные средства бэкапа есть или нет?
Есть.
MSS>- журнал транзакций с автовосстановлением по нему есть или нет?
Нет. Поскольку — версионник. Автовосстановления, кажется, тоже нет. Хотя могу и ошибаться.

MSS>- валится ли? есть ли угребищные глупости, типа MySQLного ORDER BY?
Иногда валится. Чаще от криворукости пользователей и недосмотра разработчиков, не предусмотревших защиту от дурака. Глупостей с ORDER BY нет. Во всяком случае, описанных тобой я не наблюдал.

MSS>- производительность?
MSS>- работа на базах в единицы гигабайт с нагрузкой в сотню коннектов?
В чем? Разные задачи — разная производительность. Но в целом, прилично. У меня был один проект, где FB при работе с БД под 4 гига отлично тянул по 100-150 коннектов. Тут на форуме есть люди, которые работают только с FB. И эксплуатируют приличные по размерам базы. Можно у них поспрашивать.

MSS>На этом фоне такие вещи, как наличие или отсутствие stored proc, это просто пустяки.
Stored Proc есть. И очень давно.

В последних версиях даже расширили число функций. А вообще недостающий функционал легко реализуется UDF.

Планета бибисяка: пива нэт, ФидоHэт, населена юзвеpями

Re[7]: Чем плох MySQL.

	От:	MasterZiv
	Дата:	17.07.07 11:54

LuciferArh пишет:
> MSS>Конечно. Халявностью.
> Да ну... Есть, например, FB. Гораздо более привлекательный и удобный

Есть. Расскажи об этом хостерам.

Posted via RSDN NNTP Server 2.1 beta

Re[8]: Чем плох MySQL.

	От:	MasterZiv
	Дата:	17.07.07 11:56

Maxim S. Shatskih пишет:

> Давайте сравним FB и MySQL.

Ой, давайте не будем. Тем более все, что
вы тут указали, в болшинстве, есть и там, и там.

Posted via RSDN NNTP Server 2.1 beta

Re[9]: Чем плох MySQL.

	От:	MasterZiv
	Дата:	17.07.07 11:58

LuciferArh пишет:

> MSS>- журнал транзакций с автовосстановлением по нему есть или нет?
> Нет. Поскольку — версионник. Автовосстановления, кажется, тоже нет. Хотя
> могу и ошибаться.

Есть уже. Сделали. А DURABILITY там всегда было.

Posted via RSDN NNTP Server 2.1 beta

Re[4]: Чем плох MySQL.

	От:	MasterZiv
	Дата:	17.07.07 11:59

Maxim S. Shatskih пишет:

> Я вон смотрю, кто-то играется с MySQL под виндами. А не лучше ли Jet?
> Там и база данных создается легко из ODBC Administrator
А в нем ACID-транзакции есть ?
В MySQL хоть как-то, да есть.

Posted via RSDN NNTP Server 2.1 beta

Re[3]: Чем плох MySQL.

	От:	D. Mon	http://about.thedeemon.com
	Дата:	17.07.07 12:27

___>"чем он, собственно, хорош". Или: "а на хрена он нужен?"

Товарищ рассказывал, что у них был проект на Postgress и они потом сильно пожалели, что не на MySQL, когда потребовалось масштабировать проект с одного сервера на несколько. Ибо в одном репликации не было, а в другом была.

Re[7]: Чем плох MySQL.

	От:	Igor Trofimov
	Дата:	17.07.07 16:00

LA>Да ну... Есть, например, FB. Гораздо более привлекательный и удобный сервер, нежели MySQL. И точно так же совсем бесплатен.

Для хостинга FB не приспособлен совершенно.

Re: Чем плох MySQL.

	От:	Petrovich_Alex
	Дата:	17.07.07 16:13
	Оценка:	4 (1)

это по состоянию на 2004 год?

... << RSDN@Home 1.1.4 stable SR1 rev. 568>>

Re: Чем плох MySQL.

	От:	fidget
	Дата:	17.07.07 16:27

Здравствуйте, Maxim S. Shatskih, Вы писали:

MSS>2. Отсутствие средства автовосстановления целостности по логу транзакций при старте базы. У MSSQLServer это было с рождения — с начала 90х. После крахов реально пропадают строки из таблиц. Лично видел.

Странно ожидать восстановления целостности по логу транзакций от нетранзакционной storage engine. Транзакционные в MySQL это InnoDB и NDB Cluster, у них и есть восстановление по логу транзакций.

MSS>3. Отсутствие полноценных средств бэкапа. Их всего два а) остановить демона, и скрутить базы в tgz б) mysqldump, который не бэкап, а экспорт в текст на языке SQL, и который — урааа! — накладывает лок длительностью во всю операцию.

Для бэкапа MyISAM таблиц останавливать не обязательно. Достаточно сделать FLUSH TABLES WITH READ LOCK и скопировать файлы таблиц.

MSS>4. Отвратительная имплементация ORDER BY, см. файл filesort.cc. Что они делают? выгружают ключи к результату (а то и сам результат) в _2 временных файла_, которые даже не являются MyISAMовскими таблицами. Аллоцируют временный буфер в памяти, нарезают его на кусочки, потом покусочечно читают туда первый временный файл, и пишут во второй, делая по ходу merge sort. В пределах кусочков используется qsort.

MSS>Почему это отвратительно? ну, то, что файлы растут, что при работе с ними используются обычные кэширующие syscalls — это полбеды. Беда в другом. Беда в аллокации этого самого sort_buffer на каждый запрос с ORDER BY. Если юзерей у системы много, а размер буфера велик — то реально исчерпать все 3GB юзерского адресного пространства во FreeBSD и получить облом в malloc(). Более того, там явно стоит цикл вида "а если malloc обломался — то пробуем буфер в 2 раза меньше".

Зачем ставить большой sort_buffer_size? Если нет необходимости постоянно сортировать большие объемы данных, то sort_buffer_size стоит либо оставить дефолтным (2М) либо даже уменьшить и увеличивать его на уровне соединения, а не глобально перед теми запросами где это требуется.

Re[8]: Чем плох MySQL.

	От:	LuciferArh
	Дата:	18.07.07 04:12

Здравствуйте, Igor Trofimov, Вы писали:

iT>Для хостинга FB не приспособлен совершенно.

Доказательства и ссылки в студию! Иначе это просто голословное утверждение.

Планета бибисяка: пива нэт, ФидоHэт, населена юзвеpями

1 2 3