48

В качестве примеров программ, поддерживающих работу серверов приложе-

ний, можно привести BEA WebLogic Server, Inprise Application Server и IBM WebSphere Application Server [ 15 ].

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

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

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

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

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

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

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

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

Репликация (тиражирование) БД Эта стратегия допускает хранение одинаковых данных в нескольких узлах

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

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

49

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

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

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

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

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

3.Централизованный подход – глобальный каталог данных хранится только

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

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

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

На практике перечисленные подходы не используются, в основном применяется метод перманентных идентификаторов [ 2, 12 ]. Идея метода заключает-

50

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

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

кузлу, где объект был создан, и определяет по каталогу этого узла новое место хранения объекта.

При совместной работе нескольких пользователей с общей информацией мо-

гут применяться монопольный и коллективный методы доступа к распреде-

ленным данным.

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

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

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

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