СБД_13

1
РАСПРЕДЕЛЕННЫЕ БАЗЫ ДАННЫХ
План лекции
1. Архитектура распределенной системы.
2. Введение в распределенные БД
3. Свойства идеальной распределенной БД
4. Аспекты функционирования распределенной БД
Рекомендуемая литература:
Т. Конноли. Базы данных. Проектирование, реализация и
сопровождение. Теория и практика.: Пер.с англ. – М.: Изд.дом
«Вильямс», 2006. – 1440 с.
1 Архитектура распределенной системы
Распределенная система - система, в которой хранение и
обработка
информации
сосредоточена
не
на
одной
вычислительной машине, а распределена между несколькими
компьютерами.
Можно выделить несколько характеристик распределенных
систем.
1.
Совместное использование ресурсов. Распределенные
системы допускают совместное использование как аппаратных
(жестких дисков, принтеров), так и программных (файлов,
компиляторов) ресурсов.
2.
Открытость. Это возможность расширения системы
путем добавления новых ресурсов.
3.
Параллельность.
В
распределенных
системах
несколько процессов могут одновременно выполнятся на разных
компьютерах в сети. Эти процессы могут взаимодействовать во
время их выполнения.
4.
Масштабируемость.
Под
масштабируемостью
понимается возможность добавления новых свойств и методов.
5.
Отказоустойчивость.
Наличие
нескольких
компьютеров позволяет дублировать данные, что повышает
устойчивость к некоторым аппаратным и программным ошибкам.
Распределенные системы в случае ошибки могут поддерживать
частичную функциональность.
2
6.
Прозрачность.
Пользователям
предоставляется
полный доступ к ресурсам в системе, в то же время от них скрыта
информация о распределении ресурсов по системе.
Распределенные системы обладают и рядом недостатков.
1.
Сложность. Намного труднее понять и оценить
свойства распределенных систем в целом, их сложнее
проектировать,
тестировать
и
обслуживать.
Также
производительность системы зависит от скорости работы сети, а
не отдельных процессоров. Перераспределение ресурсов может
существенно изменить скорость работы системы.
2.
Безопасность. Обычно доступ к системе можно
получить с нескольких разных машин, сообщения в сети могут
просматриваться и перехватываться. Поэтому в распределенной
системе намного труднее поддерживать безопасность.
3.
Управляемость.
Система
может
состоять
из
разнотипных компьютеров, на которых могут быть установлены
различные версии операционных систем. Ошибки на одной
машине могут распространиться непредсказуемым образом на
другие машины.
4.
Непредсказуемость. Реакция распределенных систем
на некоторые события непредсказуема и зависит от полной
загрузки системы, ее организации и сетевой нагрузки. Так как эти
параметры могут постоянно изменятся, поэтому время ответа на
запрос может существенно отличаться от времени.
Схематически такую архитектуру можно представить
следующим образом.
Архитектура распределенных систем
3
Каждый АРМ независим, содержит только ту информацию, с
которой должен работать, а актуальность данных во всей
системе обеспечивается благодаря непрерывному обмену
сообщениями с другими АРМами. Обмен сообщениями между
АРМами может быть реализован различными способами.
2 Введение в распределенные БД
Распределенная база данных - набор логически связанных
между собой БД (совокупностей данных и их описаний), которые
физически распределены в разных узлах компьютерной сети.
Любой узел в РБД способен независимо обрабатывать
запросы пользователей, требующие доступа к локально
сохраняемым данным (т.е. каждый узел обладает определенной
степенью автономности), а также способен обрабатывать
данные, сохраняемые на других компьютерах сети.
В соответствии с определением Дэйта, распределенную базу
данных (РБД) (DDB - distributed database) можно рассматривать
как слабосвязанную сетевую структуру, узлы которой
представляют собой локальные базы данных. Эти локальные
базы данных автономны, независимы и самоопределены; доступ
к ним обеспечивают сетевые многопользовательские СУБД, в
общем случае от различных поставщиков.
Связи
между
узлами
представляют
собой
потоки
тиражируемых данных. Топология РБД определяется географией
информационной системы и направленностью потоков данных возможны варианты иерархии, структур типа "звезда" и т.д.
Распределенная
СУБД
программная
система,
предназначенная для управления распределенными базами
4
данных и обеспечивающая прозрачный доступ пользователей к
распределенной информации.
Другими словами, от пользователей должен быть полностью
скрыт тот факт, что распределенная база данных состоит из
нескольких БД (или их фрагментов), которые могут размещаться
на различных компьютерах. Цель обеспечения прозрачности
состоит в том, чтобы распределенная система внешне выглядела
как централизованная. Иногда это требование называют
основным принципом создания распределенных СУБД. Данный
принцип требует предоставления конечному пользователю
широкого набора функциональных возможностей, но, к
сожалению,
одновременно
ставит
перед
программным
обеспечением
распределенной
СУБД
множество
дополнительных задач.
Пользователи взаимодействуют с распределенной базой
данных через приложения. Приложения могут подразделяться на
не требующие доступа к данным на других узлах (локальные
приложения) и требующие подобного доступа (глобальные
приложения). В распределенной системе должно существовать
хотя бы одно глобальное приложение.
Разбиение данных в распределенной базе данных может
достигаться путем хранения различных таблиц на разных
компьютерах или даже хранения разных частей и фрагментов
одной таблицы на разных компьютерах. Для пользователя (или
прикладной программы) не должно иметь значения, каким
образом распределены данные между компьютерами. Работать с
распределенной базой данных, если она действительно
распределенная, следует так же, как и с централизованной, т. е.
размещение базы данных должно быть прозрачно.
В РБД информация (данные) физически распределяется по
локальным базам при помощи операции фрагментации:
горизонтальной или вертикальной.
Горизонтальная фрагментация реализуется при помощи
операции селекции, которая направляет каждый кортеж
отношения в один из разделов (одну из локальных баз),
руководствуясь условием фрагментации. Строки данных о
сотрудниках
могут
разбиваться
на
подмножества,
соответствующие
филиалам.
Данные
о
продажах
фрагментируются по магазинам, где эти продажи производились
5
При вертикальной фрагментации отношение делится на
разделы при помощи операции проекции.
В этом случае
разбиение таблицы происходит не по строкам, а по столбцам:
некоторая часть информации о каждом сотруднике хранится в
одном месте, а другая часть (относящаяся к той же таблице) - в
другом.
За счет фрагментации данные приближаются к месту их
наиболее интенсивного использования, что потенциально
снижает затраты на пересылки; уменьшаются также размеры
отношений, участвующих в пользовательских запросах.
Независимо от того, применяется горизонтальная или
вертикальная фрагментация, в системе поддерживается
глобальная схема, позволяющая воссоздать из имеющихся
фрагментов логически централизованную таблицу или другую
структуру базы данных.
Фрагменты данных могут тиражироваться в системе с учетом
спроса на доступ к ним. Это полезно, если доступ к одним и тем
же данным нужен из приложений, выполняющихся на разных
узлах. В таком случае, с точки зрения экономии затрат, более
эффективно будет поддерживать копии данных на всех узлах,
чем непрерывно пересылать данные между узлами.
6
Распределение (включая фрагментацию и репликацию
(тиражирование) данных по множеству узлов невидимо для
пользователей.
На сегодняшний день известны несколько реализаций
распределенной обработки.
Наиболее популярна в настоящее время архитектура
«клиент-сервер»,
когда
множество
машин-клиентов
осуществляют доступ к одному серверу баз данных. В таких
системах, которые можно определить как системы типа «многоклиентов/один-сервер», проблемы управления базой данных
решаются относительно просто, поскольку вся она хранится на
одном сервере. Задачи, с которыми приходится здесь
сталкиваться, - это управление буферами клиентов, кэширование
данных и, возможно, блокировки. Управление данными
реализуется централизованно на одном сервере.
Более распределенной и более гибкой является архитектура
типа «много-клиентов/много-серверов», когда база данных
размещена на множестве серверов, которым, для того чтобы
вычислить результат пользовательского запроса или выполнить
транзакцию, необходимо взаимодействовать друг с другом.
Каждая клиентская машина имеет свой «домашний» сервер; ему
она направляет пользовательские запросы. Взаимодействие
серверов друг с другом прозрачно для пользователей. В
большинстве существующих СУБД реализован один из этих двух
типов архитектуры «клиент-сервер».
В истинно распределенной СУБД клиентские и серверные
машины не различаются. В идеале каждый узел может выступать
и как клиент, и как сервер. Такие архитектуры, тип которых
определяют
как
«равный-к-равному»,
требуют
сложных
протоколов
управления
данными, распределенными
по
множеству узлов.
Все технологии, применяемые в распределенных СУБД,
направлены на повышение надежности, поскольку благодаря
репликациям (копиям) данных исключаются одиночные точки
отказа. Отказ одного узла или сбой на линии связи не приводит к
выходу из строя всей системы. Даже если часть данных
становится недоступной, при правильной организации системы
пользователи могут иметь доступ к остальной части
информации.
7
3 Свойства идеальной распределенной базы данных
Дэйт (C.J. Date) установил 12 свойств или качеств идеальной
распределенной базы данных.
1. Локальная автономия (local autonomy)
Будучи фрагментом общего пространства данных, БД, в то же
время функционирует как полноценная локальная база данных;
управление ею выполняется локально и независимо от других
узлов системы.
2. Независимость от центрального узла (no reliance on
central site).
В идеальной системе все узлы равноправны и независимы, а
расположенные на них базы являются равноправными
поставщиками данных в общее пространство данных. База
данных на каждом из узлов самодостаточна - она включает
полный собственный словарь данных и полностью защищена от
несанкционированного доступа.
3. Непрерывные операции (continuous operation).
Это
качество
можно
трактовать
как
возможность
непрерывного доступа к данным (известное "24 часа в сутки,
семь дней в неделю") в рамках DDB вне зависимости от их
расположения и вне зависимости от операций, выполняемых на
локальных узлах. Это качество можно выразить лозунгом
"данные доступны всегда, а операции над ними выполняются
непрерывно".
4. Прозрачность расположения (location independence).
Пользователь, обращающийся к DDB, ничего не должен знать
о реальном, физическом размещении данных в узлах
информационной системы. Все операции над данными
выполняются
без
учета
знаний
их
местонахождения.
Транспортировка запросов к базам данных осуществляется
встроенными системными средствами.
5. Прозрачная фрагментация (fragmentation independence).
Это свойство трактуется как возможность распределенного
(то есть на различных узлах) размещения данных, логически
представляющих
собой
единое
целое.
Существует
фрагментация двух типов: горизонтальная и вертикальная.
Горизонтальная означает хранение строк одной таблицы на
различных узлах (фактически, хранение строк одной логической
8
таблицы в нескольких идентичных физических таблицах на
различных узлах). Вертикальная
означает распределение
столбцов логической таблицы по нескольким узлам.
6. Прозрачность тиражирования (replication independence).
Тиражирование (репликация) данных - это асинхронный
процесс переноса изменений объектов исходной базы данных в
базы, расположенные на других узлах распределенной системы.
В данном контексте прозрачность тиражирования означает
возможность переноса изменений между базами данных
средствами,
невидимыми
пользователю
распределенной
системы. Данное свойство означает, что тиражирование
возможно и достигается внутрисистемными средствами.
7. Обработка распределенных запросов (distributed query
processing).
Это свойство DDB трактуется как возможность выполнения
операций выборки над распределенной базой данных,
сформулированных в рамках обычного запроса на языке SQL. То
есть операцию выборки из DDB можно сформулировать с
помощью тех же языковых средств, что и операцию над
локальной базой данных.
8. Обработка
распределенных
транзакций
(distributed
transaction processing).
Это качество DDB можно трактовать как возможность
выполнения операций обновления распределенной базы данных
(INSERT, UPDATE, DELETE), не разрушающее целостность и
согласованность данных. Эта цель достигается применением
двухфазного протокола фиксации транзакций (two-phase commit
protocol),
ставшего
фактическим
стандартом
обработки
распределенных транзакций. Его применение гарантирует
согласованное изменение данных на нескольких узлах в рамках
распределенной транзакции.
9. Независимость от оборудования (hardware independence).
Это свойство означает, что в качестве узлов распределенной
системы могут выступать компьютеры любых моделей и
производителей - от мэйнфреймов до "персоналок".
10. Независимость от операционных систем (operationg
system independence).
Это качество вытекает из предыдущего и означает
многообразие операционных систем, управляющих узлами
9
распределенной системы.
11. Прозрачность сети (network independence).
Доступ к любым базам данных осуществляется по сети.
Спектр поддерживаемых конкретной СУБД сетевых протоколов
не должен быть ограничением системы с распределенными
базами данных. Данное качество формулируется максимально
широко - в распределенной системе возможны любые сетевые
протоколы.
12. Независимость от баз данных (database independence).
Это качество означает, что в распределенной системе могут
мирно сосуществовать СУБД различных производителей, и
возможны операции поиска и обновления в базах данных
различных моделей и форматов.
4 Аспекты функционирования распределенной БД
Размещение и тиражирование данных
В РБД может возникнуть серьезная проблема - перекос в
распределении данных, которая выражается в неравномерном
разбиении отношений и отрицательно влияет на баланс загрузки
системы. Когда текущее размещение данных приводит к
дестабилизации
загрузки,
необходимо
произвести
реорганизацию базы данных. Хорошо было бы, чтобы
реорганизацию можно было проводить в оперативном режиме
(не
прекращая
текущей
обработки
транзакций).
Но
существующие СУБД способны производить реорганизацию баз
данных
только
статически.
Статическая
реорганизация
проводится периодически и служит для изменения размещения
данных либо в связи с увеличением размера базы данных, либо
из-за изменения структуры спроса на доступ к данным и как
правило требует остановки в работе системы.
Еще один фактор, усложняющий работу РБД - это
необходимость выполнения процедуры тиражирования (или
репликации).
Тиражирование (пли репликация) означает создание
дубликатов данных. Репликаты - это множество различных
физических копий некоторого объекта базы данных (обычно
таблицы), для которых в соответствии с определенными в базе
10
данных
правилами
поддерживается
синхронизация
(идентичность) с некоторой "главной" копией.
В распределенных базах данных с тиражированием каждому
логическому элементу данных (локальной БД) соответствует
несколько физических копий - первичная и дублирующая и часто
возникают проблемы, связанные с поддержкой согласованного
состояния копий. Теоретически значения всех данных в
тиражированных
объектах
должны
автоматически
и
незамедлительно синхронизироваться друг с другом. (На
практике это правило обычно несколько ослабляется.) В
некоторых системах копии используются исключительно в
режиме чтения и обновляются в соответствии с заданным
расписанием. В других средах допускается модификация
отдельных
значений
в
копиях,
и
эти
изменения
распространяются в соответствии с процедурами планирования
и координации.
В современных промышленных распределенных СУБД
используются более гибкие технологии репликаций, где тип
согласования копий находится под контролем пользователя.
11
Репликацию можно классифицировать по-разному.
I. По направлению репликации. Если данные изменяются
только в одной из БД, а в другой данные только хранятся и не
подвергаются изменениям, то такую репликацию будем называть
однонаправленной или односторонней. Если же данные могут
изменяться и вводиться на всех копиях БД, то такой вид
репликации
будем
называть
мультинаправленной
или
многосторонней.
II. По времени проведения сеанса репликации. Если данные
должны быть засинхронизированы немедленно после изменений
во всех копиях, то такую репликацию будем называть репликация
реального времени. Если же процесс репликации запускается по
какому либо событию во времени или по отмашке
администратора БД, то такой вид репликации назовем
отложенная репликация.
Целостность данных
В распределенных базах данных поддержка целостности и
согласованности данных представляет собой сложную проблему.
Ее решение - синхронное и согласованное изменение данных в
нескольких локальных базах данных, составляющих РБД достигается применением протокола двухфазной фиксации
транзакций. Если DDB однородна - то есть на всех узлах данные
хранятся в формате одной базы и на всех узлах функционирует
одна и та же СУБД, то используется механизм двухфазной
фиксации транзакций данной СУБД. В случае же неоднородности
DDB для обеспечения согласованных изменений в нескольких
базах
данных
используют
менеджеры
распределенных
транзакций. Это, однако, возможно, если участники обработки
распределенной транзакции - СУБД, функционирующие на узлах
системы, поддерживают XA-интерфейс, определенный в
спецификации DTP консорциума X/Open. В настоящее время XAинтерфейс имеют CA-OpenIngres, Informix, Microsoft SQL Server,
Oracle, Sybase.
Протоколы обеспечения надежности
Распределенные СУБД потенциально более надежны в силу
того, что системные компоненты в них дублируются, и тем самым
исключаются одиночные точки отказа.
12
В распределенной СУБД различаются четыре типа сбоев:
сбой транзакции, сбой узла (системы), сбой носителя (диска),
сбой коммуникационной линии.
Причин сбоев транзакции может быть несколько: ошибки,
вызванные неверными входными данными, обнаружение
возникшего или возможного тупика. Обычный способ обработки
таких сбоев заключается в том, чтобы прервать транзакцию и
откатить базу данных к состоянию, предшествовавшему началу
транзакции.
Сбои узлов (систем) могут быть вызваны аппаратными
отказами или программными ошибками. Системные сбои
приводят к потере содержимого оперативной памяти. В то же
время данные, находящиеся во внешней памяти, остаются в
сохранности. Для поддержания сохранности данных обычно
применяют протоколы журнализации. В распределенной базе
данных проблема системных сбоев выражается еще и в том, что
отказавший узел не может участвовать в транзакциях.
Сбои носителей связаны с отказами устройств внешней
памяти, на которых хранится стабильная база данных. Обычно
эта проблема решается путем применения дуплексных устройств
и поддержания архивных копий базы данных.
Рассмотренные выше три типа сбоев характерны и для
централизованных,
и
для
распределенных
СУБД.
Коммуникационные сбои, напротив, являются специфической
проблемой распределенных баз данных. Они подразделяются на
несколько разновидностей, наиболее распространенные из
которых - ошибки в сообщениях, нарушение упорядоченности
сообщений,
потерянные
(недоставленные)
сообщения,
повреждения на линиях связи. Первые две из них относятся к
компетенции сетевых протоколов и не рассматриваются в
реализациях распределенных СУБД. Последние две находятся в
ведении СУБД и должны учитываться в протоколах обеспечения
надежности. Если один узел ожидает сообщения от другого, а
оно не поступает, то причин тому может быть несколько: (а)
сообщение утрачено; (б) возникло повреждение на линии связи;
(в) узел, от которого ожидается сообщение, отказал. Таким
образом, не всегда возможно отличить коммуникационный сбой
от системного. Ожидающий узел по истечении определенного
промежутка времени просто решает, что узел-партнер стал
13
недоступен. Протоколы распределенных СУБД должны уметь
адекватно реагировать на подобные неопределенные ситуации.
Протоколы обеспечения надежности поддерживают два свойства
транзакций: атомарность и долговечность. Атомарность
означает, что выполняются либо все действия транзакции, либо
не выполняется ни одно. Атомарность гарантируется даже в
условиях возможных отказов. Долговечность означает, что
результат успешно завершенной (зафиксированной) транзакции
сохраняется даже при последующих сбоях.
Для обеспечения атомарности и долговечности необходимы
протоколы атомарной фиксации и протоколы распределенного
восстановления.
Наиболее
популярным
из
протоколов
атомарной фиксации является протокол двухфазовой фиксации
транзакций (2PC - 2 Phase Commit). 2PC опирается на
следующие фундаментальные правила.
1. Если хотя бы один узел отказывается зафиксировать
транзакцию, то распределенная транзакция прерывается на всех
участвующих в ней узлах.
2. Если все узлы голосуют за фиксацию транзакции, то она
фиксируется на всех участвующих в ней узлах.
На узле, где инициируется транзакция, создается процесскоординатор; на всех прочих затрагиваемых ею узлах создаются
процессы-участники.
Вначале
координатор
рассылает
участникам сообщение «приготовиться», и каждый из них
14
независимо решает, может ли транзакция завершиться на
данном узле. Участники, которые готовы завершить транзакцию,
посылают координатору сообщение «голосую за фиксацию».
Участники, не имеющие возможности зафиксировать свою часть
транзакции, возвращают сообщение «голосую за прерывание».
Проголосовавший участник не может изменить свое решение.
Координатор, собрав голоса участников, решает судьбу
транзакции согласно правилам 2PC. Если он принимает решение
зафиксировать транзакцию, то всем участникам рассылается
сообщение «глобальная фиксация». Если решено прервать
транзакцию, то участникам, проголосовавшим за ее фиксацию,
посылается сообщение «глобальное прерывание». Участникам,
проголосовавшим за прерывание, сообщение посылать не нужно,
поскольку они сами способны принять решение исходя из правил
2PC.
Эта
ситуация
известна
под
названием
опции
одностороннего прерывания.
Обработка и оптимизация запросов
Обработка распределенных запросов (Distributed Query -DQ) задача, более сложная, нежели обработка локальных и она
требует решения с помощью особого компонента - оптимизатора
DQ.
Обратимся к базе данных, распределенной по двум узлам
сети. Таблица detail хранится на одном узле, таблица supplier - на
другом. Размер первой таблицы - 10000 строк, размер второй 100 строк (множество деталей поставляется небольшим числом
поставщиков). Результирующая таблица представляет собой
объединение таблиц detail и supplier. Данный запрос распределенный, так как затрагивает таблицы, принадлежащие
различным локальным базам данных. Для его нормального
выполнения необходимо иметь обе исходные таблицы на одном
узле. Значит, одна из таблиц должна быть передана по сети.
Очевидно, что это должна быть таблица меньшего размера, то
есть таблица supplier. Следовательно, оптимизатор DQ запросов
должен учитывать такие параметры, как, в первую очередь,
размер таблиц, статистику распределения данных по узлам,
объем данных, передаваемых между узлами, скорость
коммуникационных
линий,
структуры
хранения
данных,
соотношение производительности процессоров на разных узлах
и т.д. От интеллекта оптимизатора DQ впрямую зависит скорость
15
выполнения распределенных запросов.
В общем случае, обработка запроса - это процесс
трансляции декларативного определения запроса в операции
манипулирования данными низкого уровня. Стандартным языком
запросов, поддерживаемым современными СУБД, является SQL.
Оптимизация запроса - это процедура выбора «наилучшей»
стратегии для реализации запроса из множества альтернатив.
Для централизованной СУБД весь процесс состоит обычно из
двух шагов: декомпозиции запроса и оптимизации запроса.
Декомпозиция запроса - это трансляция его с языка SQL в
выражение реляционной алгебры. В ходе декомпозиции запрос
подвергается семантическому анализу; при этом некорректные
запросы отвергаются, а корректные упрощаются. Для заданного
SQL-запроса существует более чем одно алгебраическое
представление, причем некоторые из них могут быть «лучше»
других. «Качество» алгебраического выражения определяется
исходя из объема затрат, необходимых для его вычисления.
В распределенной СУБД между шагами декомпозиции и
оптимизации запроса включаются еще два действия:
локализация данных и глобальная оптимизация запроса.
Исходной информацией для локализации данных служит
алгебраическое выражение, полученное на этапе декомпозиции
запроса. В этом выражении фигурируют глобальные отношения
без учета их фрагментации или распределения. Сущность
данного шага заключается в том, чтобы локализовать
участвующие в запросе данные, используя информацию об их
распределении. При этом выявляются фрагменты, реально
участвующие в запросе, а запрос преобразуется к форме, где
операции применяются уже не к глобальным отношениям, а к
фрагментам. Распределенные отношения реконструируются
путем применения инверсии правил фрагментации. Это
называется программой локализации. Как и в шаге
декомпозиции, окончательный «хороший» фрагментный запрос
может быть еще далек от оптимального; данный процесс лишь
исключает
"плохие"
алгебраические
выражения.
Цель
глобальной оптимизации - найти стратегию выполнения запроса,
близкую к оптимальной.
Оптимизатор запросов обычно представляется в виде трех
компонентов: пространство поиска, модель стоимости и
16
стратегия поиска. Пространство поиска - это множество
альтернативных планов выполнения исходного запроса. Планы
эквивалентны в том смысле, что они дают один и тот же
результат, но различаются порядком и способами выполнения
отдельных операций. Модель стоимости - это способ оценить
стоимость реализации заданного плана. Стратегия поиска - это
способ обхода пространства поиска и выбора наилучшего плана.
Она определяет, какие планы и в каком порядке следует
выбирать и оценивать.
Результатом
работы
оптимизатора
является
оптимизированное алгебраическое выражение, включающее
коммуникационные операции над фрагментами.
Управление одновременным доступом
Если множество пользователей одновременно осуществляют
доступ (на чтение и запись) к разделяемой базе данных, то для
поддержания согласованного состояния данных необходимо
обеспечить синхронизацию доступа. Синхронизация достигается
путем применения алгоритмов управления одновременным
доступом, гарантирующих критерии корректности, такие как
сериализуемость. Алгоритмы управления одновременным
доступом обеспечивают свойство изолированности выполнения
транзакций, которое заключается в том, что результат
транзакции не может зависеть от других параллельно
выполняемых транзакций.
Наиболее
популярные
алгоритмы
управления
одновременным доступом основаны на механизме блокировок. В
такой схеме всякий раз, когда транзакция пытается получить
доступ к какой-либо единице памяти (как правило, странице), на
эту единицу накладывается блокировка в одном из режимов разделяемом или исключительном.
В алгоритмах, основанных на блокировании применяется
один из трех методов: централизованное блокирование,
блокирование первичной копии и распределенное блокирование.
При
централизованном
блокировании
для
всей
распределенной базы данных поддерживается единая таблица
блокировок. Эта таблица, располагаемая на одном из узлов,
находится под управлением единого менеджера блокировок.
Менеджер блокировок отвечает за установку и снятие
блокировок от имени всех транзакций. Поскольку управление
17
блокировками сосредоточено на одном узле, то оно аналогично
централизованному управлению одновременным доступом, и
глобальная сериализуемость обеспечивается достаточно легко.
Соответствующие алгоритмы просты в реализации, но с ними
связаны две проблемы. Во-первых, центральный узел может
стать узким местом как из-за большого объема обработки
данных, так и из-за генерируемого вокруг него интенсивного
сетевого трафика. Во-вторых, надежность такой системы
ограничена, поскольку отказ или недоступность центрального
узла приводит к выходу из строя всей системы.
Блокирование первичной копии - это алгоритм управления
одновременным доступом, применяемый для баз данных с
репликациями, где копии одних и тех же данных могут храниться
на множестве узлов. Одна из таких копий выделяется как
первичная, и для доступа к любому элементу данных
необходимо установить блокировку на его первичную копию.
Множество первичных копий элементов данных известно всем
узлам распределенной системы, и запросы транзакций на
блокирование направляются узлам, где хранятся первичные
копии. Если в распределенной базе данных репликации не
используются, то данный алгоритм сводится к алгоритму
распределенного блокирования.
Алгоритм распределенного (или децентрализованного)
блокирования предполагает распределение обязанностей по
управлению блокировками между всеми узлами системы. Для
выполнения транзакции необходимо участие и взаимная
координация менеджеров блокировок на нескольких узлах.
Блокировки устанавливаются на всех узлах, данные которых
участвуют в транзакции.
Общий побочный эффект всех алгоритмов управления
одновременным
доступом
посредством
блокирования
возможность тупиковых ситуаций. Задача обнаружения и
преодоления тупиков особенно сложна в распределенных
системах. Тем не менее, благодаря относительной простоте и
эффективности
алгоритмов
блокирования,
они
имеют
значительно большую популярность. чем альтернативные
алгоритмы, основанные на временных метках (timestamp-based
algorithms), а также алгоритмы оптимистического управления
одновременным доступом (optimistic concurrency control).
18
Алгоритмы, основанные на временных метках, выполняют
конфликтующие операции транзакций в соответствии с
временными метками, назначаемыми транзакциям при их
поступлении в систему. Алгоритмы оптимистического управления
одновременным доступом исходят из предположения о том, что
конфликты между транзакциями редки, и доводят транзакцию до
конца, а затем производят проверку корректности. Если
выясняется, что фиксация данной транзакции повлечет
нарушение сериализуемости, то транзакция откатывается и
запускается снова.
Межоперабельность
В контексте распределенных баз данных межоперабельность
означает две вещи.
Во-первых,
это качество, позволяющее обмениваться
данными между базами данных различных поставщиков.
Во-вторых, это возможность некоторого унифицированного
доступа к данным в DDB из приложения. Возможны как
универсальные
решения
(стандарт
ODBC),
так
и
специализированные подходы.
Специальные подходы - это, например, использование
шлюзов, позволяющее приложениям оперировать над базами
данных в «чужом» формате так, как будто это собственные базы
данных. Вообще, цель шлюза - организация доступа к
унаследованным (legacy) базам данных и служит для решения
задач согласования форматов баз данных при переходе к какойлибо одной СУБД.
Рассмотрим теперь проблемы распределенных БД:
а) Какова общая модель данных распределенной системы?
Мы должны иметь единую концептуальную схему всей сети. Это
обеспечит логическую прозрачность данных для пользователя, в
результате чего он сможет формировать запрос ко всей базе,
находясь за отдельным терминалом (т. е. как бы работая с
централизованной базой данных).
б) Необходима схема, определяющая местонахождение
данных в сети. Это обеспечит прозрачность размещения данных,
бла годаря которой пользователь может не указывать, куда
переслать запрос, чтобы получить требуемые данные.
в) Распределенные базы данных могут быть однородными
или неоднородными по аппаратным и программным средствам.
19
Проблему неоднородности сравнительно легко решить, если
распределенная база является неоднородной по аппаратным
средствам, но однородной по программным средствам
(одинаковые СУБД в узлах). Если же в узлах распределенной
системы используются разные СУБД, необходимы средства
преобразования структур данных и языков. Это должно
обеспечить
прозрачность
преобразования
в
узлах
распределенной базы данных.
г) Управление словарями. Для обеспечения всех видов
прозрачности в распределенной базе данных нужны программы,
управляющие многочисленными справочниками или словарями.
д) Методы выполнения запросов в распределенной базе
данных отличаются от аналогичных методов централизованных
СУБД, так как отдельные части запроса нужно выполнять на
месте рас положения соответствующих данных и передавать
частичные результаты на другие узлы; при этом должна быть
обеспечена координация всех процессов.
е) В распределенной базе данных нужен сложный механизм
управления одновременной обработкой, который, в частности,
должен
обеспечивать
синхронизацию
при
обновлениях
информации, то гарантирует непротиворечивость данных.
ж) Развитая методология распределения и размещения
данных, включая разбиение, является одним из основных
требований к распределенной базе данных.