Comments 24
Хорошее сравнение, достаточно давно использую Maria db однако не задумывался о переходе на XtraDB, хотя и mysql 5.6 себя неплохо показывает в реальных условиях.
0
Без TokuDB не интересно :)
+3
TokuDB подглючивает
-2
Он же вроде как оптимизирует UPDATE / INSERT, а у меня тут Чтение / Запись: 98% / 2%
+1
Гвоздь в крышку аргументу, что MyISAM быстрее.
+2
MyISAM таки может быть быстрее, но на вставку, а здесь чтение 98%.
-1
Есть много use-кейсов, когда MyISAM просто несравнимо быстрее и более предсказуем, чем InnoDB (но все они работают с ограничением, что данные вам «не нужны», то есть, вы можете их восстановить каким-либо образом в случае краха БД, чтобы не ждать REPAIR TABLE):
— С опцией myisam_use_mmap, сортировка по вторичным индексам, с доп. фильтрацией работала, по моим бенчмаркам, раз в 5 быстрее:
Объясняется это довольно просто — в индексах InnoDB содержится первичный ключ, а в MyISAM — смещение строки. Если строки маленькие и при этом фиксированного размера, то такие запросы проходят на пол-порядка быстрее
— Если все, что вы делаете с таблицами — это вставка большого количества строк (в один поток на каждую конкретную таблицу) и редкая выборка по индексам, то MyISAM обладает минимальным оверхедом (в плане места и нагрузки на диск), позволяя вставлять сотни тысяч строк в секунду в каждую из таблиц
— Если вы даете очень большой поток UPDATE (и при этом вам не очень «жалко» данные), то MyISAM ведет себя намного более предсказуемо в плане производительности — у него нет транзакций и purge thread, он масштабируется практически линейно по ядрам
Если интересно, я могу попробовать провести честные бенчмарки и оформить в виде статьи :)
— С опцией myisam_use_mmap, сортировка по вторичным индексам, с доп. фильтрацией работала, по моим бенчмаркам, раз в 5 быстрее:
SELECT * FROM table WHERE <...> ORDER BY indexed_col LIMIT <...>
Объясняется это довольно просто — в индексах InnoDB содержится первичный ключ, а в MyISAM — смещение строки. Если строки маленькие и при этом фиксированного размера, то такие запросы проходят на пол-порядка быстрее
— Если все, что вы делаете с таблицами — это вставка большого количества строк (в один поток на каждую конкретную таблицу) и редкая выборка по индексам, то MyISAM обладает минимальным оверхедом (в плане места и нагрузки на диск), позволяя вставлять сотни тысяч строк в секунду в каждую из таблиц
— Если вы даете очень большой поток UPDATE (и при этом вам не очень «жалко» данные), то MyISAM ведет себя намного более предсказуемо в плане производительности — у него нет транзакций и purge thread, он масштабируется практически линейно по ядрам
Если интересно, я могу попробовать провести честные бенчмарки и оформить в виде статьи :)
+10
Эх, жаль, нету MariaDB 5.5, которую многие ставят вместо Mysql.
-1
Занимательно то, что если посмотреть на прогресс InnoDB от 5.1 к XtraDB, то видно что его сильно ускорили в 5.5, в 5.6 ещё немного, а форки ещё слегка допилили. В тоже время производительность MyISAM прыгает от версии к версии как захочет.
+1
А где структура таблиц и запросы на которых тестировали? Без этого это сферическое тестирование в вакууме с непонятными красивыми графиками на выходе…
+1
Примерно так и есть, суть поста в том, что утверждения вроде MyIsam быстрее InnoDB или Aria не уступает MyIsam нужно проверять для себя самостоятельно.
Тестируются не запросы к БД а запросы к сайту, который в свою очередь порождает запросы к базе данных, их там много разных, не думаю что имеет смысл все выкладывать.
К статье стоит относиться как к описанию методики, данные приводятся для конкретной базы, но все же могут быть интересны пользователям и с некоторой точностью отражают общую картину.
Тестируются не запросы к БД а запросы к сайту, который в свою очередь порождает запросы к базе данных, их там много разных, не думаю что имеет смысл все выкладывать.
К статье стоит относиться как к описанию методики, данные приводятся для конкретной базы, но все же могут быть интересны пользователям и с некоторой точностью отражают общую картину.
+1
Раньше тоже частенько мигрировал из разных БД и проводил бессонные ночи тестирований нагрузок.
Потом просто остановился на Maria db + ssd в рейде. Уже год как никаких проблем, все летает при сравнительно любых нагрузках.
Потом просто остановился на Maria db + ssd в рейде. Уже год как никаких проблем, все летает при сравнительно любых нагрузках.
-2
Сталкивался с тем, что большие значения query_cache_size ведут к тормозам.
Это особенность реализации query_cache в mysql, подробнее в блоге перконы:
www.percona.com/blog/2007/03/23/beware-large-query_cache-sizes/
2G слишком много.
Попробуйте меньшее значение, например:
Это особенность реализации query_cache в mysql, подробнее в блоге перконы:
www.percona.com/blog/2007/03/23/beware-large-query_cache-sizes/
2G слишком много.
Попробуйте меньшее значение, например:
query_cache_size = 128M query_cache_limit = 8M
+1
Ох и охота вам от мейнстрима отходить? А что будет когда 5.7 выйдет?
0
Sign up to leave a comment.
Тестирование производительности форков Mysql на реальных данных