Гомогенные и гетерогенные распределенные БД

Распределенные БД

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

Каждая таблица в РАБД может быть разделена на некоторое количество частей, называемых фрагментами: горизонтальными,вертикальными и смешанными.

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

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

Для задания горизонтального разделения отношений в SQL была введена конструкция вида

DISTRIBUTE TABLE <table-name> HORIZONTALLY INTO

<name> WHERE <predicate> IN SEGMENT <segment-name site>

.

.

<name> WHERE <predicate> IN SEGMENT <segment-name site>

Вертикальное разделение производилось с помощью оператора

DISTRIBUTE TABLE <table-name> VERTICALLY INTO

<name> WHERE <column-name-list> IN SEGMENT <segment-name site>

.

.

<name> WHERE <column-name-list> IN SEGMENT <segment-name site>

Гомогенные и гетерогенные распределенные БД

РаБД можно классифицировать на гомогенные и гетерогенные.

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

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

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

В основе распределенных БД лежат основные принципы:

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

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

3.Непрерывность операций. Это возможность непрерывного до­ступа к данным в рамках распределенной БД вне зависимости от их расположения и вне зависимости от операций, выполняемых на локальных узлах.

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

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

6.Прозрачное тиражирование. Тиражирование данных — это асин­хронный процесс переноса изменений объектов исходной базы
данных в базы, расположенные на других узлах распределенной системы.

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

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

9.Независимость от оборудования. Это свойство означает, что в качестве узлов распределенной системы могут выступать компью­теры любых моделей и производителей.

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

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

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

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

· Репликация и фрагментирование.Репликаты– множество различных физических копий некоторого объекта БД, для которых в соответствии с определенными в БД правилами поддерживается синхронизация с некоторой «главной копией».

Существуют несколько альтернативных стратегий размещения данных в системе:

· раздельное (фрагментированное) размещение,

· размещение с полной репликацией,

· размещение с выборочной репликацией.

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

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

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

· Распределенные транзакции.Распределенные транзакции обращаются к двум и более узлам и обновляют на них данные.

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

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

Координатор транзакции – узел, который контролирует выполнение этого протокола (обычно, тот узел, который инициирует данную транзакцию).

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

Координатор выполняет протокол 2ФФ по следующему алгоритму:

I. Фаза 1 (голосование).

Занести запись begin_commit в системный журнал и обеспечить ее перенос из буфера в ОП на ВЗУ. Отправить всем участникам команду PREPARE.

Ожидать ответов всех участников в пределах установленного тайм-аута.

II. Фаза 2 (принятие решения).

При поступлении сообщения ABORT: занести в системный журнал запись abort и обеспечить ее перенос из буфера в ОП на ВЗУ; отправить всем участникам сообщение GLOBAL_ABORT и ждать ответов участников (тайм-аут).

Если участник не отвечает в течение установленного тайм-аута, координатор считает, что данный участник откатит свою часть транзакции и запускает протокол ликвидации.

Если все участники прислали COMMIT, поместить в системный журнал запись commit и обеспечить ее перенос из буфера в ОП на ВЗУ. Отправить всем участникам сообщение GLOBAL_COMMIT и ждать ответов всех участников.

После поступления подтверждений о фиксации от всех участников: поместить в системный журнал запись end_transaction и обеспечить ее перенос из буфера в ОП на ВЗУ.

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

· Связи. Для получения доступа к удаленной БД нужно установить связь с этой БД с помощью специальной команды языка SQL – LINK. При формировании связи могут учитываться учетные сведения пользователя для обеспечения безопасности данных.

Создание общей связи баз данных к удаленной базе данных SALES:

CREATE PUBLIC DATABASE LINK <имя связи> USING <имя БД>;

Создание личной связи баз данных для создателя этой связи:

CREATE DATABASE LINK <имя связи> CONNECT TO <имя пользователя> IDENTIFIED BY <пароль>;

• Тиражирование.

Производится с помощью двух средств Oracle:

1. Многоабонентского тиражирования.
2. Узлов обновляемых моментальных снимков.

Распространение изменений:

1. на уровне строк: сервер записывает изменения, сделанные каждой DML-транзакцией, и рассылает эти изменения в удаленные узлы.
2. путем процедурного тиражирования: тиражируется вызов удаленной процедуры, выполняющей в удаленном узле те же изменения, что и в вызывающем.

Различают асинхронное и синхронное распространение изменений.

Внесение изменений в тиражируемые данные происходит в несколько этапов:

ü локальный узел вносит изменения в свою копию данных (ОМС);

ü локальный узел запускает отложенную транзакцию на основном узле;

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