Проектирование распределенных секционированных представлений
Чтобы спроектировать набор распределенных секционированных представлений для реализации федерации серверов баз данных, необходимо выполнить следующее:
Определите шаблон инструкций SQL, выполняемых приложением
Определите, каким образом таблицы связаны друг с другом.
Сопоставьте частоту инструкций SQL с секциями, определенными при анализе внешних ключей.
Определите правила маршрутизации инструкций SQL.
Шаблон инструкций SQL, выполняемых приложением
Создайте список типичных инструкций SQL, которые будут выполняться приложением в течение большей части работы. Разбейте этот список на категории SELECT, UPDATE, INSERT и DELETE и отсортируйте инструкции в каждой из них по частоте выполнения. Если инструкции SQL ссылаются на хранимые процедуры, включайте в список базовые инструкции SELECT, INSERT, UPDATE и DELETE, содержащиеся в этих хранимых процедурах. Если секционируется существующая база данных SQL Server, для получения этого списка можно воспользоваться Приложение SQL Server Profiler.
Упорядочивание инструкций SQL по частоте использования вызвано необходимостью получения разумного их усреднения при типичной оперативной обработке транзакций (OLTP) или работе базы данных веб-узла, в которых применение распределенных секционированных представлений наиболее эффективно. Такие системы характеризуются наличием ряда инструкций SQL, которые извлекают сравнительно небольшие объемы данных по сравнению с запросами, применяемыми в системах принятия решений (или OLAP). Если все инструкции SQL работают с небольшими объемами данных, остается изучить частоту вызова каждой из них, чтобы примерно определить объем данных, проходящих по системе. Однако многие системы содержат некоторое число инструкций SQL, которые запрашивают большое количество данных. Можно также дополнительно оценить то, каким образом влияют запросы, работающие с большими объемами данных.
Связи между таблицами
Целью является найти кластеры таблиц, которые могут быть секционированы по одному измерению (например, по номеру детали или по коду отдела), чтобы все строки, относящиеся к конкретным значениям этого измерения, оказались на одном сервере. Например, может выясниться, что один из способов секционирования базы данных — по региону. Чтобы поддержать эту возможность, даже таблицы, не содержащие в своем ключе кода региона, должны иметь возможность секционирования каким-либо способом, относящимся к региону. Даже если в таблице Customer нет столбца кода региона, но регионы определены в виде коллекции штатов и провинций, столбец Customer.StateProvince применим для секционирования клиентов по региональному признаку.
Поскольку явные или неявные внешние ключи определяют связи между таблицами, они являются важнейшими элементами при поиске способа секционирования данных. Изучите явные определения внешних ключей, чтобы выяснить, как часто запросы будут пользоваться строками одной таблицы для поиска строк в другой. Кроме того, изучите неявные внешние ключи, а также способы, которыми инструкции SQL пользуются значениями в строках одной таблицы для ссылки на записи в другой при выполнении операций соединения, даже если явные определения ключей отсутствуют. Поскольку неявные внешние ключи непосредственно в составе схемы базы данных не определены, следует просмотреть инструкции SQL, выдаваемые приложением, чтобы выяснить, используются ли в инструкциях, соединяющих таблицы, неключевые столбцы. Такие неявные внешние ключи обычно индексируются, чтобы повысить производительность операций соединения. Таким образом, следует также просмотреть индексы, определенные в базе данных.
Частота использования инструкций SQL применительно к секциям
Сопоставьте частоту инструкций SQL с секциями, определенными при анализе внешних ключей. Выберите секционирование, которое лучше всего поддерживает весь набор инструкций SQL, используемых в приложении. Если некоторая часть таблиц может быть секционирована более чем одним способом, по частоте использования инструкций SQL определите, какие из секций удовлетворяют большему числу инструкций. Таблицы, которые чаще всего указываются в инструкциях SQL, нужно секционировать в первую очередь. Выстройте последовательность секционирования таблиц, основываясь на частоте ссылок на них.
Шаблон инструкций SQL также влияет на принятие решения о секционировании таблиц:
Таблица секционируется, если более 5% инструкций, ссылающихся на нее, — это инструкции INSERT, UDATE или DELETE и если таблица может быть секционирована по выбранному измерению.
Сохраните полные копии таблиц на каждом из серверов, если менее 5% инструкций, ссылающихся на таблицу, — инструкции INSERT, UPDATE или DELETE. Также необходимо определить, каким образом производятся изменения, чтобы обновлялись все копии таблицы. Если требуется высокая целостность транзакций, можно создать триггеры, выполняющие распределенное обновление всех копий в контексте распределенной транзакции. Если высокая целостность не требуется, можно для переноса изменений от одной копии таблицы на все остальные воспользоваться механизмами репликации SQL Server.
Не секционируйте и не копируйте таблицу, если менее 5% инструкций, ссылающихся на нее, являются инструкциями INSERT, UDATE или DELETE, а таблица не может быть секционирована по выбранному измерению.
Правила маршрутизации инструкций SQL
Правила маршрутизации должны быть способны определить, какой из серверов наиболее эффективно обработает каждую из инструкций SQL. Они должны установить связь между контекстом пользовательского ввода и сервером, который содержит данные, необходимые для выполнения инструкции. Приложения должны быть способны принять данные, введенные пользователем, и сопоставить их с правилами маршрутизации, чтобы определить, какой из серверов должен обработать данную инструкцию SQL.