Поделиться через

Федерации в SQL Azure

  • Статья

Федерации дают возможность использовать подходы распределения баз данных по серверам в SQL Azure. Подход распределения по серверам используется для постройки многих популярных веб сайтов, таких как социальные сети, сайты аукционов и масштабируемые приложения для электронной почты (такие как Facebook, eBay и Hotmail). Принося в SQL Azure возможность распределения по серверам, федерации позволяют строить масштабируемые и эластичные слои баз данных и сильно облегчить разработку и управление современными облачными приложениями ориентированными на множественное владение / множественную аренду.
Представьте стандартное многослойное приложение: в таком приложении обычно выделяются слои веб серверов и серверов бизнес логики с целью их последующего масштабирования. В то время как варьируется спрос на приложение, администраторы добавляют или удаляют новые экземпляры серверов для обслуживания слоев передних веб серверов и серверов бизнес логики, чтобы справиться с разницей в нагрузке. На платформе Windows Azure этого легко достичь с помощью легкой инициализации новых мощностей и моделью оплаты облака на основе принципа «плати только за то, что использовал».
Обычно слои баз данных не поддерживали масштабирование, но федерации SQL Azure позволяют их масштабировать. Федерации позволяют масштабировать слой баз данных таким образом, как бы вы масштабировали слои передних веб серверов и серверов бизнес логики, основываясь на нагрузке на приложение. С помощью федераций приложения могут увеличить или сократить количество рабочих серверов, которые обслуживают базу данных, без какого-либо простоя.

Рисунок 1: Федерации SQL Azure могут масштабировать базу данных подобно масштабированию слоев передних веб серверов и серверов бизнес логики
Федерации предоставляют приложениям следующие возможности:

  • Неограниченное масштабирование:

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

  • Экономия в результате эластичности предложения:

Федерации предлагают легкий способ перераспределения данных (repartitioning of data) без простоя, что делает соотношение цены и производительности эластичным. Приложения, построенные с помощью федераций, могут легко приспосабливаться к изменениям в своей рабочей нагрузке с помощью перераспределения данных. Перераспределение данных и модель «плати только за то, что использовал» позволяют администраторам приложения легко оптимизировать нагрузку и стоимость решения путем изменения количества баз данных и рабочих серверов, которые они используют при нагрузке в каждый конкретный момент времени. И опять-таки, нет никакого простоя во время прохождения изменений.

  • Упрощенный процесс разработки и администрирования масштабируемых систем баз данных

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

  • Упрощенное множественное владение / множественная аренда:

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

**
**Рисунок 2: Федерации предоставляют гибкую модель аренды

Кому нужны федерации?

С помощью федераций можно масштабировать разные типы баз данных. Вот несколько примеров:

  • Продавцы программного обеспечения, которые используют SaaS решения:

Много приложений разрабатываются на основе модели «один арендатор – одна база данных». Но для современных облачных приложений нужна гибкая арендная модель. Статическое расположение арендаторов требует большего внимания к себе, а в случае с облачной инфраструктурой одноэкземплярные (single node) решения могут лимитировать возможности масштабирования, в частности, от большого количества небольших клиентов до очень больших потребителей. В случае федераций ISV (независимые поставщики программного обеспечения) не должны использовать статическое расположение арендаторов. Федерированные слои баз данных легко приспосабливаются к разным типам арендаторов и характеристикам нагрузки, при этом продолжая расти вместе с приходом новых арендаторов в систему.
Рассмотрим пример независимого поставщика программного обеспечения, который предоставляет приложение для управления общением с клиентами. Некоторые арендаторы начинают использование приложения с маленьким количеством профилей клиентов, а у некоторых могут быть очень большие портфолио клиентов. Понятие мало или много клиентов тут слегка размыто, в моей практике работы с SaaS решениями база клиентов размером до 100 MB обычно классифицировалась как маленькая, в то время как базу клиентов размером от 1 GB уже можно классифицировать как большую. Данная классификация зависит от множества критериев, и заострять особое внимание на этом мы не будем. В случае использования федерации, арендаторы с маленьким портфолио могут начать использование приложения как часть мульти-арендной федерации, но с ростом количества клиентов могут стать выделенными участниками федерации (dedicated federation member) и перейти на модель один арендатор – одна база данных. В случае, если портфолио выйдет за рамки лимита одной базы данных, арендатор может подняться до мощностей, которые обычно использовались бы на нескольких выделенных участников. И опять-таки, во время роста арендатор не будет испытывать простои.

  • Масштабирование баз данных веб приложений

