Локализация данных

Имя таблицы	Фрагменты	Распределение фрагментов по узлам
Служащие	1 2 3	1 1,2 1,3
Завод	a a a	1,2.3 1,2,3 1,2,3
Сырье	A B C	1 2

Очевидно, что для таблицы «Завод» осуществляется дублирование, а для таблицы «Сырье» - расчленение.

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

Иначе говоря, РБД можно представить в виде, показанном на рис. .

Рис. Уровни представления данных в РБД

Сеть в РБД образуют сетевые операционные системы (например, Windows NT, Novell NetWare). В качестве СУБД, изначально предназначавшихся для использования в сети, следует назвать BTrieve, Oracle, Interbase, Sybase, Informix.

Естественно, что для работы в РБД необходимы администраторы РБД и локальных БД, рабочими инструментами которых являются перечисленные словари.

Схема работы РБД показана на рис. 4.

Рис. 4. Схема работы РБД

Пользовательский запрос, определяемый приложением, поступает в систему управления распределенной базы данных (СУРБД) и через сетевую и локальную операционные системы попадает в локальную СУБД. Если запрос связан с локализованными данными, СУБД осуществляет вызов данных из локальной БД, которые поступают пользователю. Если часть данных для выполнения приложения находится в другой локальной БД, локальная СУБД дополнительно через локальные и сетевые операционные системы осуществляет удаленный вызов процедуры (Remote Procedure Call - PRC), после выполнения которой данные передаются пользователю.

В основе распределённых баз данных лежат следующие требования:

• НЕЗАВИСИМОСТЬ ДУБЛИРОВАНИЯ ДАННЫХ. Это свойство СУБД позволяет создавать в узлах сети дубли данных без снижения производительности приложения и без нарушения непротиворечивости данных.

• РАСПРЕДЕЛЕННЫЕ ПРЕДСТАВЛЕНИЯ (views). Представления могут формироваться при выполнении операции соединения (join) таблиц, размещающихся в разных узлах.

• РАСПРЕДЕЛЕННЫЕ ОГРАНИЧЕНИЯ ЦЕЛОСТНОСТИ. Эта функция обеспечивает ссылочную целостность данных. В узлах могут находиться таблицы, зависящие от некоторой таблицы-мастера. При модификации данных таблицы-мастера автоматически модифицируются зависимые таблицы.

• НЕПРЕРЫВНАЯ ОБРАБОТКА (continual operation). Обработка, выполняемая в локальном узле БД, не может быть прервана командами из другого узла. Т.е. в каждом узле обработка выполняется независимо и целиком.

• НЕЗАВИСИМОСТЬ РАЗМЕЩЕНИЯ. Изменение места хранения данных не ведет к изменению работающих с этими данными приложений.

• ОБРАБОТКА РАСПРЕДЕЛЕННЫХ ТРАНЗАКЦИЙ. Обеспечение ограничений целостности поддерживается и при выполнении транзакции, изменяющей несколько узлов.

• ГЛОБАЛЬНАЯ ОБРАБОТКА ВЗАИМОБЛОКИРОВОК И ПРОБЛЕМ, ВОЗНИКАЮЩИХ ПРИ ОДНОВРЕМЕННОМ ДОСТУПЕ К ДАННЫМ. Блокировка данных может выполняться во всех узлах БД. Необходимо выявлять и разрешать ситуации, когда два узла взаимно блокируют друг друга.

• НЕЗАВИСИМОСТЬ ОТ ТИПА КОМПЬЮТЕРОВ, ОПЕРАЦИОННЫХ СИСТЕМ, СЕТЕВЫХ ПРОТОКОЛОВ, ТИПОВ СУБД. Эта независимость осуществляется путем использования как встроенных в СУБД средств, так и шлюзов (gateways).

Ведущие, да и прочие специалисты написали достаточно много о тех особенностях, которыми должна обладать распределенная СУБД, и к настоящему времени достигнуто общее согласие в отношении этих "идеальных" характеристик. Было сформулированы основные функции, которые должна поддерживать распределенная СУБД.

Локальная автономия. Администратор БД конкретного узла полностью контролирует данные локальной БД данного узла. Он может работать независимо от администраторов других узлов.В распределенной системе узлы следует делать автономными. Локальная автономия означает, что функционирование любого узла Х не зависит от успешного выполнения операций на некотором узле У. В противном случае выход из строя узла У может привести к невозможности выполнения операций на узле Х.. Из принципа локальной автономии следует, что владение и управление данными осуществляется локально вместе с локальным ведением учета. В действительности цель локальной автономии достигается не полностью, поскольку часто узел Х должен представлять некоторую часть управления узлу У, поэтому говорят не о полной, а о максимально возможной автономии.

Независимость от центрального узла. Все узлы должны рассматриваться как равные. Следовательно, не должно существовать никакой зависимости и от центрального «основного» узла с некоторым централизованным обслуживанием, например централизованной обработкой запросов, централизованным управлением транзакциями или централизованным присвоением имен. Зависимость от центрального узла нежелательна по двум причинам. Во-первых, центральный узел может быть «узким» местом всей системы, а во-вторых, более важно то, что система в целом становится уязвимой, т.е. при повреждении центрального узла может выйти из строя вся система.

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

Надежность (вероятность того, что система выполняет свойственные ей функции в заданный момент времени) повышается благодаря работе распределенных систем не по принципу «все или ничего», а в постоянном режиме; т.е. работа системы продолжается , хотя и на более низком уровне, даже в случае неисправности некоторого отдельного компонента, например узла.

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

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

