5 стратегий работы с высокими нагрузками в MySQL

MySQL — проверенная и очень мощная технология. В том числе и для построения систем с большой нагрузкой. Даже Facebook использует MySQL для управления огромными объемами данных. Рассмотрим основные стратегии для построения нагруженных систем на основе MySQL.

Оптимизация и индексы

Прежде всего убедитесь, что вы используете все стандартные возможности базы данных. Правильная работа с индексами даст огромные приросты в производительности. Сотни и даже тысячи раз. Освобождая при этом ресурсы для других задач. Сегодня стоимость жестких дисков постоянно снижается, а требования к скорости постоянно растут.

Индексы – это эффективный механизм перенести нагрузку с процессора на жесткий диск в правильных пропорциях.

Не спешите оптимизировать все запросы заранее. Используйте лог медленных запросов, чтобы понять, где существуют реальные проблемы.

Сразу после установки MySQL не забудьте оптимизировать основные параметры. Стандартная настройка очень базовая и ориентирована на скромное железо и жесткие требования к сохранности.

Подстройка стандартных параметров даст существенный прирост в ускорении не только операций чтения, а и записи.

Кэширование

Очень популярным методом оптимизации производительности является кэширование.

Внутренний кэш MySQL

Перед тем как использовать внешнее решение, подумайте, стоит ли использовать внутренний кэш MySQL. Его имеет смысл включать в тех случаях, когда MySQL работает с очень большим количеством чтений (SELECT), но не очень большим (как минимум в 10 раз меньше) записей (INSERT, DELETE и UPDATE).

Лучше не включать внутренний кэш Mysql в средах с большим количеством записей/обновлений.

Настройка кэша выполняется с помощью параметра mysql_query_cache_size.

Внешние решения

Более гибкое решение — использование внешних инструментов кэширования, вроде Memcache либо Redis. Есть целый ряд техник кэширования данных в приложениях.

Однако будьте осторожны. Кэширование — это часто не решение проблемы, а ее откладывание. Медленный запрос становится еще медленнее, а его влияние (при сбросе кэша) — менее прогнозируемым.

Кэширование лучше использовать только как промежуточные решения. В конце концов следует избавляться от медленных запросов.

Репликация

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

С другой стороны, реплика как раз позволяет обеспечить высокую доступность. Один из подходов выглядит так:

• Использовать master-slave-репликацию для каждого сервера БД.
• Приложение всегда работает только с мастером.
• Если мастер выходит из строя, приложение переключается на слейв.
• Мы в это время поднимаем сломанный сервер и превращаем его в слейв (как это правильно сделать).
Курс-професія "Копірайтер" від Skvot.
40 занять — і ти з упевненістю, скілами та портфоліо зможеш тиснути Apply на вакансії копірайтера.Досвідом і ключами поділяться 2 лекторки та запрошені спікери.
Детальніше про курс

Таким образом, в новой схеме мастер и слейв поменялись местами, а приложение (то есть его пользователи) не заметило никаких проблем.

Репликацию стоит использовать только как механизм резервирования. Не для масштабирования под нагрузки.

Шардинг

Шардинг — это принцип масштабирования базы данных, когда данные разделяются по разным серверам. В нашем распоряжении есть два подхода:

Вертикальный шардинг

Его стоит использовать в первую очередь. Это простое распределение таблиц по серверам. Например, вы помещаете таблицу users на одном сервере, а таблицу orders на другом. В этом случае группы таблиц, по которым выполняются JOIN, должны находится на одном сервере.

Горизонтальный шардинг

Этот тип шардинга следует использовать следующим этапом. На этом этапе очень большие таблицы, которые перестают помещаться на одном сервере, разделяют на части и помещают разные их части на разных серверах. Это усложняет логику приложения, однако мир еще не придумал лучших механизмов масштабирования.

Шардинг — единственный подход для масштабирования действительно больших данных.

Другие задачи

Следует отметить, что есть задачи, с которым MySQL справляется крайне плохо. Один из примеров — выборки уникальных значений в разных диапазонах. Либо полнотекстовый поиск.

Обратите внимание на Handlersocket, который может стать заменой любого NoSQL-решения, в случае если оно используется для простых Key-Value операций.

MySQL — мощное, но не универсальное решение. Redis, Elastic и другие технологии помогут решить дополнительные задачи.

Самое важное

MySQL вместе с современными подходами к оптимизации и масштабированию — это мощная платформа для построения огромных систем. Не забывайте использовать другие технологии для смежных задач, c которыми MySQL справляется не так эффективно.