Приложения в вебе постоянно сталкиваются с проблемами планирования изменяющегося и растущего трафика. Пики, спады, взрывы и дневной прилив пользователей – с помощью федераций приложения могут справляться с вариацией в нагрузке, увеличивая или уменьшая мощности, которые они используют в SQL Azure.
Например, представим сервис, который занимается хостингом блогов. В любой конкретный день пользователи создают новые посты в блогах, просматривают другие блоги и оставляют комментарии. Каждый день возможна ситуация, при которой конкретный пост станет очень популярным и привлечет большое количество посетителей. Однако сложно предугадать, какой именно блог станет популярным, поэтому использование статического расположения данных блогов будет неэффективно: некоторые из ваших серверов могут оказаться перегружены, в то время как некоторые будут простаивать. Федерации помогут справиться с изменениями в трафике с помощью перераспределения данных, при этом не требуя времени простоя на проведение операции. С ростом нагрузки приложение продолжит вводить в использование новые рабочие экземпляры, таким образом достигая неограниченного масштабирования. А модель оплаты «плати только за то, что использовал» SQL Azure в сочетании с федерациями означает, что вам не нужно тратить много денег на поддержку постоянного запаса вычислительных мощностей на случай пиковой нагрузки или временного «взрыва» в трафике, - вы будете оплачивать реально потребляемые ресурсы.

  • NoSQL приложения

Приложения, построенные по технологии NoSQL, также могут получить выгоду от федераций в SQL Azure. Федерации добавляют много свойств NoSQL в платформу SQL Azure, такие как, например, подход распределения баз данных по серверам (sharding pattern).
Другая выгода от федераций – это TempDB, которая сейчас идет с каждой базой данных SQL Azure. Федерации предоставляют все возможности баз данных SQL Azure для хранения неструктурированных или частично структурированных данных через такие типы данных, как XML или двоичные данные (binary data).

Архитектура федераций

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

Федерации

Федерации – это такие же объекты в пользовательской базе данных, как и другие объекты типа представлений (views), хранимых процедур или триггеров. Однако объект федерации является уникальным в одном отношении: он позволяет передавать части ваших схем (schema) и данных в базы данных, управляемые другими системами, называемыми участниками федерации (federation members). Федерация представляет собой схему федерации, которая включает ключ распределения федерации, тип данных и стиль распределения. SalesDB на Рисунке 2 является пользовательской базой данных с федерациями. Возможно также создавать несколько федераций для удовлетворения разных потребностей в масштабировании отдельных наборов данных. Например, вы можете выносить заказы в одну федерацию под SalesDB, а товары и все связанные с ними объекты – в другую.

Корень федерации

Корень федерации указывает базу данных, которая содержит объект федерации. SalesDB на Рисунке 3 является корнем федерации. Корневая база данных – это центральный репозиторий информации о распределении рассредоточенных данных.

Участники федерации

Федерация использует множество управляемых системой баз данных SQL Azure рассредоточенных именных участников федерации. Участники федерации предоставляют вычислительные мощности и место под хранение данных. Собрание всех участников федерации представляет собой собрание всех данных федерации. Управление участниками федерации происходит динамически в процессе перераспределения данных. Администраторы принимают решение о том, сколько участников федерации должно использоваться в выбранный момент времени с помощью операций перераспределения данных федерации.

Рисунок 3: SalesDB – корневая база данных с многими федерациями

 

Ключ распределения федерации

