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

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

В распределенной СУБД различаются четыре типа сбоев:

• сбой транзакции,

• сбой узла (системы),

• сбой носителя (диска),

• сбой коммуникационной линии.

http://ami.nstu.ru/~vms/lecture/lecture10/lecture10.htm#name3

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

• ошибки в сообщениях,

• нарушение упорядоченности сообщений,

• потерянные (недоставленные) сообщения,

• повреждения на линиях связи

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

в качестве протокола атомарной фиксации является протокол двухфазовой фиксации транзакций (2PC - 2 Phase Commit).

Три основных принципа лежат в ее основе:

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

2. Если все узлы голосуют за фиксацию транзакции, то она фиксируется на всех участвующих в ней узлах.

3. Проголосовавший участник не может изменить свое решение.

1 фаза 2PC - подготовка к фиксации транзакции (голосование).

2 фаза 2PC- глобальные фиксация или откат транзакции (принятие решения).

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

Предпринимались попытки создания неблокирующих протоколов (пример - протокол трехфазовой фиксации - 3PC)

Обратной стороной терминирования является восстановление:

1. Cбой произошел до начала процедуры фиксации. Узел может начать процесс фиксации после восстановления.

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

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

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

Если в DDB предусмотрено тиражирование данных, то это сразу предъявляет дополнительные жесткие требования к дисциплине поддержки целостности данных на узлах, куда направлены потоки тиражируемых данных. Проблема в том, что изменения в данных инициируются как локально - на данном узле - так и извне, посредством тиражирования. Неизбежно возникают конфликты по изменениям, которые необходимо отслеживать и разрешать

Тиражирование данных (Data Replication - DR) - это асинхронный перенос изменений объектов исходной базы данных (source database) в БД, принадлежащим различным узлам распределенной системы.

http://citforum.ru/database/kbd96/45.shtml

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

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

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

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

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

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

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

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

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

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

http://otherreferats.allbest.ru/radio/d00077308.html:

Поддержка целостности в реляционной модели данных в ее классическом понимании включает в себя 3 метода:

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

Второй метод это поддержка языковой целостности, которая состоит в том, что реляционная СУБД должна обеспечивать языки описания и манипулирования данными не ниже стандарта SQL. Не должны быть доступны иные низкоуровневые средства манипулирования данными, не соответствующие стандарту.

Третий метод это поддержка ссылочной целостности (Declarative Referential Integrity, DRI), означает обеспечение одного из заданных принципов взаимосвязи между экземплярами кортежей взаимосвязанных отношений:

• кортежи подчиненного отношения уничтожаются при удалении кортежа основного отношения, связанного с ними.

• кортежи основного отношения модифицируются при удалении кортежа основного отношения, связанного с ними, при этом на месте ключа родительского отношения ставится неопределенное Null значение.

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

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

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