Преобразование MyISAM к InnoDB. Выгодный? Последствия?
Мы выполняем сайт социальной сети, который регистрирует действие каждого участника (включая посещение страниц другого участника); это включает много записей к дб. Эти действия хранятся в таблице MyISAM и так как что-то начинает облагать налогом ЦП, моя первая мысль была то, что это - блокировка таблицы MyISAM, который вызывает это напряжение на ЦП.
- Существуют только чтения и записи, никакие обновления этой таблицы. Я думаю, что баланс между чтениями и записями о 50/50 для этой таблицы, InnoDB поэтому был бы более оптимальным вариантом?
- Если я хочу изменить таблицу на InnoDB, и мы не используем ограничения внешнего ключа, транзакции или полнотекстовые индексы - я должен волноваться о чем-нибудь?
3 ответа
Несмотря на какие-либо преимущества/недостатки его использования, которые обсуждаются в других потоках ( MyISAM против InnoDB), миграция является нетривиальным процессом.
Рассмотрим
- Функциональное тестирование всех компонентов, которые по возможности общаются с базой данных - разные движки имеют разную семантику
- Выполнение как можно большего количества тестирования производительности - некоторые вещи могут улучшаться, другие - намного хуже. Известный пример - SELECT COUNT(*) на большой таблице.
- Проверка того, что весь ваш код будет грациозно обрабатывать дедлоки - вы можете получить их без явного использования транзакций
- Оцените, сколько места вы получите при конвертации - проверьте это в непроизводственной среде.
Вам, несомненно, придется изменить что-то в большой программной платформе; это нормально, но так как у вас (надеюсь) много автотестирования, изменения должны быть приемлемы.
PS: Если "Что-то начинает облагать центральный процессор налогом", то вы должны a) выяснить, что, в непроизводственной среде, b) попробовать различные опции, чтобы уменьшить это, в непроизводственной среде. Вы не должны слепо начинать делать такие важные вещи, как замена движков баз данных, когда вы еще не полностью проанализировали проблему.
Все тестирование производительности должно проводиться в непроизводственной среде, с данными, подобными производственным, и на оборудовании производственного класса. В противном случае будет сложно корректно интерпретировать результаты
.Я думаю, что вполне возможно, что переход на InnoDB улучшит производительность, но, по моему опыту, вы не можете быть уверены, пока не попробуете. На вашем месте я бы установил тестовое окружение на том же сервере, преобразовал бы его в InnoDB и запустил бенчмарк
.С уважением к другим потенциальным проблемам миграции:
1) Космос - таблицы InnoDB часто требуют большего дискового пространства, хотя формат файла Barracuda для новых версий InnoDB сузил разницу. Вы можете получить смысл для этого, преобразовав недавнюю резервную копию таблиц и сравниваю размер. Используйте «Показать статус таблицы», чтобы сравнить длину данных.
2) Полный текстовый поиск - только на MyISAM
3) GIS / пространственные типы данных - только на MyISAM
на производительности, как и другие ответы, а ссылка на ответ, это зависит от вашей рабочей нагрузки. MyISAM гораздо быстрее для полной таблицы сканирования. InnoDB имеет тенденцию быть намного быстрее для высокопоставленного доступа. InnoDB также может быть намного быстрее, если ваши поиски основаны на первичном ключ.
Другой выпуск производительности состоит в том, что MyISAM всегда может держать подсчет строки, поскольку он только делает блокировку уровня таблицы. Таким образом, если вы часто пытаетесь получить подсчет строки для очень большого стола, он может быть намного медленнее с InnoDB. Ищите в интернете, если вам нужен обходной путь для этого, как я видел несколько предложенных.
В зависимости от размера таблицы (ы), вам также может потребоваться обновить файл mysql config. По крайней мере, вы можете снять байты из Key_Buffer в InnoDB_BUFFER_POOL_SIZE. Вы не получите справедливое сравнение, если вы оставляете базу данных как оптимизированную для MyISAM. Читайте все свойства конфигурации InnoDB_ *.