Если механизм накопления данных в мощных корпоративных системах (снизу вверх) можно считать более или менее отработанным, проблема эффективного распределения этих данных по различным узлам сети (сверху вниз) пока не имеет однозначного решения. Особенно актуальна оптимизация процессов извлечения и модификации данных по клиентскому периметру БД: на уровне отделов, рабочих групп, индивидуальных рабочих мест и мобильных портативных ПК.
Начиная с 1993 г. для решения этой задачи разработчики СУБД применяют различные механизмы реплицирования, связанные с хранением и модификацией копий одних и тех же данных на разных узлах сети. Эти механизмы различаются между собой прежде всего направлением потока данных: распределенная (горизонтальная) и децентрализованная (вертикальная) репликации. Распределенная репликация предполагает однородную структуру узлов сети и поддерживает согласованный обзор данных всеми пользователями (когда каждый клиент в один и тот же момент времени видит одни и те же данные). Такой механизм эффективен при сравнительно небольшом числе участников обмена данными и не очень подходит для нерегламентированного подключения к сети случайных клиентов. Кроме того, синхронизация изменений данных в такой модели требует больших накладных расходов. Вертикальная репликация более приспособлена к нуждам многочисленных потребителей информации на рабочих местах и мобильных клиентов.
В новых версиях сервера SQLBase фирма Gupta продолжает активно совершенствовать именно те характеристики своего продукта, которые и обеспечили ему успех в определенном секторе рынка (SQLBase, по-видимому, лучший сервер для среднемасштабных информационных систем в сетях NetWare). Основная идея подхода Gupta - создать вертикальный механизм репликации изменений в децентрализованных гетерогенных базах данных. Решения Gupta гарантируют целостность и согласованность данных, даже когда транзакции выполняются над одними и теми же данными в двух или более различных БД. Разработанный механизм позволяет поддерживать мобильные приложения, а также приложения с нерегламентированным доступом к информации: транзакции могут выполняться в компактных локальных БД с последующей синхронизацией данных в центральной базе данных либо через локальную сеть (когда возможно), либо через службу сообщений. Для обслуживания репликаций предусмотрен стандартный графический интерфейс инструментария SQLConsole (администрирование баз данных Gupta).
ЧТО ТАКОЕ РЕПЛИКАЦИЯ В SQLBASE
По соглашениям, принятым в SQLBase, репликация представляет собой набор операций над выбранной совокупностью объектов (будем называть ее набором репликации), который согласованно выполняется между двумя типами БД: диспетчером репликации и подписчиками репликации. Диспетчер репликации - это сервер с базой данных, на которую и из которой один или более подписчиков репликации будут реплицировать данные. Диспетчер репликации может быть сервером SQLBase или гетерогенным сервером БД (например, СУБД Oracle или Informix). Подписчики репликаций должны быть серверами SQLBase или SQLBase для настольного ПК (сервер и клиент на одной машине). Например, сервер предприятия является диспетчером данных, сервер отдела может играть роль как подписчика по отношению к головному серверу, так и роль диспетчера для индивидуальных подписчиков, работающих на настольных компьютерах.
С набором репликации связаны три фазы цикла репликации: описание (определение), инициализация и синхронизация.
ОПИСАНИЕ РЕПЛИКАЦИИ
Описание выполняется администратором в зоне диспетчера репликаций с помощью графического интерфейса пользователя, аналогичного интерфейсу диспетчера файлов Windows (это расширение Database Object Manager в SQL Console). Для описания необходимо указать, какие объекты участвуют в репликации (пользователи и таблицы), а затем установить атрибуты набора репликации.
Для этого на левой панели окна диспетчера репликаций вы щелкаете мышью на желаемом объекте, а затем перемещаете его на правую панель, где и составляется набор репликации. В этот набор можно включить любое число объектов из левой панели. Для каждого подписчика можно указать только те столбцы или строки таблиц, которые ему требуются. Другими словами, можно явно описать вертикальную выборку данных (столбцы таблицы) или горизонтальную выборку, строки которой определяются условием WHERE в операторе SQL.
Иллюстрация работы диспетчера репликации
Кроме того, необходимо определить и режим передачи данных от диспетчера к подписчику - либо полное обновление (режим “насоса”), либо передачу изменений данных. При описании набора устанавливается направление, в котором данные будут реплицироваться: диспетчер - подписчик, подписчик - диспетчер или двунаправленное. Если предполагается, что одни и те же данные могут обновляться и у диспетчера, и у одного или более подписчиков, необходимо также выбрать механизм разрешения возможных конфликтов.
Процесс описания репликации создает в базе данных диспетчера все объекты, необходимые для синхронизации возможных изменений, в частности фоновые таблицы для запоминания изменений в данных.
Инициализация репликации
Следующая фаза работы с репликациями - инициализация, запускаемая индивидуальными подписчиками. В результате объекты БД, метаданные (системная информация) и сами данные направляются диспетчером каждому подписчику. Процесс инициализации завершается при запуске процесса синхронизации. К этому времени подписчик уже располагает всем, что необходимо для успешной синхронизации, включая собственные фоновые таблицы для фиксации изменений данных.
Если описание набора репликации изменяется, повторно выполняется и инициализация. Чтобы гарантировать, что изменения в наборе репликации (у диспетчера) не разрушат данные, введен механизм поддержки номеров версий набора репликации. Если подписчик пытается синхронизировать данные, используя старый набор репликации, фиксируется конфликт и эти данные перехватываются для ручной обработки.
СИНХРОНИЗАЦИЯ РЕПЛИКАЦИИ
Репликация не требует вмешательства администратора: именно подписчик, а не диспетчер, запускает процесс синхронизации и сбрасывает его (с помощью средств Gupta или любого другого приложения, использующего одноименный интерфейс).
Процесс синхронизации выполняется в несколько шагов:
(1) подписчик запускает синхронизацию;
(2) изменения данных передаются от подписчика диспетчеру;
(3) изменения данных у подписчика сравниваются с изменениями данных у диспетчера;
(4) изменения пересылаются в базу данных диспетчера;
(5) изменения данных у диспетчера пересылаются в базу данных подписчика.
Синхронизацию можно повторять несколько раз.
СОГЛАСОВАННОСТЬ ТРАНЗАКЦИЙ И ЦЕЛОСТНОСТЬ ДАННЫХ
Самая сложная проблема децентрализованной репликации данных связана с тем обстоятельством, что одни и те же данные могут располагаться и обновляться не в одном, а в нескольких местах. Как быть, если модифицирована строка, которая входит в таблицы разных БД?
Традиционный подход к решению этой проблемы - использование механизма двухфазной фиксации транзакции - требует, чтобы изменения во всех узлах, вовлеченных в транзакцию, фиксировались синхронно или чтобы во всех узлах синхронно выполнялся откат. Однако в большинстве систем двухфазная фиксация оказывается слишком непрактичным и дорогим решением.
С точки зрения экономии системных ресурсов репликация представляется более привлекательной, так как фиксация измененных данных на узлах выполняется асинхронно (когда возникает возможность или по требованию администратора). Однако при таком подходе возможны конфликты в данных.
В механизме репликаций SQLBase предусмотрено два способа решения этой проблемы. Во-первых, можно использовать режим уклонения от конфликтов, т. е. режим работы, который гарантирует, что конфликтов просто не будет. Во-вторых, можно использовать режим, допускающий одновременное обновление данных более чем в одном месте, но гарантирующий, что все конфликты будут зафиксированы для последующего разрешения. В последнем случае предусматривается возможность автоматического разрешения конфликтов. Во всех случаях механизм репликации SQLBase поддерживает согласованность транзакций и целостность данных.
Для уклонения от конфликтов достаточно выбрать одностороннее направление репликации для конкретной выборки (т. е. совокупности столбцов или строк): диспетчер - подписчик или подписчик - диспетчер. В этом случае данные могут обновляться только в одном месте и возникновение конфликтов становится невозможным.
Разрешение конфликтов
Если при описании набора репликации вы допустили возможность возникновения конфликтов, SQLBase предлагает следующий механизм разрешения.
Поиск конфликтов ведется диспетчером репликации при сравнении данных, поступивших от подписчика, с данными, зафиксированными в фоновых таблицах диспетчера. Если конфликтов не обнаружено (т. е. строки, полученные от подписчика, не изменены за это время в БД диспетчера), новые данные просто передаются в БД диспетчера. Если конфликты обнаружены, противоречивые строки посылаются в отдельную фоновую таблицу для автоматического или ручного разрешения.
Конфликты обнаруживаются на уровне строки, однако фиксируются все строки, которые связаны с транзакцией, содержащей противоречивую строку. Другими словами, БД диспетчера отвергает всю транзакцию, пока конфликт не разрешен. По желанию можно предусмотреть прекращение процесса синхронизации, если транзакция отвергнута.
В SQLBase имеются средства, позволяющие администратору просмотреть зафиксированные противоречия и разрешить их по своему усмотрению. Можно использовать и автоматический способ разрешения конфликтов - с помощью назначения диспетчеру или подписчику приоритета. В этом случае предпочтение автоматически отдается приоритетному участнику репликации. Например, если приоритет имеет подписчик, строка подписчика в процессе синхронизации заменит ту же строку в таблице БД диспетчера. Если приоритет имеет диспетчер, его строка сохраняется, а подписчику посылается оповещение, что транзакция отвергнута. В этом случае конфликт подписчика с диспетчером придется разрешать вручную.
Таким образом, децентрализованная репликация данных в SQLBase позволяет по-новому решить многие проблемы обмена модифицированными данными между корпоративной БД и клиентскими приложениями. Особенности этого подхода:
- репликация в гетерогенной среде;
- вертикальная архитектура;
- эффективная поддержка доступа мобильных клиентов;
- удобные средства обслуживания репликаций на базе “классического” интерфейса Windows.
Статья подготовлена по материалам журнала Gupta World, №19/95.
Юрий Шафрин, Лев Бродский