Добавил:
ivanov666
Опубликованный материал нарушает ваши авторские права? Сообщите нам.
Вуз:
Предмет:
Файл:Базы данных. Лекции по курсу. В 4 частях. Ч.1. Учебное пособие
.pdf
I. select * from T1
where место_сборки = ”Беркли”
and название_изделия in
(select название_изделия from T2
where название_детали in
(select название_детали from T3
where название_комплектующего = ”Болт”
))
II. select все столбцы T1
from T1, T2, T3
where T1.название_изделия = T2. название_изделия
and T2.название_детали = T3. название_детали
and.место_сборки = “Беркли”
and T3.название_комплектующего = “Болт”
Данные запросы – распределенные, поскольку затрагивают таблицы, принадлежащие различным локальным базам данных. Для их выполнения необходимо иметь все исходные таблицы на одном узле.
Следовательно, одна из таблиц должна быть передана по сети.
1. Простейшая стратегия – перемещение таблиц в узел, из которого
поступил запрос:
a) если запрос поступил из узла Б, необходимо
перемещение таблиц T1, T2 в узел Б (101 Мбайт); при скорости 1 Мбайт/с это займет
101 с;
б) если запрос поступил из узла А, необходимо перемещение таб-
лицы T3 в узел А (10 Мбайт); при скорости 1 Мбайт/с это займет 10 с.
2. Лучшая стратегия – создание подмножества данных по названию
детали (болт) и месту сборки изделий (
Беркли):
a) если запрос поступил из узла Б, необходимо перемещение
100 000 записей о поставках из таблицы T2 и 1000 описаний изделий
из таблицы T1 в узел Б (10 100 000 байт); при скорости 1 Мбайт/с это
составит ~ 10 с;
б) если запрос поступил из узла А, необходимо перемещение
10 записей описаний деталей из таблицы T3 в узел А (1000 байт); при
скорости 1 Мбайт/с это составит ~ 0,1 с.
61
3. Стратегия, исключающая вариации.
Вне зависимости от узла 1000-байтовая проекция таблицы деталей
передается из узла Б в узел А, там получается результат и, если запрос
поступил из узла Б, результат пересылается обратно.
Прозрачность распределенности (полная прозрачность располо-
жения данных).
В идеале пользователь, обращающийся к DDB, ничего не должен
знать о реальном, физическом размещении данных в узлах сети. Все
операции над данными выполняются без учета их местонахождения.
Приложение (клиент) указывает, не что делать, а что он хочет, а сервер
решает, как это обеспечить. Но это только
в идеале, поэтому в рамках
прозрачности распределенности выделяют несколько уровней:
прозрачность локального отображения;
прозрачность расположения;
прозрачность фрагментации.
Рассмотри пример. Отношение
раздела: для отдела кадров раздел
) с информацией о сотрудниках компании и раздел Emp_salary
tion
Staff разбито на два вертикальных
Employee (emp_id, emp_name, posi-
(emp_id, salary) в базе данных в узле в Далласе для бухгалтерии. Раздел
Employee (emp_id, emp_name, position), в свою очередь, разбит на два
горизонтальных раздела: таблица
) в базе данных узла в Бостоне и таблица Employee2 (emp_id,
tion
emp_name, position
), определенная в базе данных узла в Денвере
Employee1 (emp_id, emp_name, posi-
(рис. 27).
Рис. 27. Расположение данных
В случае прозрачности локального отображения предполагается
знание пользователем как имен фрагментов, так и их расположения.
62
В этом случае запрос «Получить информацию о заработной плате
сотрудников-менеджеров компании» будет выглядеть следующим образом:
select y.emp_id, x.emp_name, y.salary
from Employee1@boston x, Emp_salary@dallas y
where x.emp_id = y.emp_id and position=”Manager”
union
select y.emp_id, x.emp_name, y.salary
from Employee2@denver x, Emp_salary@dallas y
where x.emp_id = y.emp_id and position=”Manager”
В случае прозрачности расположения предполагается, что пользователь имеет сведения о способах фрагментации, но не нуждается в
сведениях о расположении данных. Тот же запрос на этом уровне запишется следующим образом:
select y.emp_id, x.emp_name, y.salary
from Employee1 x, Emp_salary y
where x.emp_id = y.emp_id and position=”Manager”
union
select y.emp_id, x.emp_name, y.salary
from Employee2 x, Emp_salary y
where x.emp_id = y.emp_id and position=”Manager”
Основное преимущество прозрачности расположения состоит в
том, что база данных может подвергнуться реорганизации, но это никак не скажется на приложении.
В случае
прозрачности фрагментации, предполагается, что поль-
зователь ничего не знает, как фрагментированы таблицы. Тот же запрос на этом уровне примет вид
select emp_id, emp_name, salary
from Staff position=”Manager”
Записанный запрос выглядит как SQL-запрос в централизованной
базе данных.
63
Свойство прозрачности распределенности DDB в реальных СУБД
поддерживается различными механизмами. Разработчики СУБД придерживаются различных подходов. В одном из подходов задача решается с помощью SQL-оператора
CREATE SYNONYM, который позволя-
ет создавать новые имена для существующих таблиц. Так, запись
create synonym customer for client@central:smith.customer
означает, что любое обращение к таблице customer в открытой базе
данных будет автоматически переадресовано на компьютер
базу данных
client к таблице customer пользователя smith. В результате
central в
мы можем написать полностью независимый от расположения базы
данных запрос:
select customer.cust_name, order.order_date from customer, order
where customer.cust_number = order.cust_number
При таком подходе мы можем переместить таблицу из одной базы
данных в другую, оставив в первой базе ссылку на ее новое местонахождение, при этом все необходимые действия для доступа к содержимому таблицы будут сделаны автоматически.
Прозрачность тиражирования
Тиражирование данных – это в общем случае асинхронный процесс
переноса изменений объектов исходной базы данных в базы данных,
расположенные в других узлах распределенной системы. В таком контексте прозрачность тиражирования означает возможность переноса
изменений между базами данных средствами, невидимыми пользователю распределенной системы.
Независимость от оборудования
Это свойство означает, что в качестве узлов распределенной системы могут использоваться компьютеры любых моделей и производителей – от мэйнфреймов до «персоналок».
Независимость от операционных систем
Это качество означает многообразие операционных систем, управляющих узлами распределенной базы данных.
Прозрачность сети
64
Данное свойство означает широкий спектр поддерживаемых конкретной СУБД сетевых протоколов.
Независимость от баз данных
Это качество означает, что в распределенной системе могут мирно
сосуществовать СУБД различных производителей.
3.2. ТЕХНОЛОГИИ БАЗ ДАННЫХ
Функционирование распределенных баз данных обеспечивается
набором технологий, которые принято называть технологиями DDB. К
числу таковых обычно относятся следующие технологии:
обработка и оптимизация запросов (I);
управление одновременным доступом (II);
целостность данных и протоколы обеспечения надежности (III);
технология тиражирования данных (IV).
I. Обработка и оптимизация запросов
Обработка запроса – это процесс трансляции декларативного запроса в операции манипулирования данными низкого уровня.
Оптимизация запроса – это процедура выбора «наилучшей» стратегии для реализации запроса из множества альтернатив.
Для централизованной СУБД процесс обработки запроса состоит
из двух шагов:
декомпозиции запроса (1);
оптимизации запроса (2).
1. Декомпозиция запроса – это трансляция запроса с языка SQL
в выражение реляционной алгебры. В ходе декомпозиции запрос подвергается семантическому анализу, при этом некорректные запросы
отвергаются, а корректные упрощаются.
2. Для заданного SQL-запроса существует более чем одно алгебраическое представление, причем некоторые из них могут быть «лучше»
других. «Качество» алгебраического выражения
определяется исходя
из объема затрат, необходимых для его вычисления. Оптимизация запроса состоит в выборе «наиболее хорошего» представления.
В распределенной СУБД между шагами декомпозиции и оптимиза-
ции в запрос включаются еще две операции:
65
локализация данных (1+);
глобальная оптимизация запроса (2–).
Ранее в лекции отмечалось, что правила фрагментации выражаются
посредством реляционных операций селекции для горизонтальной
фрагментации и проекции для вертикальной.
На этапе локализации данных распределенные отношения реконструируются путем применения инверсии правил фрагментации. Это
называется программой локализации. Программа локализации для горизонтально фрагментированного запроса – это объединение (union)
его фрагментов, для
вертикально фрагментированного запроса – со-
единение (join) его фрагментов.
Цель глобальной оптимизации – найти стратегию выполнения распределенного запроса с учетом:
дискового пространства,
числа обменов с дисками,
времени CPU,
коммуникационных затрат и т. д.
Обычно это некоторая взвешенная сумма затрат ввода-вывода, CPU
и коммуникаций.
Иногда в распределенных СУБД применяется упрощенный подход,
когда в качестве наиболее значимых рассматриваются лишь коммуникационные затраты.
II. Управление одновременным доступом
Проблема управления одновременным доступом состоит в поддержании согласованного состояния данных, это обеспечивается использованием широкого спектра алгоритмов: алгоритма синхронизационных захватов (метода блокировок), метода временных меток, метода
выделения версий данных и т. д
.
Для распределенных СУБД те же задачи переносятся в распределенную среду: транзакции могут выполняться на нескольких узлах, где
располагаются необходимые данные.
66
Наиболее популярные алгоритмы управления одновременным доступом основаны на механизме блокировок. Самыми распространенными являются следующие протоколы:
централизованный протокол двухфазной блокировки;
блокировка первичной копии;
распределенный протокол двухфазной блокировки.
При централизованной блокировке для всей распределенной базы
данных поддерживается единая таблица блокировок. Эта таблица, располагаемая на одном из узлов, находится под управлением единого
программного компонента – менеджера блокировок. Менеджер блокировок отвечает за установку и снятие блокировок от имени всех транзакций.
С данным алгоритмом связаны две
проблемы. Во-первых, центральный узел может стать узким местом как из-за большого объема
обработки данных, так и из-за интенсивного сетевого трафика. Во-вторых, надежность такой системы ограничена, поскольку отказ или недоступность центрального узла приводит к выходу из строя всей системы.
Блокировка первичной копии – это
алгоритм управления одновременным доступом, применяемый для баз данных с репликациями,
где копии одних и тех же данных могут храниться на множестве узлов. Одна из таких копий выделяется как первичная, и для доступа к
элементу данных любого узла необходимо установить блокировку на
его первичную копию. Множество первичных копий элементов дан
ных известно всем узлам распределенной системы, и запросы транзакций на блокирование направляются узлам, где хранятся первичные копии (при этом данные могут быть взяты с другого узла). После
того как первичная копия будет обновлена, внесенные изменения
могут быть распространены на все ведомые копии (желательно с
максимальной скоростью). Этот алгоритм
хорош для нечастых об-
новлений данных.
Алгоритм распределенной блокировки предполагает распределение
обязанностей по управлению блокировками между всеми узлами системы. Блокировки устанавливаются на всех узлах, данные которых
участвуют в транзакции. Для операции считывания используется лю-
-
67
бая копия, при выполнении операции обновления блокируются все
копии, где содержится блокируемый элемент.
Алгоритмам распределенной блокировки не свойственны недостатки механизма централизованной блокировки, связанные с перегруженностью центрального узла. Однако алгоритмы этого типа сложнее, а
коммуникационные затраты, необходимые для установки всех требуемых блокировок, значительно выше.
Общий побочный эффект всех алгоритмов
управления одновременным доступом посредством блокирования – возможность тупиковых ситуаций. Задача обнаружения и преодоления тупиков особенно
сложна в распределенных системах. Тем не менее благодаря относительной простоте и эффективности алгоритмов блокировки они более
популярны, чем альтернативные алгоритмы, основанные на временных
метках и протоколах оптимистичного управления одновременным
доступом.
Алгоритмы, основанные на
временных метках, выполняют конфликтующие операции транзакций в соответствии с временными метками, присвоенными транзакциям при их регистрации.
Алгоритмы оптимистичного управления выполняются в предположении о том, что конфликты между транзакциями редки, и доводят
транзакцию до конца, а затем производят проверку корректности. Если
выясняется, что фиксация данной транзакции повлечет нарушение
сериализуемости
, транзакция откатывается и запускается снова.
III. Целостность данных и протоколы обеспечения надежности
В качестве протокола атомарной фиксации выступает уже упомянутый протокол двухфазовой фиксации транзакций (2PC – 2 Phase
Commit).
Три основных принципа лежат в его основе.
1. Если хотя бы один узел отказывается зафиксировать транзакцию
(голосует за ее прерывание), то распределенная транзакция прерывается во всех узлах.
2. Если все узлы голосуют за фиксацию транзакции, то она
фикси-
руется во всех участвующих в ней узлах.
3. Проголосовавший участник не может изменить свое решение.
68
Первая фаза протокола – подготовка к фиксации транзакции (голо-
сование).
Вторая фаза протокола – глобальная фиксация или откат транзак-
ции (принятие решения).
В простейшем варианте работа 2PC выглядит следующим образом.
В узле, где инициируется транзакция, создается процесс-коор-
динатор, во всех прочих затрагиваемых ею узлах создаются процессыучастники. Координатор рассылает участникам сообщение
PREPARE,
и каждый из них независимо решает, может ли транзакция завершиться
в данном узле. Координатор ожидает в пределах установленного таймаута. Участники, которые готовы завершить транзакцию, посылают
координатору сообщение
READY TO COMMIT. Участники, не имею-
щие возможности зафиксировать свою часть транзакции, возвращают
сообщение
Если все участники проголосовали за завершение транзакции,
READY TO ROLLBACK.
координатор принимает решение зафиксировать транзакцию (все
участники подтвердили согласие), и всем участникам рассылается сообщение
GLOBAL_COMMIT. Координатор ожидает в пределах уста-
новленного тайм-аута реакцию от всех узлов. Если хотя бы один
участник высказался за прерывание транзакции, координатор прерывает транзакцию, и всем участникам, высказавшимся за транзакцию, посылается сообщение
Получив сообщение GLOBAL_COMMIT, участник транзакции
GLOBAL_ABORT.
завершает и фиксирует свою часть транзакции и посылает координатору сообщение
COMMIT. После получения от всех участников сообще-
ний о фиксации транзакций координатор завершает транзакцию. Если
некоторые участники не прислали сообщения о фиксации, координатор продолжает их опрашивать до получения требуемых подтверждений.
IV. Технология тиражирования данных
Современные информационные системы предъявляют достаточно
высокие требования к скорости отработки информации при условии
одновременной работы большого количества клиентов.
Основной недостаток физического распределения данных – жесткие требования к скорости и надежности каналов связи. Если база дан-
69
ных распределена по нескольким территориально удаленным узлам,
объединенным относительно медленными и ненадежными каналами
связи, а число одновременно работающих пользователей составляет
сотни и выше, то вероятность того, что распределенная транзакция
будет зафиксирована в обозримом временном интервале, становится
чрезвычайно малой.
В действительности далеко не во всех задачах требуется обеспечение идентичности базы данных
в различных узлах в любое время. Достаточно поддерживать тождественность данных лишь в определенные
критичные моменты. Следовательно, можно накоплять изменения в
данных в виде транзакций в одном узле и периодически копировать
эти изменения на другие узлы.
Так часто поступают при развитии компании, когда создаются уда-
ленные филиалы, магазины и склады.
Каждая удаленная информационная система с целью повышения устойчивости работает самостоятельно, периодически отправляя в Центральный офис консолидированную информацию.
Тиражирование данных (Data Replication – DR) – это асинхронный
перенос изменений объектов исходной базы данных (source database) в
базы данных других узлов распределенной системы. Функции DR выполняет специальный модуль СУБД – сервер тиражирования данных,
называемый репликатором (replicator). Его задача – поддержка
иден-
тичности в принимающих в исходных базах данных.
Репликации можно классифицировать по-разному.
1. По направлению репликации:
однонаправленная репликация – данные изменяются только в
одной из баз данных, а в другой не подвергаются изменениям;
многонаправленная репликация – данные могут изменяться и
вводиться во всех базах данных.
2. По времени проведения сеанса репликации:
репликация реального времени – данные должны быть синхро-
низированы немедленно после их изменений;
отложенная, или асинхронная, репликация – процесс репликации
запускается по какому-либо событию во времени.
70
Соседние файлы в предмете [НЕСОРТИРОВАННОЕ]