(Продолжение. Начало в №7-9, 11, 12, 13, 14, 15, 16, 17, 18, 19, 20, 22, 24)

Сегодня мы расскажем о примененной в LeoBase системе тиражирования баз данных.

Понятно, что пополнение динамично изменяющейся базы данных будет идти быстрее, если над ней будет работать не один, а сразу несколько человек. В связи с этим встает важный вопрос обеспечения необходимого взаимодействия и согласования результатов их работы. Как известно, популярные СУБД, за малым исключением, не включают комплекса мероприятий для совместного ведения одной БД. В LeoBase такая система существует и называется она системой тиражирования. В данной процедуре есть нечто общее с родственной ей процедурой обновления, однако здесь все устроено несколько сложнее, ввиду того, что информация о коррекции данных БД поступает сразу из нескольких источников. Необходимый компонент этого - сервер репликаций, специальная программа, которая по окончании автономной работы клиентов совмещает результаты их работы для всего комплекса БД.

• Полный процесс тиражирования показан на схеме, где "ноль" - первоначальное состояние БД, "А","Б","В" - имена клиентов, а "1","2" и "3" - изменения, проведенные каждым клиентом.

Процесс происходит следующим образом:

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

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

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

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

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

Диаграмма действий клиентов в случае с откатом выглядит так:

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

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

1. Принятие времени работы отдельных групп за точку отсчета;
2. Работа каждой группы по известной схеме, пока не настанет время объединения результатов;
3. Изготовление файлов тиражирования сервера каждой группы;
4. Получение общего файла тиражирования на общем сервере репликаций;
5. Откат действий клиентов каждой группы до точки отсчета;
6. Запуск общего файла тиражирования на компьютере каждого клиента;
7. Переход к шагу №1.

В LeoBase существуют два метода тиражирования БД: метод блокировок и метод конкуренции. Первый метод используется в том случае, когда заранее известно, какие записи и поля каких баз собираются изменять или удалять. Такие элементы БД блокируются на сервере теми клиентами, которые будут с ними работать. Эти действия осуществляются специальными функциями блокировки для тиражирования, при этом с незаблокированными элементами БД никакой работы вестись не может. При использовании этого метода конфликтов между действиями отдельных клиентов, по понятным причинам, быть не может.

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

• по модификации одних и тех же полей;
• по удалению записей. Например, один клиент удалил запись, а второй поставил на нее ссылку из другой БД или изменил в ней поле;
• по пользовательским данным. Здесь возможны самые различные ситуации, зависящие от наполнения БД. Например, какое-либо поле записи должно быть уникальным в общей базе, а не только в каталогах клиентов. Сервер репликации не в состоянии отследить требования конкретных задач, поэтому в таких ситуациях идеологию работы с данными пользователя необходимо менять.

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

В следующей статье мы расскажем о работе LeoBase в сети.

(Продолжение следует)

Владимир КОТЛЯРОВ,
"СофтИнформ", тел. 213-28-13,
e-mail: ui@activ.minsk.by