Тестирование производительности форков Mysql на реальных данных

[zenn]

Хорошее сравнение, достаточно давно использую Maria db однако не задумывался о переходе на XtraDB, хотя и mysql 5.6 себя неплохо показывает в реальных условиях.

[UUSER]

Без TokuDB не интересно :)

[akalend]

TokuDB подглючивает

[Silverstorm]

а конкретнее? (интересно, вроде они стабильные)

[akalend]

Вот именно на больших данных и подглючивает. Может что-то и изменилось за это время, делали тесты года два назад.

[evger]

Он же вроде как оптимизирует UPDATE / INSERT, а у меня тут Чтение / Запись: 98% / 2%

[Silverstorm]

ну не только, у них ведь еще индексы интересные есть. мы делали DWH под собственные нужды (да да, от бедности не на vertica|infobrigh) – и лидером по тестам получился именно tokudb.

[gnomeby]

Гвоздь в крышку аргументу, что MyISAM быстрее.

[ajaxtelamonid]

MyISAM таки может быть быстрее, но на вставку, а здесь чтение 98%.

[taliban]

MyISAM при вставке блокирует таблицу полностью, в отличии от InnoDB, который при вставке блокирует только строку. Только это говорит об обратном. Все дело в транзакциях и внешний ключах, которых нет в MyISAM, и при бездумной работе с ними можно сильно замедлить InnoDB.

[youROCK]

Есть много use-кейсов, когда MyISAM просто несравнимо быстрее и более предсказуем, чем InnoDB (но все они работают с ограничением, что данные вам «не нужны», то есть, вы можете их восстановить каким-либо образом в случае краха БД, чтобы не ждать REPAIR TABLE):

— С опцией myisam_use_mmap, сортировка по вторичным индексам, с доп. фильтрацией работала, по моим бенчмаркам, раз в 5 быстрее:

SELECT * FROM table WHERE <...> ORDER BY indexed_col LIMIT <...>

Объясняется это довольно просто — в индексах InnoDB содержится первичный ключ, а в MyISAM — смещение строки. Если строки маленькие и при этом фиксированного размера, то такие запросы проходят на пол-порядка быстрее

— Если все, что вы делаете с таблицами — это вставка большого количества строк (в один поток на каждую конкретную таблицу) и редкая выборка по индексам, то MyISAM обладает минимальным оверхедом (в плане места и нагрузки на диск), позволяя вставлять сотни тысяч строк в секунду в каждую из таблиц

— Если вы даете очень большой поток UPDATE (и при этом вам не очень «жалко» данные), то MyISAM ведет себя намного более предсказуемо в плане производительности — у него нет транзакций и purge thread, он масштабируется практически линейно по ядрам

Если интересно, я могу попробовать провести честные бенчмарки и оформить в виде статьи :)

[evger]

Да, интересно

[mapron]

Интересно, оформляйте!

[steff]

Статью можно не ждать?)

[ajaxtelamonid]

Эх, жаль, нету MariaDB 5.5, которую многие ставят вместо Mysql.

[evger]

Можно будет дополнить ими потом, вообще хотел посмотреть именно последние версии, Mysql 5.1 здесь был для себя, чтобы сравнить производительность с текущей боевой средой

[SonicGD]

Занимательно то, что если посмотреть на прогресс InnoDB от 5.1 к XtraDB, то видно что его сильно ускорили в 5.5, в 5.6 ещё немного, а форки ещё слегка допилили. В тоже время производительность MyISAM прыгает от версии к версии как захочет.

[LastDragon]

А где структура таблиц и запросы на которых тестировали? Без этого это сферическое тестирование в вакууме с непонятными красивыми графиками на выходе…

[evger]

Примерно так и есть, суть поста в том, что утверждения вроде MyIsam быстрее InnoDB или Aria не уступает MyIsam нужно проверять для себя самостоятельно.
Тестируются не запросы к БД а запросы к сайту, который в свою очередь порождает запросы к базе данных, их там много разных, не думаю что имеет смысл все выкладывать.
К статье стоит относиться как к описанию методики, данные приводятся для конкретной базы, но все же могут быть интересны пользователям и с некоторой точностью отражают общую картину.

[NickyX3]

Aria быстрее MyISAM с FIXED ROW форматом на выборках (но и данные должны быть ограниченной длины). Оверхэд только в размере таблицы

[L3n1n]

Раньше тоже частенько мигрировал из разных БД и проводил бессонные ночи тестирований нагрузок.
Потом просто остановился на Maria db + ssd в рейде. Уже год как никаких проблем, все летает при сравнительно любых нагрузках.

[agorlov]

Сталкивался с тем, что большие значения query_cache_size ведут к тормозам.

Это особенность реализации query_cache в mysql, подробнее в блоге перконы:
www.percona.com/blog/2007/03/23/beware-large-query_cache-sizes/

2G слишком много.

Попробуйте меньшее значение, например:

query_cache_size               = 128M
query_cache_limit              = 8M

[guglez]

Ох и охота вам от мейнстрима отходить? А что будет когда 5.7 выйдет?

[evger]

Не известно что придумает Oracle с лицензией