Ключ распределения федерации – это ключ, используемый для распределения данных в федерации. В определении федерации ключ распределения представлен 3 свойствами:

    • Ярлык, который используется для обращения к ключу
    • Тип данных, который обозначает действительный домен данных (data domain) для распределения, например, uniqueidentifier или bigint
    • Тип данных, который обозначает метод распределения данных, например, ‘range’

Атомарная единица федерации

Атомарная Единица (АЕ) федерации представляет собой все данные, которые относятся к одному экземпляру ключа федерации. Атомарная единица содержит все строки во всех федерированных таблицах с одним и тем же значением ключа федерации. Атомарные единицы гарантированно остаются вместе на одном участнике федерации и никогда НЕ РАСПРЕДЕЛЯЮТСЯ на разные участники. Участники федерации могут содержать много атомарных единиц. Например, при ключе распределения федерации tenant_id атомарная единица ссылается на все строки по всем федерированным таблицам со значением tenant_id=55. Рисунок 4 иллюстрирует суть атомарных единиц федерации.

Рисунок 4: Атомарные единицы федерации

Федерированные таблицы

Федерированные таблицы – это таблицы, которые содержат данные, распределенные в федерации. Федерированные таблицы создаются на участниках федерации и содержат ключ распределения федерации, аннотированный конструкцией:

FEDERATED ON (federation_distribution_key = column_name)
во время создания таблицы. Больше информации об этом можно найти в документации для оператора CREATE TABLE в SQL Azure. На Рисунке 5 федерированные таблицы выделены голубым цветом.

Таблицы ссылок

Таблицы ссылок – это таблицы, которые содержат дополнительную информацию для оптимизации запросов выборки в федерациях. Таблицы ссылок создаются на участниках федерации и не содержат аннотации FEDERATED ON. Такие таблицы обычно содержат небольшое количество дополнительной информации, полезной для запросов, например, почтовые коды, которые клонируются на каждом участнике федерации. На Рисунке 5 таблицы ссылок выделены зеленым цветом.

Центральные таблицы

Центральные таблицы – таблицы, которые создаются в корне федерации для кэшированных данных или же данных с низким трафиком, которые не нужно распределять. Хороший пример – метаданные или таблицы конфигурации, которые редко запрашиваются приложением. На Рисунке 5 центральные таблицы выделены оранжевым цветом.

Рисунок 5: Типы таблиц в федерации. Федерированные таблицы – синий; Таблицы ссылок – зеленый; Центральные таблицы - оранжевый

 

Онлайн операции перераспределения (Online Repartitioning)

Одно из фундаментальных преимуществ федераций – это возможность проводить операции перераспределения объектов федерации в режиме реального времени. Это можно сделать с помощью команд ALTER FEDERATION T-SQL. Например, перераспределяя Orders_Fed с помощью операции SPLIT, администраторы могут переместить данные на новые участники федерации без простоя и расширить вычислительные мощности с 1 до 2 участников федерации. Как показано на Рисунке 6 - участники федерации помещаются в отдельные узлы и дают большой выигрыш в производительности для приложения.

Рисунок 6: Операция SPLIT создает 2 новых участника федерации в фоне и делает реплики всех данных с участника, который был источником данных, на нового участника

Как создать федерацию?

Мы будем использовать SQL Azure Management Portal для иллюстрации необходимых действий. Чтобы попасть на портал управления SQL Azure, нужно кликнуть на кнопку "Manage" под SQL Azure на портале Windows Azure Management Portal или просто зайти по вашему полному имени сервера SQL Azure в браузере с HTTPS:// заголовком, например:
https://<sql_azure_server_name>.database.windows.net/

Создание федераций

 Чтоб создать федерацию на портале SQL Azure Management Portal, вы можете нажать на иконку «Новая федерация» на странице баз данных.

