Проблемы распределенных баз данных

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

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

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

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

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

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

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

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

· саму программу,

· методику выполнения программы (запроса) с учетом необходимых перемещений данных.

Одновременная работа

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

Транзакция -это разовый прогон программы, реализующей запрос (другими словами, такая единица работы), при котором БД остается в состоянии целостности до и после выполнения транзакции.

Замечание. В процессе выполнения транзакции целостность БД может нарушаться.

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

Очевидно, что расписание при одновременной работе представляет порядок выполнения транзакций во времени.

Примеры расписаний. Введем следующие обозначения:

Т -транзакция,

R-A - элементарный шаг транзакции, представляющий чтение значения поля А,

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

Расписание 1.

Т1: R-A

T1: W-A

T2: R-A

T2: W-A

Нарушения целостности (рассогласования) БД возникнуть не может, так как транзакции Т1 и Т2 выполняются последовательно.

Расписание 2.

Т1: R-A

T2: R-A

T1: W-A

T2: W-A

Модификация транзакции Т1 затирается транзакцией Т2, следовательно, она теряется.

Расписание 3.

Т1: W-A

T2: W-A

T1: отменить

Потеря модификации транзакции Т2, поскольку после ее окончания следует сигнал отмены модификации.

Расписание 4.

Т1: W-A

T2: R-A

T1: прервать

Ситуация известна под названием «неправильное считывание», поскольку выбранное транзакцией Т2 значение впоследствии из БД удаляется.

Расписание 5

Т2: R-A

T1: W-A

T2: R-A

Две выборки дадут различные значения.

Пример рассогласования БД.

Пусть транзакции Т1 и Т2 имеют вид:

R-A

A=A+1

W-A

Шаги выполнения транзакций приведены в следующей таблице

Такты
Значение А в БД
Т1	R-A		A=A+1			W-A
T2		R-A		A=A+1	W-A
Значение А в раб. пространстве Т1
Значение А в раб. пространстве Т2

 

Очевидно, что целостность БД нарушена, поскольку нельзя было допустить чтение и модификацию поля А транзакцией Т2 до того, пока транзакция Т1 свое выполнение не закончит, то есть до записи модифицированного транзакцией Т1 значения в поле А.

Согласованные состояния БД обеспечивают последовательные или приводимые к последовательным расписания.

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

Расписание называется приводимым к последовательному, если результат применения этого расписания к БД эквивалентен результату последовательного расписания.

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

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

Пример 1. Расписание последовательное

 

Т1: W-A

T1: W-B

T2: W-A

T2: W-B

Пример 2. Расписание, приводимое к последовательному

Т1: W-A

T2: W-А

T1: W-В

T2: W-B

 

 

Пример 3. Расписание, не приводимое к последовательному

Т1: W-A

T2: W-А

T2: W-В

T1: W-B

Управление блокированием

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

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

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

ЗАХВАТ - ДЕЙСТВИЕ - ОСВОБОЖДЕНИЕ

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

Итак, всякая транзакция в конце концов должна разблокировать все, что она ранее заблокировала.

Таким образом, в распределенных БД необходимо обеспечить передачу следующих сообщений о блокировках:

1) послать запросы на блокировку во все узлы,

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

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

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