Правила планирования федеративных серверов баз данных
Процесс построения федерации серверов баз данных включает в себя разработку набора распределенных секционированных представлений, используемых для распределения данных по серверам. Секционирование дает хорошие результаты, если строение таблиц в базе данных позволяет поделить их на одинаковые секции так, чтобы большинство строк, к которым обращается любая из инструкций SQL, были бы размещены на одном федеративном сервере. Таблицы разбиваются на кластеры связанных элементов. Предположим, например, что записи заказа ссылаются на таблицы Orders, Customers и Parts, а также на все таблицы, которые ведут запись связей между заказчиками, заказами и деталями. Секционирование будет работать наилучшим образом, если все строки в логическом кластере можно будет разместить на одном федеративном сервере.
Симметричные секции
Наиболее эффективно секционирование работает в случае, если все таблицы в базе данных могут быть секционированы симметрично следующим образом:
Взаимосвязанные данные размещаются на одном федеративном сервере таким образом, чтобы большинство инструкций SQL, направленных к нужному федеральному серверу, минимально нуждалось в данных, размещенных на других серверах, или вообще не нуждалось в них. Цель проектирования распределенных секционированных представлений можно сформулировать, как правило 80/20: проектируйте секции таким образом, чтобы большинство инструкций SQL обращалось к федеральному серверу, содержащему не менее 80 процентов требуемых данных, а на распределенные запросы приходилось бы 20 или меньше процентов данных. В качестве хорошей проверки достижимости этой цели рекомендуется посмотреть, позволяет ли секция разместить на одном федеративном сервере все строки внешних ключей со всеми их ссылками. Базы данных, структура которых позволяет достичь указанной цели, являются хорошими кандидатами на секционирование.
Данные секционируются по федеративным серверам равномерно.
Предположим, например, что компания поделила Северную Америку на регионы. Каждый работник работает в одном регионе; заказчики совершают большинство покупок в штате или провинции, где живут. Таблицы регионов и работников секционируются между регионами. Данные о заказчиках секционируются между регионами, с учетом штатов или провинций. Хотя некоторые запросы требуют данных из нескольких регионов, большинство запросов нуждается в данных с сервера одного региона. Приложения направляют инструкции SQL на федеративный сервер с данными того региона, который был определен из контекста входных данных.
Асимметричные секции
Хотя идеальными секциями были бы симметричные секции, большинство приложений имеют сложные схемы доступа к данным, не позволяющие осуществить симметричное секционирование. При асимметричном секционировании некоторым федеративным серверам приходится назначать более масштабные роли, чем другим. Например, в базе данных могут быть секционированы лишь некоторые из таблиц, а остальные таблицы, которые не могут быть секционированы, приходится оставлять на исходном сервере. Асимметричное секционирование позволяет добиться большей части производительности, возможной во время симметричного секционирования, и при этом имеет следующие важные преимущества:
С помощью асимметричного секционирования некоторых таблиц можно значительно улучшить производительность баз данных, которые не могут быть секционированы симметрично.
Большую существующую систему можно успешно секционировать посредством серии последовательных, асимметричных улучшений. На каждом из шагов для секционирования выбираются таблицы, секционирование которых даст на данном этапе наибольший прирост производительности.
При асимметричном подходе некоторые таблицы, не соответствующие схеме секционирования, как правило, остаются на первоначальном сервере. Производительность этих оставшихся таблиц обычно более высокая, чем та, что наблюдалась в первоначальной системе, поскольку распределенные таблицы перемещаются на федеративные серверы и, таким образом, сокращается загрузка первоначального сервера.
Многие базы данных могут быть секционированы несколькими способами. Для реализации должны выбираться те конкретные секции, которые наилучшим образом отвечают требованиям типичного диапазона инструкций SQL, выполняемых на уровне бизнес-служб.