Рисунок 7: Создание федерации
Также можно использовать такой T-SQL для создания федерации:
CREATE FEDERATION blogs_federation (id BIGINT RANGE)
Детальную информацию об операторе CREATE FEDERATION можно найти в документации SQL Azure. В общем случае, CREATE FEDERATION создает федерацию и ее первого участника.
Вы можете просмотреть детальную информацию о распределении федерации на странице деталей федерации или используя такой T-SQL:
SELECT * FROM sys.federations fed JOIN sys.federation_member_distributions fedmd ON fed.federation_id=fedmd.federation_id order by range_low 

Рисунок 8: Страница деталей федерации
Развертывание схемы данных на федерации
Объект федерации позволит вам распределить части вашей схемы по участникам федерации. Участники федерации – это обычные базы данных SQL Azure. Чтобы развернуть схему на участнике федерации вместо корневой базы данных, вы должны сначала подключиться к соответствующему участнику федерации. Оператор USE FEDERATION позволит вам сделать это. Информацию об операторе USE FEDERATION можно найти в документации SQL Azure. Как только вы подключились к участнику федерации, вы можете развернуть свою схему на этом участнике федерации, используя обычные операторы, чтобы создать объекты типа таблиц, хранимых процедур, триггеров и представлений. Подключиться и развернуть схему можно также выбрав действие Query > New Query на участнике федерации.

Рисунок 9: Действия над участниками федерации на странице деталей федерации
Вы должны предоставить аннотации к федерациям, в которых будут указаны федерированные таблицы и ключ федерации. Конструкция FEDERATED ON включается в оператор CREATE TABLE именно для этих целей. Таблицы – единственные объекты, которые требуют специальную аннотацию. Никакой другой объект не может быть развернут, используя обычный T-SQL синтаксис SQL Azure.
Вот пример оператора T-SQL CREATE TABLE, который создает федерированную таблицу:

USE FEDERATION blogs_federation(id=-1) WITH RESET, FILTERING=OFF
GO
CREATE TABLE blogs_tbl(
blog_id bigint primary key,
blog_title nvarchar(1024) not null,
...
*) FEDERATED ON (id=blog_id)


*

Рисунок 10: Развертывание схемы при помощи онла��н T-SQL редактора
Масштабирование с помощью федераций
После развертывания своей схемы вы можете масштабировать свою федерацию на других участников федерации, чтобы она смогла справиться с большим трафиком. Это можно сделать на странице деталей федерации с помощью действия SPLIT на портале управления или же использовать такой T-SQL оператор:
ALTER FEDERATION blogs_federation SPLIT AT (id=100)
Операции перераспределения, такие как SPLIT, выполняются онлайн в SQL Azure, так что даже если действие должно занять некоторое время, простоя приложения не будет. Про данную операцию вы можете более подробно прочитать пройдя по ссылке http://msdn.microsoft.com/en-us/library/windowsazure/hh597475.aspx.

Рисунок 11: Действие SPLIT над федерацией
Страница федерация также предоставляет детальную информацию о прогрессе операции SPLIT. После запуска операции SPLIT вы можете обновить окно или же использовать такой T-SQL, чтобы контролировать прогресс выполнения:
*SELECT * FROM sys.dm_federation_operations

*

Рисунок 12: Контроль за действием SPLIT на странице деталей федерации
С увеличением масштаба приложения будет создаваться больше SPLIT точек (SPLIT points). Точнее, с ростом нагрузки на систему, администраторы будут разбивать федерацию на большее количество участников федерации.

Рисунок 13: Страница деталей федерации с полным обзором всех участников федерации
Все вышеперечисленные операции могут быть выполнены с помощью T-SQL. Для полной информации об операторах T-SQL, обращайтесь к онлайн документации по SQL Azure.

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

Давайте рассмотрим на более жизненном примере использование федераций в SQL Azure. Сценарий у нас будет таков – допустим, у нас есть крупный интернет магазин. В этом интернет магазине происходит торговля товарами разного назначения, например бытовой химией, автомобильными аксессуарами, компьютерной электроникой и даже продуктами питания. Нагрузка на наш интернет магазин регулярно растет, и мы принимаем решение использовать федерации в SQL Azure, чтобы разнести базу данных нашего магазина по нескольким серверам и, таким образом, справиться с наплывом посетителей. Поскольку мы торгуем очень разнородными товарами, то логично будет разносить базу по серверам опираясь на принадлежность товара к той или иной категории.
Итак, первым делом, мы создаем саму федерацию:
CREATE FEDERATION shop_federation (shop_id INT RANGE)

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

