Преобразование MyISAM в InnoDB. Выгодно? Последствия?
У нас есть сайт социальной сети, который регистрирует действия каждого участника (включая посещение страниц других участников); это включает в себя много записей в БД. Эти действия хранятся в таблице MyISAM, и, поскольку что-то начинает обременять ЦП, моей первой мыслью было, что именно блокировка таблицы MyISAM вызывает такую нагрузку на ЦП.
- Есть только чтение и запись, нет обновлений в этой таблице. Я думаю, что баланс между операциями чтения и записи составляет около 50/50 для этой таблицы, поэтому InnoDB будет лучшим вариантом?
- Если я хочу изменить таблицу на InnoDB, и мы не используем ограничения внешнего ключа, транзакции или полнотекстовые индексы - нужно ли о чем-то беспокоиться?
4 ответа
Несмотря на любые преимущества / недостатки его использования, которые обсуждаются в других потоках ( MyISAM по сравнению с InnoDB), миграция является нетривиальным процессом.
Рассматривать
- Функциональное тестирование всех компонентов, которые обращаются к базе данных, если это возможно - разностные механизмы имеют разную семантику
- Проведите как можно больше тестов производительности - некоторые вещи могут улучшиться, другие могут быть намного хуже. Хорошо известным примером является SELECT COUNT(*) на большой таблице.
- Проверяя, что весь ваш код будет корректно обрабатывать взаимоблокировки - вы можете получить их без явного использования транзакций
- Оцените, сколько места вы получите за счет конвертации - протестируйте это в непроизводственной среде.
Вам, несомненно, нужно будет что-то менять на большой программной платформе; это нормально, но, учитывая, что у вас (надеюсь) есть большой охват автоматического тестирования, изменения должны быть приемлемыми.
PS: Если "что-то начинает облагать налогом процессор", то вам следует: а) выяснить, что в непроизводственной среде; б) попробовать различные варианты его уменьшения в непроизводственной среде. Вы не должны слепо начинать делать такие важные вещи, как смена движков баз данных, если вы не полностью проанализировали проблему.
Все тесты производительности должны проводиться в непроизводственной среде с данными, подобными производственным, и на оборудовании промышленного уровня. В противном случае трудно правильно интерпретировать результаты.
Что касается других потенциальных проблем миграции:
1) Пространство - Таблицы InnoDB часто требуют больше дискового пространства, хотя формат файла Barracuda для новых версий InnoDB сократил разницу. Вы можете понять это, преобразовав последнюю резервную копию таблиц и сравнив ее размер. Используйте "Показать статус таблицы" для сравнения длины данных.
2) Полнотекстовый поиск - только на MyISAM
3) ГИС / Пространственные типы данных - только на MyISAM
На производительность, как указывают другие ответы и ссылочный ответ, это зависит от вашей рабочей нагрузки. MyISAM намного быстрее для полного сканирования таблицы. InnoDB имеет тенденцию быть намного быстрее для высококонкурентного доступа. InnoDB также может быть намного быстрее, если ваши поиски основаны на первичном ключе.
Другая проблема с производительностью заключается в том, что MyISAM всегда может вести подсчет строк, поскольку он выполняет только блокировку на уровне таблицы. Так что, если вы часто пытаетесь получить количество строк для очень большой таблицы, это может быть намного медленнее с InnoDB. Поищите в Интернете, если вам нужен обходной путь для этого, как я видел несколько предложенных.
В зависимости от размера таблиц, вам также может потребоваться обновить конфигурационный файл MySQL. По крайней мере, вы можете захотеть переместить байты из key_buffer в innodb_buffer_pool_size. Вы не получите честного сравнения, если оставите базу данных как оптимизированную для MyISAM. Ознакомьтесь со всеми свойствами конфигурации innodb_*.
Я думаю, что вполне возможно, что переход на InnoDB улучшит производительность, но по моему опыту, вы не можете быть уверены, пока не попробуете. На вашем месте я бы настроил тестовую среду на том же сервере, конвертировал бы в InnoDB и запустил бенчмарк.
Исходя из моего опыта, таблицы MyISAM полезны только для индексирования текста, когда вам нужна хорошая производительность при поиске по большому тексту, но вам по-прежнему не нужна полноценная поисковая система, такая как Solr или ElasticSearch.
Если вы хотите переключиться на InnoDB, но хотите продолжать индексировать свой текст в таблице MyISAM, я предлагаю вам взглянуть на это: http://blog.lavoie.sl/2013/05/converting-myisam-to-innodb-keeping-fulltext.html
Также: InnoDB поддерживает резервное копирование в режиме реального времени с использованием innobackupex от Percona. Это больно при работе с производственными серверами.