Search
Write a publication
Pull to refresh

Comments 24

Хорошее сравнение, достаточно давно использую Maria db однако не задумывался о переходе на XtraDB, хотя и mysql 5.6 себя неплохо показывает в реальных условиях.
а конкретнее? (интересно, вроде они стабильные)
Вот именно на больших данных и подглючивает. Может что-то и изменилось за это время, делали тесты года два назад.
Он же вроде как оптимизирует UPDATE / INSERT, а у меня тут Чтение / Запись: 98% / 2%
ну не только, у них ведь еще индексы интересные есть. мы делали DWH под собственные нужды (да да, от бедности не на vertica|infobrigh) – и лидером по тестам получился именно tokudb.
Гвоздь в крышку аргументу, что MyISAM быстрее.
MyISAM таки может быть быстрее, но на вставку, а здесь чтение 98%.
MyISAM при вставке блокирует таблицу полностью, в отличии от InnoDB, который при вставке блокирует только строку. Только это говорит об обратном. Все дело в транзакциях и внешний ключах, которых нет в MyISAM, и при бездумной работе с ними можно сильно замедлить InnoDB.
Есть много 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, он масштабируется практически линейно по ядрам

Если интересно, я могу попробовать провести честные бенчмарки и оформить в виде статьи :)
Эх, жаль, нету MariaDB 5.5, которую многие ставят вместо Mysql.
Можно будет дополнить ими потом, вообще хотел посмотреть именно последние версии, Mysql 5.1 здесь был для себя, чтобы сравнить производительность с текущей боевой средой
Занимательно то, что если посмотреть на прогресс InnoDB от 5.1 к XtraDB, то видно что его сильно ускорили в 5.5, в 5.6 ещё немного, а форки ещё слегка допилили. В тоже время производительность MyISAM прыгает от версии к версии как захочет.
А где структура таблиц и запросы на которых тестировали? Без этого это сферическое тестирование в вакууме с непонятными красивыми графиками на выходе…
Примерно так и есть, суть поста в том, что утверждения вроде MyIsam быстрее InnoDB или Aria не уступает MyIsam нужно проверять для себя самостоятельно.
Тестируются не запросы к БД а запросы к сайту, который в свою очередь порождает запросы к базе данных, их там много разных, не думаю что имеет смысл все выкладывать.
К статье стоит относиться как к описанию методики, данные приводятся для конкретной базы, но все же могут быть интересны пользователям и с некоторой точностью отражают общую картину.
Aria быстрее MyISAM с FIXED ROW форматом на выборках (но и данные должны быть ограниченной длины). Оверхэд только в размере таблицы
Раньше тоже частенько мигрировал из разных БД и проводил бессонные ночи тестирований нагрузок.
Потом просто остановился на Maria db + ssd в рейде. Уже год как никаких проблем, все летает при сравнительно любых нагрузках.
Сталкивался с тем, что большие значения 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
Ох и охота вам от мейнстрима отходить? А что будет когда 5.7 выйдет?
Не известно что придумает Oracle с лицензией
Sign up to leave a comment.

Articles