Экспорт (0) Печать
Развернуть все
6 из 7 оценили этот материал как полезный - Оценить эту тему

Федерации в базе данных SQL Windows Azure (прежнее название — SQL Azure)

Обновлено: Март 2014 г.

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

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

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

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

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

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

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

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

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

Диаграмма логической модели для федераций Диаграмма физической модели федераций

Вопросы проектирования

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

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

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

Перспективы открытой спецификации

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

См. также

Была ли вам полезна эта информация?
(1500 символов осталось)
Спасибо за ваш отзыв

Добавления сообщества

ДОБАВИТЬ
Показ:
© 2014 Microsoft. Все права защищены.