Для начала необходимо создать таблицу ProductCategory.
CREATE TABLE [Production].[ProductCategory](
[ProductCategoryID] [int] IDENTITY (1, 1) NOT NULL,
[Name] [Name] NOT NULL,
[rowguid] uniqueidentifier ROWGUIDCOL NOT NULL CONSTRAINT [DF_ProductCategory_rowguid] DEFAULT (NEWID()),
[ModifiedDate] [datetime] NOT NULL CONSTRAINT [DF_ProductCategory_ModifiedDate] DEFAULT (GETDATE())
)

А где же тут ключ федерации, спросите вы. Его тут нет, и именно это позволит нам напомнить про одну особенность федераций. Мы не можем подключиться одновременно больше чем к одному участнику федерации. Если бы мы поместили ключ федерации в эту таблицу, то такая простая задача как построение дерева каталога товаров ста��а бы уже не такой простой. Если бы таблица ProductCategory была разнесена по нескольким серверам, то для построения каталога товара нам бы пришлось сперва подключится к первому участнику федерации, выбрать все записи из таблицы, потом ко второму, потом к третьему и т.д. Нам нужно было-бы повторить этот запрос столько раз, сколько у нас участников федерации, и каждый запрос еще и будет сопровождаться открытием и закрытием канала передачи данных. Именно из этих соображений мы не поместили ключ федерации в таблицу ProductCategory, таким образом она будет продублирована на каждом участнике федерации полностью.
Теперь я напомню еще про одну особенность федераций. Поскольку мы решили дублировать таблицу ProductCategory на каждом участнике федерации, то это повлечет за собой дополнительные накладные расходы. Платформа Windows Azure тарифицирует нас согласно суммарному размеру всех участников федераций как одной базы данных. Так как мы решили дублировать таблицу ProductCategory, то итоговый суммарный размер всех участников федерации будет больше, чем была изначальная база данных. Об этом важно помнить.
По аналогии мы создаем таблицу ProductSubcategory.
CREATE TABLE [Production].[ProductSubcategory](
[ProductSubcategoryID] [int] IDENTITY (1, 1) NOT NULL,
[ProductCategoryID] [int] NOT NULL,
[Name] [Name] NOT NULL,
[rowguid] uniqueidentifier ROWGUIDCOL NOT NULL CONSTRAINT [DF_ProductSubcategory_rowguid] DEFAULT (NEWID()),
[ModifiedDate] [datetime] NOT NULL CONSTRAINT [DF_ProductSubcategory_ModifiedDate] DEFAULT (GETDATE())
) FEDERATED ON (shop_id = ProductCategoryID)

