Экспорт (0) Печать
Развернуть все

Федерации в базе данных SQL Azure

Обновлено: Апрель 2014 г.

Федерации в База данных SQL Microsoft Azure (База данных SQL Azure) позволяют повысить масштабируемость и управлять ограничениями емкости на уровне баз данных приложения. Одна или несколько таблиц в базе данных секционируются горизонтально и разделяются между несколькими базами данных (членами федерации). Этот тип горизонтального секционирования часто называют шардингом. В этом разделе представлены общие сведения о федерациях.

ImportantВажно!
Текущая реализация федераций будет упразднена вместе с уровнями служб Web и Business. Рекомендуется развернуть решения пользовательского сегментирования для обеспечения максимального уровня масштабируемости, гибкости и производительности. Дополнительные сведения о пользовательском сегментировании см. в разделе Горизонтальное масштабирование баз данных SQL Azure.

Федерация представляет собой коллекцию секций базы данных, определяемых схемой распределения федерации, которая называется схемой федерации. Схема федерации определяет ключ распределения федерации, от которого зависит распределение данных по секциям федерации. Ключ распределения федерации должен иметь тип INT, BIGINT, UNIQUEIDENTIFIER или VARBINARY (до 900 байт), он указывает значение диапазона. У федерации может быть только одна схема и только один ключ распределения.

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

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

Хотя члены федерации физически реализованы как базы данных, логически они на уровне приложения представляют собой диапазон значений ключей федерации. Например, логически доступ к базе данных-члену федерации, содержащей строки, связанные со значениями ключа федерации 50–100, осуществляется путем указания значения ключа внутри соответствующего диапазона, а не указания имени базы данных.

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

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

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

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

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

Новая спецификация расширенных функций SQL по сегментированию данных доступна по ссылке Перспектива Microsoft Open Specification. Дополнительные сведения см. в спецификации Федерации баз данных SQL Azure.

См. также

Показ:
© 2014 Microsoft