
- •Лекция 11. Развитие бд: состояние и перспективы
- •Использование xml для описания данных
- •Реализация xml сервера
- •11.2 Объектно-ориентированные бд
- •11.3 Распределенные бд
- •Синхронизация доступа к данным
- •Управление транзакциями
- •Поддержание копий данных в нескольких узлах сети
- •Фрагментация объектов бд
- •Алгоритмы выполнения реляционных операций
- •11.4 Коммерческие бд
- •Архитектура "клиент-сервер" и параллельность обработки
- •Системы бд с многоуровневой защитой
- •11.5 Информационные хранилища
- •Логическая архитектура базы данных
- •Физическая архитектура базы данных
- •Индексные структуры
- •Материализованные представления
- •Концептуальная модель данных
11.3 Распределенные бд
В распределенных СУБД приходится решать все задачи, свойственные централизованным, но, как правило, в более сложных постановках. Кроме того, здесь возникают специфические проблемы, от решения которых во многом зависит эффективность, надежность и доступность систем БД. В настоящее время большинство распределенных СУБД базируется на реляционной модели данных и рассчитано на использование в локальных сетях ЭВМ. Но также имеются распределенные СУБД в территориально разнесенных сетях. Основные отличия от несетевых БД и, соответственно, проблемы связаны с синхронизацией доступа к данным, алгоритмами выполнения реляционных операций и управлением транзакциями.
Синхронизация доступа к данным
В централизованных системах БД очень распространено использование двухфазного протокола синхронизационных захватов объектов БД. В соответствии с этим протоколом объект БД автоматически захватывается транзакцией в соответствующем режиме при первом обращении, и все захваты данной транзакции освобождаются только при ее завершении. В случае возникновения конфликта по синхронизации транзакция блокируется, пока объект не будет освобожден. Следование этому протоколу может привести к возникновению синхронизационного тупика между двумя или более транзакциями. Задача СУБД - распознать появление тупика и разрушить его путем отката одной или нескольких транзакций.
Распознавание тупиков сводится к обнаружению циклов в графе ожидания транзакций, что является трудоемкой задачей даже в централизованных СУБД.
Поэтому более часто в распределенных системах применяются протоколы синхронизации, основанные на временных метках. Это направление само по себе очень широко, имеются разные варианты и даже комбинации с протоколом двухфазных захватов, но основной проблемой реализации является отсутствие в распределенной системе единого времени.
Управление транзакциями
В истинно распределенной СУБД транзакции естественно утрачивают линейную структуру. Распределенная транзакция в общем случае представляет собой дерево, промежуточными узлами которого являются распределенные подтранзакции, а листья соответствуют обычным линейным транзакциям локальных СУБД.
Основной проблемой управления транзакциями в этом случае является корректное завершение (фиксация) распределенной транзакции. Классическим решением является использование давно известного протокола двухфазной фиксации.
Поддержание копий данных в нескольких узлах сети
Основным накладным расходом при выполнении распределенного запроса является пересылка данных между узлами сети. Одним из способов сокращения этого накладного расхода является поддержание копий наиболее часто используемых данных в нескольких узлах сети с учетом порождаемых этим дополнительных накладных расходов по поддержанию согласованности копий при модификации данных.
Другим основанием для поддержания копий является увеличение уровня доступности данных при выходе из строя узлов сети или коммуникационных линий, вследствие чего утрачивается связность сети.
Фрагментация объектов бд
Альтернативный предыдущему подход, обеспечивающий максимальное распараллеливание выполнения запроса к БД, состоит в том, что отношение (если говорить в терминах реляционной модели данных) разбивается на ряд вертикальных или горизонтальных фрагментов, и эти фрагменты хранятся в разных узлах сети.
Понятно, что теоретически это может обеспечить убыстрение выполнения запроса, затрагивающего фрагментированное отношение, но практически добиться этого очень трудно. Основная проблема состоит в резком расширении пространства поиска вариантов выполнения запросов, с которым должен работать оптимизатор запросов.
Имеются предложения и исследования, связанные с комбинацией поддержания копий и фрагментацией объектов БД. В этом случае поддерживаются копии фрагментов, что, вообще говоря, решает обе задачи, но еще больше усложняет реализацию.