LS-Sb90335

аспекта управления обработкой транзакций, а именно: управление восстановлением и управление параллелизмом. Каждому из этих аспектов в распределенных системах должно уделяться повышенное внимание.

4.1.9. Независимость от аппаратного обеспечения

Этот принцип предполагает, что СУРБД должна функционировать на оборудовании с различными вычислительными платформами. Существует реальная необходимость интеграции данных на этих системах и создания для пользователя «представления единой системы». Таким образом, весьма важна возможность запуска копий одной и той же СУБД на разном аппаратном обеспечении, чтобы разные компьютеры могли работать в распределенной системе как равные партнеры.

4.1.10. Независимость от операционной системы

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

4.1.11. Независимость от сети

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

4.1.12. Независимость от типа СУБД

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

4.2.Представление и методы поддержки распределенных данных

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

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

31

Таким образом, каждая группа пользователей одни и те же данные будет видеть по– своему.

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

Внутренний уровень представляет БД в полностью в «материализованном» виде, тогда как на других уровнях идет работа с отдельными экземпляров или множествами экземпляров данных.

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

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

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

Глобально-логический уровень соответсвует концептуальному уровню локальных БД и используется для описания логической структуры всей распределенной базы данных. При описании РаспБД этому уровню ставится в соответствие глобальная представляющая схема.

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

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

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

32

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

вданном рассмотрении эти уровни не принимают участия.

4.3.Методы поддержки распределенных данных

Существуют различные методы поддержки распределенности:

1.Фрагментация – разбиение БД или таблицы на несколько частей и хранение этих частей на разных узлах РБД.

2.Репликация – создание и хранение копий одних и тех же данных на разных узлах РБД.

3.Распределенные ограничения целостности – ограничения, для проверки выполнения которых требуется обращение к другому узлу РБД.

4.Распределенные запросы – это запросы на чтение, обращающиеся более чем к одному узлу РБД.

5.Распределенные транзакции – команды на изменение данных, обращающиеся более чем к одному узлу РБД.

4.3.1. Фрагментация

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

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

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

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

33

идентичных физических таблицах на различных узлах. При этом каждый фрагмент хранится на отдельном узле. Каждый фрагмент имеет уникальные строки. Все уникальные строки имеют одинаковые атрибуты (столбцы).

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

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

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

4.3.2. Репликация данных

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

Достоинства репликации:

–повышение доступности и надежности данных;

–повышение локализации ссылок на реплицируемые данные. Недостатки репликации:

–сложность поддержания идентичности реплик;

–увеличение объема памяти для хранения данных.

Поддержание идентичности реплик называется распространением изменений (обновлений) и реализуется службой тиражирования. Функции репликации выполняет специальный модуль СУБД – сервер тиражирования данных, называемый репликатором (replicator). Его задача – поддержка идентичности данных в принимающих базах (target database) исходной БД.

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

34

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

Общая схема устранения этой проблемы (и не единственно возможная в этом случае), называется схемой первичной копии. При реализации этого подхода одна копия каждого реплицируемого объекта называется первичной, а все остальные – вторичными. Первичные копии различных объектов находятся на разных узлах, а это означает, что схема является распределенной. Операции обновления считаются завершенными, если обновлены все первичные копии. В некоторый момент времени узел, содержащий первичную копию, несет ответственность за распространение операции обновления на вторичные копии. Однако поскольку свойства транзакции АСИД (атомарность, согласованность, изоляция, долговечность) должны выполняться, то подразумевается, что «некоторый момент времени» предшествует завершению исполнения транзакции.

При этом могут возникнуть дополнительные проблемы. В частности, нарушатся требования локальной автономии, поскольку даже если локальная копия остается доступной, выполнение транзакции может потерпеть неудачу из-за недоступности удаленной первичной копии объекта.

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

Существуют и другие способы реализации распространения обновлений (поддержания идентичности реплик).

Симметричная репликация (без основной копии). Все копии реплициру-

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

35

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

Использование триггеров1. Внутрь триггера помещаются команды, производящие на других копиях обновления, аналогичные тем, которые вызвали выполнение триггера. Этот подход достаточно гибкий, но обладает рядом недостатков:

−триггеры создают дополнительную нагрузку на систему;

−триггеры не могут выполняться по графику (время срабатывания триггера не определено);

−с помощью триггеров сложнее организовать групповое обновление

связанных таблиц (из-за проблемы мутирующих таблиц).

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

−соблюдение порядка внесения изменений для сохранения согласованности данных;

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

4.3.3. Распределенные запросы

Распределенным называется запрос, который обращается к двум и более узлам РБД, но не обновляет на них данные.

Запрашивающий узел должен определить, что в запросе идет обращение к данным на другом узле, выделить подзапрос к удаленному узлу и перенаправить его этому узлу.

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

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

36

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

−адекватно оценивать интенсивность обмена данными и время доступа к удаленным узлам системы;

−строить запросы так, чтобы время передачи данных было много меньше времени вычислений и операций ввода/вывода;

− по возможности осуществлять параллельную обработку данных на узлах.

4.3.4. Распределенные ограничения целостности

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

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

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

4.3.5. Распределенные транзакции

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

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

37

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

При реализации этого протокола один из узлов системы выполняет функции координатора. Процесс состоит из двух фаз.

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

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

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

Вторая фаза. Координатор посылает команду «фиксировать» всем подчиненным процессам.

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

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

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

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

38

5.ТЕХНОЛОГИИ ИНТЕГРАЦИИ ДАННЫХ

ВРАСПРЕДЕЛЕННЫХ СИСТЕМАХ

Распределенные базы данных можно подразделить на гомогенные и гетерогенные. Гомогенной РаспБД управляет один и тот же тип СУБД, гетерогенной – различные типы СУБД, использующие разные модели данных: реляционные, сетевые, иерархические или объектно-ориентированные.

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

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

Задачей интеграции является получение единой и цельной картины данных. Интеграция данных может быть описана с помощью модели, которая включает приложения, продукты, технологии и методы.

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

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

Технологии реализуют один или несколько методов интеграции данных. Методы – это подходы к интеграции, независимые от технологий. Существует три основных метода интеграции данных: консолидация,

федерализация и распространение.

5.1. Консолидация данных

Консолидация – комплекс методов и процедур, направленных на извлечение данных из различных источников, обеспечение необходимого уровня их информативности и качества, а также преобразование их в единый формат. Цели консолидации:

−доведение данных до соответствующего уровня качества и информативности;

39

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

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

−обеспечение высокой скорости доступа к данным;

−компактность хранения;

−автоматическая поддержка целостности структуры данных;

−контроль непротиворечивости данных.

Задачи консолидации:

−выбор источников данных, определение типа и методики организации доступа к ним;

−разработка стратегии консолидации;

−оценка качества данных;

−обогащение;

−очистка;

−перенос в хранилище данных.

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

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

40