Как MySQL должен быть оптимизирован / настроен для большого количества записей и нескольких операций чтения (100: 1). Читайте перф

Question

У меня есть простая база данных с 4 таблицами по несколько миллионов строк в каждой и несколькими индексами. Я выполняю несколько сотен обновлений и вставляю их в минуту. Чтения гораздо реже, но они должны быть быстрыми - для веб-приложения. Чтения должны иметь приоритет - я могу отложить запись, если это поможет улучшить скорость чтения.

В настоящее время, когда я не пишу вставки и обновления, все красиво выбирается. Когда я пишу одновременно, все может замедлиться - иногда массово. Сервер определенно привязан к вводу-выводу - я использовал iostat и видел, что унификация диска достигла 99% в периоды высокой записи.

Завтра я попытаюсь сократить индекс или два, уменьшить размер строки и отключить кэш запросов. У кого-нибудь есть какие-либо другие предложения относительно того, как таблица или сам mysql должны быть настроены для большого количества записей и нескольких операций чтения?

Таблицы в настоящее время настроены на использование механизма innodb с компактными строками, и большая часть конфигурации по-прежнему настроена по умолчанию, кроме размера пула буферов. БД будет продолжать быстро расти, поэтому не стоит выбирать все это.

Обновление: это на slicehost.com - 1 Гб оперативной памяти, рейд 10.

Answer 1

Я думаю, вам нужно рассмотреть возможность разбиения. Это практически единственный способ масштабирования записей. MySQL имеет встроенную поддержку для этого начиная с версии 5.1 и выше, но также вполне возможно реализовать собственное решение Последнее намного сложнее, поэтому, если возможно, я бы рекомендовал использовать встроенную поддержку. Однако, учитывая вашу чрезмерную нагрузку при записи, этого может быть недостаточно. Однако сложно дать вам более подробный совет, не зная, как структурированы данные.

Answer 2

К сожалению, MySQL, как правило, рассчитан на чтение / запись 80/20. Я не знаю, много ли ты можешь сделать.

Используете ли вы транзакции?

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

Answer 3

Одна вещь (из многих), которую следует учитывать, - это использование транзакций. Если вы можете объединить несколько операций записи в одну транзакцию, это должно уменьшить количество обращений к диску.

Answer 4

Индексы будут замедлять запись, но они необходимы для производительности чтения, так что лишь немногие из них могут сойти с рук для поддержки чтения. Будет ли ваш кластерный индекс сильно замедляться?

Другой возможностью является чтение из отдельной базы данных / таблицы из ваших записей и выбор конечной согласованности - это может быть невозможно в вашем случае.

Answer 5

Если бы MySQL поддерживал коэффициент заполнения индекса, это была бы одна область, на которую нужно обратить внимание. К сожалению, версия 5 не поддерживает коэффициент заполнения (по-видимому, он находится в списке запрос функции для версии 6.x).

• Поможет удалить все неиспользуемые индексы и ограничить ширину ваших индексов.

• Проверьте, сколько памяти имеет сервер.

• Работает ли дисковый RAID?

Answer 6

Я предлагаю вам разделить запись / чтение, настроив конфигурацию mysql master-slave.

Вы пишете ведущему и перенаправляете чтения на ведомые устройства.

Само расщепление может быть сделано двумя способами

1. Использовать прокси (MySQL Proxy, Continuent / Sequoia, ..)
2. Сделайте разбиение самостоятельно в вашем приложении