Планирование мощностей баз данных

Практически каждый динамический веб-сайт хранит информацию в какой-либо базе данных. А это означает, что мощности базы данных тоже необходимо планировать. В мире LAMP наибольшей популярностью обладают базы данных MySQL и Postgres; впрочем, Oracle, Microsoft SQL Server и множество других баз данных используются в bаск-еnd-подсистеме многих успешных сайтов.

Кроме базовой серверной статистики также имеется ряд специфических метрик баз данных, которые тоже желательно отслеживать:

  • Количество запросов в секунду (SELECT, INSERT, UPDATE и DELETE).
  • Текущее количество открытых подключений.
  • Задержка репликации.
  • Частота попаданий в кэш.

Планирование мощностей баз данных, особенно в кластерах, бывает весьма непростым делом. Выявление потолков быстродействия баз данных затрудняется тем, что некоторые скрытые «ловушки» могут проявляться только в особых граничных случаях.

Например, в прошлом в Flickr предполагалось, что базы данных, работающие на некоторой аппаратной платформе, обладают потолком в X запросов в секунду, а после прохождения этого потолка наступает неприемлемое снижение производительности. Однако позднее сотрудники с удивлением обнаружили, что некоторые запросы нормально выполняются для пользователей, у которых не более 10 000 фотографий, но резко замедляются для пользователя, имеющего более 100 000 фотографий (да, на Flickr есть пользователи, загружающие более ста тысяч фотографий!) Тогда мы переопределили потолки для сервера базы данных, обслуживающего пользователей с большим количеством фотографий. Такого рода «творческое отслеживание» мощностей и производительности практически обязательно для баз данных; оно подчеркивает, насколько важно понимать особенности реального использования баз данных вне контекста системной статистики.

На этой стадии я должен еще раз повторить замечание, относившееся к настройке производительности. Как упоминалось в книге Джереми Заводны и Дерека Боллиннгa High Performance MySQL, производительность баз данных часто сильнее зависит от схем и запросов, чем от скорости оборудования. По этой причине разработчики и администраторы баз данных направляют первоочередные усилия на оптимизацию схем и запросов, зная, что это может кардинально отразиться на производительности базы данных. В свою очередь, это обстоятельство отражается на потолках базы данных. Сегодня вы думаете, что вам нужны 10 серверов баз данных для обслуживания 20 000 запросов в секунду, а завтра выясняется, что можно обойтись всего 5, потому что вы (или ваши программисты) смогли оптимизировать наиболее частые (или высоко затратные) запросы.