В данной ситуации мы добавили в объявление таблицу ключ федерации. Мы это можем сделать по той причине, что в нашем интернет магазине пользователь в один момент времени может просматривать только одну категорию товаров. Для этой категории товаров мы построим список подкатегорий, и все эти подкатегорию гарантированно будут находиться в рамках одного участника федерации.
CREATE TABLE [Production].[Product](
[ProductCategoryID] [int] NOT NULL,
[ProductID] [int] IDENTITY (1, 1) NOT NULL,
[Name] [Name] NOT NULL,
[ProductNumber] [nvarchar](25) NOT NULL,
[MakeFlag] [Flag] NOT NULL CONSTRAINT [DF_Product_MakeFlag] DEFAULT (1),
[FinishedGoodsFlag] [Flag] NOT NULL CONSTRAINT [DF_Product_FinishedGoodsFlag] DEFAULT (1),
[Color] [nvarchar](15) NULL,
[SafetyStockLevel] [smallint] NOT NULL,
[ReorderPoint] [smallint] NOT NULL,
[StandardCost] [money] NOT NULL,
[ListPrice] [money] NOT NULL,
[Size] [nvarchar](5) NULL,
[SizeUnitMeasureCode] [nchar](3) NULL,
[WeightUnitMeasureCode] [nchar](3) NULL,
[Weight] [decimal](8, 2) NULL,
[DaysToManufacture] [int] NOT NULL,
[ProductLine] [nchar](2) NULL,
[Class] [nchar](2) NULL,
[Style] [nchar](2) NULL,
[ProductSubcategoryID] [int] NULL,
[ProductModelID] [int] NULL,
[SellStartDate] [datetime] NOT NULL,
[SellEndDate] [datetime] NULL,
[DiscontinuedDate] [datetime] NULL,
[rowguid] uniqueidentifier ROWGUIDCOL NOT NULL CONSTRAINT [DF_Product_rowguid] DEFAULT (NEWID()),
[ModifiedDate] [datetime] NOT NULL CONSTRAINT [DF_Product_ModifiedDate] DEFAULT (GETDATE()),
CONSTRAINT [CK_Product_SafetyStockLevel] CHECK ([SafetyStockLevel] > 0),
CONSTRAINT [CK_Product_ReorderPoint] CHECK ([ReorderPoint] > 0),
CONSTRAINT [CK_Product_StandardCost] CHECK ([StandardCost] >= 0.00),
CONSTRAINT [CK_Product_ListPrice] CHECK ([ListPrice] >= 0.00),
CONSTRAINT [CK_Product_Weight] CHECK ([Weight] > 0.00),
CONSTRAINT [CK_Product_DaysToManufacture] CHECK ([DaysToManufacture] >= 0),
CONSTRAINT [CK_Product_ProductLine] CHECK (UPPER([ProductLine]) IN ('S', 'T', 'M', 'R') OR [ProductLine] IS NULL),
CONSTRAINT [CK_Product_Class] CHECK (UPPER([Class]) IN ('L', 'M', 'H') OR [Class] IS NULL),
CONSTRAINT [CK_Product_Style] CHECK (UPPER([Style]) IN ('W', 'M', 'U') OR [Style] IS NULL),
CONSTRAINT [CK_Product_SellEndDate] CHECK (([SellEndDate] >= [SellStartDate]) OR ([SellEndDate] IS NULL)),
) FEDERATED ON (shop_id = ProductCategoryID)

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

Расписывать дальнейший процесс создания базы данных уже не имеет смысла, т.к. на этих нескольких таблицах мы увидели, чем нужно руководствоваться в дальнейшем.
Теперь давайте разнесем наше базу на несколько серверов. Для этого выполним команду SPLIT несколько раз:
ALTER FEDERATION shop_federation SPLIT AT (shop_id = 10)
ALTER FEDERATION shop_federation SPLIT AT (shop_id = 2)
ALTER FEDERATION shop_federation SPLIT AT (shop_id = 5)

По выполнению этих команд мы будем иметь 4 участника федерации.

    • shop_id >= 10
    • shop_id >= 5 и shop_id < 10
    • shop_id >= 2 и shop_id < 5
    • shop_id < 2

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

Итого

Использованиe федераций в SQL Azure дает нам следующие преимущества:

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

Использования федераций в SQL Azure имеет следующие недостатки:

  • Нет возможности подключиться к нескольким участникам федерации одновременно.
  • Переключение между участниками федерации требует разрыва соединения с базой.
  • Использование федераций часто приводит к денормализации базы данных.

Из всего вышеприведённого можно сделать следующий вывод – хоть федерации и обладают некоторыми недостатками, но преимущества, которые они приносят в проект, значительно их перекрывают. Возможность масштабировать базу данных в режиме реального времени без простоя, путем отправки простого TSQL запроса уже стоит многих похвал. А главное, что компания Microsoft не планирует останавливаться на достигнутом, и в будущем нас ждет много улучшений и дополнений к уже существующим возможностям.