4.4. Управление распределенными данными

При работе с распределенными базами данных необходимо решать две проблемы:

1. сохранения согласованности БД при одновременных изменениях хранимых данных в нескольких узлах системы;

2. обеспечения совместного доступа нескольких пользователей к общей информации.

Для организации распределенной базы данных могут быть использованы две стратегии.

Фрагментация БД

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

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

Репликация (тиражирование) БД

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

Каждая копия данных обрабатывается (в том числе и изменяется) пользователями автономно, независимо друг от друга. Идентичность копий обеспечивается передачей сделанных изменений между узлами с помощью компонента системы, называемого репликатором [ 15 ]. Передача изменений выполняется асинхронно, поэтому аналогичные данные, хранящиеся в различных узлах, некоторое время могут различаться между собой (это является основным недостатком метода). Другой недостаток – большие затраты внешней памяти для хранения информации.

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

Сведения о месте расположения и других характеристиках каждого объекта распределенной базы данных хранятся в глобальном словаре данных (каталоге). Хранение глобального словаря данных и управление им могут реализовываться различными способами [ 2, 12 ]:

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

2. Полностью реплицированный подход – полная копия глобального каталога данных хранится в каждом узле системы. При этом ускоряется поиск нужных данных, но при изменении объекта базы данных в одном узле требуется обновление каталогов, хранящихся во всех узлах.

3. Централизованный подход – глобальный каталог данных хранится только в одном узле системы. Обеспечение работы системы требует более простых средств, чем при реализации других подходов, но качество работы системы во многом зависит от надежности функционирования узла, в котором находится каталог. Кроме того, этот подход предъявляет повышенные требования к ресурсам системы.

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

На практике перечисленные подходы не используются, в основном применяется метод перманентных идентификаторов [ 2, 12 ]. Идея метода заключается в том, что каждый объект базы данных имеет логическое имя (на которое при работе ссылаются пользователи) и системное имя, включающее идентификаторы узла, в котором был создан объект, и узла, в котором в данное время хранится объект. После создания объекта его системное имя заносится в каталоги данных всех других узлов.

В каталоге каждого узла хранятся сведения о каждом объекте, созданном или хранимом в этом узле. Перемещения объекта базы данных между узлами отслеживаются локальным каталогом узла, в котором был создан объект. Если какому-нибудь узлу системы необходим этот объект, он предварительно обращается к узлу, где объект был создан, и определяет по каталогу этого узла новое место хранения объекта.

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

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

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

Расширением рассмотренной технологии является метод двухфазной фиксации транзакций (понятие транзакции будет рассмотрено в п. 5) [ 15 ].

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

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