4.4. Управление распределенными данными
При работе с распределенными базами данных необходимо решать две проблемы:
сохранения согласованности БД при одновременных изменениях хранимых данных в нескольких узлах системы;
обеспечения совместного доступа нескольких пользователей к общей информации.
Для организации распределенной базы данных могут быть использованы две стратегии.
Фрагментация БД
В рамках этой стратегии база данных делится на фрагменты, размещаемые в разных узлах системы. В полностью фрагментированной системе данные не должны дублироваться (на практике реализовать это требование практически невозможно). Сведения о месте расположения и других характеристиках каждого фрагмента хранятся в глобальном словаре данных, который может распределяться между несколькими узлами или содержаться только в одном из них.
Достоинствами фрагментации БД являются экономное использование внешней памяти (уменьшается дублирование информации) и постоянное поддержание базы данных в актуальном состоянии. Недостаток – высокие требования к пропускной способности и надежности каналов связи, по которым практически непрерывно передаются команды и данные.
Репликация (тиражирование) БД
Эта стратегия допускает хранение одинаковых данных в нескольких узлах системы. В идеальной распределенной базе данных такого дублирования информации не должно быть, тем не менее на практике оно используется достаточно часто для обеспечения требований производительности, доступности и безопасности. Репликация является обоснованной, например, если одни и те же данные регулярно используются в различных узлах.
Каждая копия данных обрабатывается (в том числе и изменяется) пользователями автономно, независимо друг от друга. Идентичность копий обеспечивается передачей сделанных изменений между узлами с помощью компонента системы, называемого репликатором [ 15 ]. Передача изменений выполняется асинхронно, поэтому аналогичные данные, хранящиеся в различных узлах, некоторое время могут различаться между собой (это является основным недостатком метода). Другой недостаток – большие затраты внешней памяти для хранения информации.
По сравнению со стратегией фрагментации БД, репликация обеспечивает более высокую скорость обращения пользователей к данным; уменьшение объема информации, передаваемой по сети; меньшую зависимость качества работы системы от используемых каналов связи.
Сведения о месте расположения и других характеристиках каждого объекта распределенной базы данных хранятся в глобальном словаре данных (каталоге). Хранение глобального словаря данных и управление им могут реализовываться различными способами [ 2, 12 ]:
1. Полностью распределенный подход – в каждом узле системы содержится часть глобального каталога, характеризующая только объекты базы данных, хранящиеся в этом узле. Работа системы не зависит от некоторого центра управления, при необходимости доступа из одного узла к данным, размещенным в другом узле, требуется просмотр всех локальных каталогов, пока не будет найдена необходимая информация.
2. Полностью реплицированный подход – полная копия глобального каталога данных хранится в каждом узле системы. При этом ускоряется поиск нужных данных, но при изменении объекта базы данных в одном узле требуется обновление каталогов, хранящихся во всех узлах.
3. Централизованный подход – глобальный каталог данных хранится только в одном узле системы. Обеспечение работы системы требует более простых средств, чем при реализации других подходов, но качество работы системы во многом зависит от надежности функционирования узла, в котором находится каталог. Кроме того, этот подход предъявляет повышенные требования к ресурсам системы.
4. Комбинированный подход – в каждом узле системы содержится локальный каталог, включающий сведения о части базы данных, размещенной в этом узле, в одном из узлов хранится и глобальный каталог данных. Этот подход более эффективен, чем централизованный, но также требует высокой надежности работы узла, в котором хранится глобальный каталог данных.
На практике перечисленные подходы не используются, в основном применяется метод перманентных идентификаторов [ 2, 12 ]. Идея метода заключается в том, что каждый объект базы данных имеет логическое имя (на которое при работе ссылаются пользователи) и системное имя, включающее идентификаторы узла, в котором был создан объект, и узла, в котором в данное время хранится объект. После создания объекта его системное имя заносится в каталоги данных всех других узлов.
В каталоге каждого узла хранятся сведения о каждом объекте, созданном или хранимом в этом узле. Перемещения объекта базы данных между узлами отслеживаются локальным каталогом узла, в котором был создан объект. Если какому-нибудь узлу системы необходим этот объект, он предварительно обращается к узлу, где объект был создан, и определяет по каталогу этого узла новое место хранения объекта.
При совместной работе нескольких пользователей с общей информацией могут применяться монопольный и коллективный методы доступа к распределенным данным.
Монопольный доступ организуется с помощью полных блокировок, реализуемых непосредственно СУБД или прикладными программами. Монопольный доступ к данным обычно применяется при работе с конфиденциальной информацией или при выполнении фундаментальных преобразований БД (например, изменения ее структуры), когда требуется полностью исключить работу с данными других пользователей [ 15 ].
В режиме коллективного доступа к данным полная блокировка не допускается. Применяется механизм временных блокировок, ограничивающих или запрещающих работу пользователя или приложения с объектами базы данных, когда эти объекты используются другими пользователем или приложением. Например, если реплицированные данные изменяются в одном узле системы, в других узлах они блокируются. После фиксации сделанных обновлений в узле, где они были выполнены, другие узлы пытаются изменить свои реплицированные данные и зафиксировать полученные результаты. Данные в исходном узле остаются заблокированными до тех пор, пока обновления не будут зафиксированы во всех узлах. Если в одном или нескольких узлах реализовать обновления данных не удалось, производится отмена (откат) выполненных действий в масштабах всей системы.
Расширением рассмотренной технологии является метод двухфазной фиксации транзакций (понятие транзакции будет рассмотрено в п. 5) [ 15 ].
На первом этапе регистрируются все изменения, происходящие в отдельных узлах системы. При этом временно сохраняется возможность их отмены. Информация о сделанных изменениях пересылается управляющему компоненту системы, контролирующему данный процесс.
На втором этапе, после получения от всех узлов системы подтверждения о правильности и непротиворечивости выполненных операций, управляющий компонент системы передает всем узлам команду окончательно зафиксировать сделанные изменения.
- Содержание
- Предисловие
- Введение
- 1. Основные понятия баз данных
- 1.1. Банк данных и его компоненты
- Пользователи
- Прикладные
- 1.2. Модели данных
- 2. Целостность баз данных
- Условие на значение “Парус” or “Волна” or “Лотос”
- 3. Внутренняя организация субд
- 3.1. Общие положения
- 3.2. Линейный список
- 3.3. Инвертированный список
- 3.4. Индексы
- 3.5. Хеширование
- Область переполнения
- 3.6. Кластеризация
- 4. Распределенная обработка данных
- 4.1. Режимы работы с базой данных
- Параллельный
- 4.2. Архитектура «клиент-сервер»
- Приложения
- 4.3. Модели «клиент-сервер»
- 4.4. Управление распределенными данными
- 5. Восстановление баз данных
- 5.1. Транзакции
- 5.2. Журнал транзакций
- 5.3. Выполнение транзакций в многопользовательских системах
- 6. Защита баз данных
- 7. Основы проектирования реляционных баз данных
- 7.1. Этапы проектирования
- 7.2. Построение концептуальной модели предметной области
- 7.3. Логическое проектирование базы данных
- 7.4. Нормализация отношений
- 7.5. Автоматизированные технологии проектирования баз данных
- Заключение
- Библиографический список