Прозрачность относительно местоположения. Пользователь не должен беспокоиться о том, где физически располагаются данные. СУБД должна представлять все данные так, как если бы они были локальными, и отвечать за сохранение этой "иллюзии".

Разнородные системы. СУБД должна работать с данными, которые хранятся на различных системах с различной архитектурой и производительностью, включая персональные компьютеры, рабочие станции, серверы ЛВС, мини-ЭВМ и большие ЭВМ.

Прозрачность относительно сети. За исключением различий в производительности, СУБД должна работать одинаково в различных сетях, от высокоскоростных ЛВС до низкоскоростных, использующих телефонные линии.

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

Обработка распределенных запросов. При обработке в распределенной системе запроса необходимо выработать эффективную стратегию его реализации. Например, запрос на объединение отношений Rx, расположенного на узле X, и отношения Ry, хранимого на узле Y, может быть выполнен с помощью перемещения отношения Rx на узел Y, перемещения отношения Ry на узел X или перемещения этих двух отношений на третий узел Z и т.д. Это означает, что при выполнении запроса на распределенной БД необходим его предварительный анализ с последующим выбором оптимальной стратегии его реализации.

Проблема оптимизации. Когда доступ к данным осуществляется по сети, обычные правила оптимизации операторов SQL применять нельзя. Например, полное сканирование локальной таблицы может оказаться более оптимальным, чем поиск по индексу в удаленной таблице. Программа оптимизации должна знать параметры сети и, в частности, ее быстродействие. Если говорить, в общем, роль оптимизации становится более важной, а ее осуществление более трудным.

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

Распределенные изменения. Пользователь должен иметь возможность изменять данные в любой таблице, на доступ к которой у него есть необходимые привилегии, независимо от того, находится ли эта таблица в локальной или удаленной системе.

Распределенные транзакции. СУБД должна выполнять транзакции (используя операторы commit и rollback), выходящие за границы одной вычислительной системы, и сохранять целостность распределенной базы данных даже при возникновении отказов как в отдельных системах, так и в сети в целом.

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

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

Независимость от фрагментации. В системе поддерживается фрагментация данных, если некоторое отношение из соображений физического хранения необходимо разделить на части или фрагменты. Фрагментация желательна для повышения производительности системы, поскольку данные лучше хранить в том месте, где они наиболее часто используются. При такой организации многие операции становятся локальными, а объем передаваемых в сети данных снизится. В модели доступа к распределенным данным, введенной компанией IBM и состоящей из четырех уровней, таблица базы данных трактуется как неделимый элемент. Считается, что таблица расположена в одной вычислительной системе, в одной базе данных, управляемой одной СУБД. В некоторых новых разработках, относящихся к распределенным базам данных, это ограничение ослабляется и допускается распределение одной таблицы по нескольким вычислительным системам. В коммерческих СУБД распределенные таблицы пока отсутствуют, но несколько поставщиков СУБД уже объявили, что в будущем они введут возможность распределения таблиц.

Горизонтальная и вертикальная фрагментация. Эта функция позволяет "расщеплять" таблицу БД по строкам (горизонтально) и по столбцам (вертикально) и размещать части данных таблицы в разных узлах сети. Существует два типа фрагментации – горизонтальная и вертикальная (расчленение).

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

Вертикальная фрагментация связана с группированием данных по задачам. Распределения таблицы по сети состоит в вертикальном разделении таблицы и размещении ее столбцов в разных системах. При вертикальном разделении СУБД не должна анализировать содержимое строк для определения их местоположения. Однако перед ней стоит другая, не менее сложная задача сохранения отношения "один-к-одному" между частями строк, расположенными в разных системах. Помимо этого, вертикально разделенные таблицы могут потребовать значительных изменений в программной логике СУБД, осуществляющей блокировку таблиц. Если программе требуется заблокировать строку, то теперь СУБД должна блокировать части строки в нескольких системах. Должна ли СУБД блокировать все части строки или только те ее части, которые действительно обновляются? В зависимости от ответа на этот вопрос СУБД, возможно, придется реализовать блокировку на уровне элементов строк.

Зеркальные таблиц. В идеально спроектированной распределенной базе данных должно соблюдаться правило 80/20: 80 процентов (или более) обращений к базе данных должно удовлетворяться локально и только 20 процентов (или менее) — посредством удаленного доступа. Однако если одна или две таблицы в распределенной базе данных интенсивно используются многими пользователями, находящимися в разных системах, то может оказаться очень трудно достичь баланса 80/20. Где бы ни находились эти таблицы, обращения к ним пользователей из других систем вызовут повышение сетевого трафика и временные задержки.

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

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

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

Независимость от репликации. В системе поддерживается независимость от репликации, если заданное отношение или фрагмент могут быть представлены различными копиями (репликами) хранимыми на разных узлах. Репликация полезна по двум причинам. Во-первых, благодаря ей достигается большая производительность, т.к. приложения могут работать с локальными копиями , не обмениваясь данными с удаленными узлами. Во-вторых, репликация позволяет обеспечить большую доступность, т.к. реплицированный объект остается доступным для обработки до тех пор, пока остается хотя бы одна его реплика. Главный недостаток репликации заключается в том, что при обновлении реплицируемого объекта, все его копии должны синхронизироваться.

В системе, которая поддерживает репликацию данных, должна также поддерживаться независимость от репликации, т.е. пользователь не должен касаться проблем связанных с созданием и синхронизацией копий.