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

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

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

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

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

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

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

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

Кэширование

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

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

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

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

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

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

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

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

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

Репликация

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

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

  • Использовать master-slave репликацию для каждого сервера БД.
  • Приложение всегда работает только с мастером.
  • Если мастер выходит из строя, приложение переключается на слейв.
  • Мы в это время поднимаем сломанный сервер и превращаем его в слейв ( как это правильно сделать).

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

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

Шардинг

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

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

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

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

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

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

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

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

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

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

Самое важное

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


Подпишитесь на Хайлоад с помощью Google аккаунта
или закройте эту хрень