Билет 13. Тираживание данных

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

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

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

Реализация технологии DR отвечает на 4 вопроса:

· Что тиражировать?

· Где тиражировать?

· Когда тиражировать?

· Как разрешать возможные конфликты?

1. Что тиражировать?

согласовано распределенный набор данных (consistent distributed data set - CDDS). Это набор данных, идентичность которого поддерживается репликатором во всех узлах, вовлеченных в процесс тиражирования.

CDDS может представлять собой

1. Всю БД;

2. Избранные объекты БД: таблицы или представления;

3. Вертикальные проекции объектов БД: избранные столбцы таблиц и/или представлений;

4. оризонтальные проекции объектов БД: избранные строки таблиц и/или представлений;

5. Сочетания наборов 2-4.

Строгое определение CDDS состоит в выполнении следующих условий:

· набор данных, претендующий на определение в качестве CDDS, должен располагаться в нескольких базах данных в идентичных копиях;

· данные из различных CDDS должны быть взаимно ортогональны, т.е. одни и те же данные не могут входить в различные CDDS;

· CDDS должен обладать свойством полноты, т.е. включать все идентичные копии данных, существующие в распределенной системе.

Замечание. Идентичность понимается как одинаковость определения и состава данных.

· любое изменение любой копии CDDS автоматически распространяется на все остальные копии;

· ввнутри CDDS ни одна копии данных не имеет преимущества перед другой копией - они абсолютно равноправны;

· все объекты, составляющие каждую копию CDDS, имеют одинаковые имена.

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

2. Где тиражировать?

Следующий элемент схемы тиражирования - путь переноса изменений (data propagation path - DPP) из каждой тиражируемой базы в другие БД.

Основные схемы тиражирования:

· " Центр - филиалы", изменения в базах данных филиалов переносятся в центральную БД, и/или наоборот;

· равноправное, несколько БД разделяют общий набор изменяемых и тиражируемых данных;

· каскадное, изменения в одной БД переносятся в другую БД, откуда в свою очередь в третью БД и т.д.;

· через шлюзы изменения в БД могут переноситься в БД другой СУБД (неоднородная БД);

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

Механизмы, регулирующие взаимоотношения между узлами (с точки зрения принимающего узла):

· " равный-с-равными" (peer-to-peer или full peer): все изменения, произведенные в CDDS на первом узле, попадут на второй узел и наоборот, при этом выполняется контроль возможных коллизий;

· доступ с обнаружением и разрешением конфликтов (protected read): изменения с первого узла попадают во второй, производится контроль возможных конфликтов (например, если источников несколько); при этом изменения CDDS на втором узле незаконны, игнорируются и на первый узел не передаются;

· доступ по чтению без предотвращения конфликтов: то же, что и 2, но конфликты не обнаруживаются и не разрешаются;

· доступ через шлюз: то же, что и 3, но второй узел содержит данные, получаемые через шлюз к БД другой СУБД.

3. Когда тиражировать?

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

· тиражирование начинается после завершения определенного числа транзакций (в частном случае, после каждой транзакции);

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

· процесс тиражирования контролируется вручную администратором или созданным пользователем монитором тиражирования.

4. Как разрешать конфликты?

Репликатор самостоятельно обнаруживает конфликты (например, встречное тиражирование) и предоставляет разрешение конфликта либо администратору, либо делает это автоматически. Некоторые варианты:

· разрешение конфликта в пользу более раннего или более позднего обнаружения;

· разрешение конфликта в пользу наивысшего приоритета тиражируемой записи.

Решение вышеперечисленных вопросов выливается в тот или иной протокол тиражирования.

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

Задача протокола тиражирования - отобразить эти операции доступа к некоторому элементу х на множества операций над физическими копиями x (x1, x2,..., xn). Типичный протокол тиражирования, обеспечивающий сериализуемость по критерию полной эквивалентности копий, известен под названием ROWA (Read-Once/Write-All - одно чтение, запись во все копии). Протокол ROWA отображает чтение x Read(x) на операцию чтения какой-либо из копий x Read(xi). Из какой именно копии будет производиться чтение, неважно - этот вопрос может решаться из соображений эффективности. Каждая операция записи в логический элемент данных x отображается на множество операций записи во все физические копии x.

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

Ряд альтернативных алгоритмов ослабляют требование протокола ROWA. Это такие алгоритмы:

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

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

Специфика механизмов DR зависит от используемой СУБД.

Билет номер 14

⇐ Предыдущая45678910111213Следующая ⇒

Поделиться: