Конкурс:Мистер лето

[шпунтик]

Шардинг, партиционирование, репликация - зачем и когда?
Многие разработчики крупных (что весьма относительно) проектов приходят к выводу о том, что один единственный сервер базы данных никак не сможет справится с нагрузками. Это может быть как на этапе проектирования, так и на этапе роста - не важно. Вопрос в том, какую стратегию выбирать, если Вы уверены, что столкнетесь с такой ситуацией!

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

[шпунтик]

Суть проблемы
Для того, что-бы сделать какой-то выбор, Вам необходимо иметь характеристики Вашей проблемы. Проблема - сервер не может… - это не проблема. Существуют два предела, в которые могут уткнуться сервера баз данных:

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

[шпунтик]

Проблема чтения данных - Что же делать дальше?
Итак, Вы оптимизировали запросы и конфигурационные параметры, как могли
(полезные статьи: оптимизация запросов к бд,оптимизация mysql, оптимизация postgres).
Что же делать дальше?

[шпунтик]

Партиционирование таблиц
Именно на этот вариант стоит посмотреть сперва. Партиционирование (partitioning) - это разбиение больших таблиц на логические части по выбранным критериям. Звучит сложно, но на практике все просто.

Скорее всего у Вас есть несколько огромных таблиц (обычно всю нагрузку обеспечивают всего несколько таблиц СУБД из всех имеющихся). Причем чтение в большинстве случаев приходится только на самую последнюю их часть (т.е. активно читаются те данные, которые недавно появились). Примером тому может служить блог - на первую страницу (это последние 5…10 постов) приходится 40…50% всей нагрузки, или новостной портал (суть одна и та же), или системы личных сообщений… впрочем понятно. Партиционирование таблицы позволяет базе данных делать интеллектуальную выборку - сначала СУБД уточнит, какой партиции соответствует Ваш запрос (если это реально) и только потом сделает этот запрос, применительно к нужной партиции (или нескольким партициям). Таким образом, в рассмотренном случае, Вы распределите нагрузку на таблицу по ее партициям. Следовательно выборка типа “SELECT * FROM articles ORDER BY id DESC LIMIT 10” будет выполняться только над последней партицией, которая значительно меньше всей таблицы.

Многие СУБД поддерживают партиционирование на том или ином уровне, например:

Партиционирование в Mysql - отлично реализовано на уровне СУБД (убедитесь, что Ваша версия >= 5.1)
Партиционирование в Postgres - не так хорошо, но все же возможность есть

[шпунтик]

Репликация
К этому пункту стоит переходить, только после рассмотрения предыдущего. Если Вы снова упираетесь в ресурсы, рассмотрите возможность репликации. Репликация - это синхронное/асинхронное копирование данных с ведущих серверов на ведомые (или возможно тоже ведущие) сервера. Ведущие сервера называют мастерами (master), ведомые - слейвами (slave). Вариантов репликации бывает несколько, но для решения проблемы чтения, Вам понадобится master-slave репликация.

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

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

Репликация также помогает изолировать нагрузку. Если у Вас есть проблемные тяжелые запросы, которые выполняются не так часто, но несут за собой промедления работы всей СУБД, выносите их на слейвы.

[шпунтик]

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

Рассмотрим пример. Пусть у нас есть приложение с регистрацией пользователей, которое позволяет писать друг другу личные сообщения. Допустим оно очень популярно и много людей им пользуются ежедневно. Естественно, что таблица с личными сообщениями будет намного больше всех остальных таблиц в базе (скажем, будет занимать 90% всех ресурсов). Зная это, мы можем подготовить для этой (только одной!) таблицы выделенный сервер помощнее, а остальные оставить на другом (послабее). Теперь мы можем идеально подстроить сервер для работы с одной специфической таблицей, постараться уместить ее в память, возможно, дополнительно партиционировать ее и т.д. Такое распределение называется вертикальным шардингом.

Что делать, если наша таблица с сообщениями стала настолько большой, что даже выделенный сервер под нее одну уже не спасает. Необходимо делать горизонтальный шардинг - т.е. разделение одной таблицы по разным ресурсам. Как это выглядит на практике? Все просто. На разных серверах у нас будет таблица с одинаковой структурой, но разными данными. Для нашего случая с сообщениями, мы можем хранить первые 10 миллионов сообщений на одном сервере, вторые 10 - на втором и т.д. Т.е. необходимо иметь критерий шардинга - какой-то параметр, который позволит определять, на каком именно сервере лежат те или иные данные.

Обычно, в качестве параметра шардинга выбирают ID пользователя (user_id) - это позволяет делить данные по серверам равномерно и просто. Т.о. при получении личных сообщений пользователей алгоритм работы будет такой:

1 Определить, на каком сервере БД лежат сообщения пользователя исходя из user_id
2 Инициализировать соединение с этим сервером
3 Выбрать сообщения
Задачу определения конкретного сервера можно решать двумя путями:

1 Хранить в одном месте хеш-таблицу с соответствиями ”пользователь=сервер”. Тогда, при определении сервера, нужно будет выбрать сервер из этой таблицы. В этом случае узкое место - это большая таблица соответсвия, которую нужно хранить в одном месте. Для таких целей очень хорошо подходят базы данных ”ключ=значение”
2 Определять имя сервера с помощью числового (буквенного) преобразования. Например, можно вычислять номер сервера, как остаток от деления на определенное число (количество серверов, между которыми Вы делите таблицу). В этом случае узкое место - это проблема добавления новых серверов - Вам придется делать перераспределение данных между новым количеством серверов.
Для шардинга не существует решения на уровне известных платформ, т.к. это весьма специфическая для отдельно взятого приложения задача.

Естественно, делая горизонтальный шардинг, Вы ограничиваете себя в возможности выборок, которые требуют пересмотра всей таблицы (например, последние посты в блогах людей будет достать невозможно, если таблица постов шардится). Такие задачи придется решать другими подходами. Например, для описанного примера, можно при появлении нового поста, заносить его ID в общий стек, размером в 100 элементом.

Горизонтальный шардинг имеет одно явное преимущество - он бесконечно масштабируем.

[шпунтик]

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

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

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

[шпунтик]

Итог
-Если у Вас есть проблемы с пропускной способностью БД, не спешите покупать новый дорогой сервер
-Анализируйте и изолируйте проблемные места (большие таблицы, тяжелые запросы)
-Решений горизонтального масштабирования БД несколько - выбирайте оптимальное
-Репликация - не единое доступное решение, анализируйте проблему
-Шардинг - горизонтально масштабируемое решение, которое практически не имеет ограничений, но требует грамотного архитектурного решения
-Продумайте возможность гибридного решения (совмещение вертикального шардинга и репликации)