Первое знакомство с федерациями SQL Azure 

Что же такое федерации в базах данных SQL Azure? Я думаю, что сам термин база данных не требует объяснений, в отличие от термина федерации. Согласно определению федеративная система баз данных – это система, которая позволяет прозрачно интегрировать несколько автономных систем баз данных в единую федеративную систему баз данных. Автономные системы баз данных объединены в единую сеть и могут быть географически децентрализованы. Соответственно федерации в SQL Azure это способ использовать SQL Azure как федеративную систему баз данных.

Рисунок 1. Доступ к облачной системе баз данных.

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

Рисунок 2. Доступ к облачной федеративной системе баз данных.

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

Проблема высоконагруженной базы данных
Давайте рассмотрим проблему высоконагруженных баз данных как таковых. Допустим у нас есть приложение, которое работает с базой данных. Пока мы оперируем небольшими объемами информации - наша база работает быстро. Но, пройдет время, и данных в базе станет больше, следовательно, станет вопрос оптимизации SQL запросов. Хорошо, теперь запросы оптимизированы, и мы вернулись к приемлемой скорости работы базы. Но, пройдет еще время, и опять мы накопим большой объем данных, что приведет к падению производительности. В этой ситуации может стать вопрос о внедрении кэширования результатов выборки. Мы внедрим кэширование и опять вернем показатели производительности в допустимые интервалы. К сожалению, на данном этапе у нас кончились козыри, и, когда мы опять выйдем за пределы допустимых значений показателей производительности, у нас нечем будет крыть. Но это не совсем так. Для разграничения нагрузки на базу данных мы можем использовать механизм федераций, который поставляется совместно с SQL Azure.

Использование федераций в SQL Azure

Поскольку мы говорим об облачных вычислениях, неотъемлемой частью которых является простота масштабирования решения, то способом увеличения производительности нашей базы выберем увеличение количества серверов, которые эту базу обслуживают. Распределяя базу данных по нескольким серверам мы уменьшаем нагрузку на каждый из них, и это логично. Поскольку еще одной неотъемлемой частью облака есть доступность, то важно заметить, что любое разнесение базы по серверам абсолютно не принуждает нас выключать сервер баз данных. Как только мы запустили процесс разнесения базы на несколько узлов, система сама сделает копию базы, разобьёт ее согласно нашим требованиям и распределит по такому количеству серверов, которое мы захотим. Естественно этот процесс займет определенное время, но, пока это будет происходить, наша база будет оставаться доступной и будет обрабатывать запросы пользователей, а как только процесс распределение базы будет завершен, система SQL Azure сама перенаправит все новые запросы пользователей на множество серверов входящих в состав федерации.

Преимущества федераций

Давайте рассмотрим как происходит распределение данных по участникам федерации и за счет чего достигается увеличение производительности. Распределение данных по участникам федерации идет путем разнесения данных из одной или нескольких таблиц по участникам федерации. Рассмотрим ситуацию на примере телефонного справочника, который позволяет используя фамилию абонента найти его телефон. Количество записей в таком справочнике будет очень большим. Чем больше записей в таблице, тем больше размер индекса по данной таблице. Чем больше размер индекса, тем медленнее по нему происходит поиск. Теперь представим, что этим справочником пользуются ежедневно миллионы пользователей, совершая миллионы запросов. Также следует учитывать, что данный справочник регулярно обновляется, в него добавляются новые записи и изменяются уже существующие.
Используя федерации SQL Azure мы можем разнести наш справочник на несколько баз данных, например таким образом как показано на рисунке 3.

Рисунок 3. Распределение справочника абонентов по нескольким участникам федерации.

Когда мы распределим нашу базу по нескольким серверам мы получим прирост производительности за счет следующих факторов:

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

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

Типичный сценарий применения федераций
Пример эффективного использования федераций можно проиллюстрировать при помощи компании, которая занимается продажей SaaS решений. Допустим у нас есть компания, которая предоставляет своим пользователям в аренду какую либо CRM систему. Под каждого клиента мы будем создавать отдельную организацию, в рамках которой будут работать все его пользователи. Поскольку сама CRM система у нас остается одинаковой, для всех пользователей всех клиентов, то все они работают в рамках одной схемы базы данных. Но, также нам необходимо агрегировать информацию о существующих пользователях CRM системы, для целей выставления счета каждому клиенту. Опираясь на эти требования можно построить следующий план использования федерации:

1. Таблицы со списками клиентов мы федерировать не будем. Эти таблицы будут продублированы на каждом участнике федерации.
2. Таблицы со списками пользователей клиентов, а также со всеми данными, которые они держат в рамках свой организации мы будем федерировать. Ключом для федерации мы будем использовать уникальный ИД организации клиента.

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

В заключение

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