Технология тиражирования данных
Принципиальная характеристика тиражирования данных (Data Replication - DR) заключается в
отказе от физического распределения данных. Суть DR состоит в том, что любая база данных (как
для СУБД, так и для работающих с ней пользователей) всегда является локальной; данные
размещаются локально на том узле сети, где они обрабатываются; все транзакции в системе
завершаются локально.
Тиражирование данных - это асинхронный перенос изменений объектов исходной базы данных в
базы, принадлежащим различным узлам распределенной системы. Функции DR выполняет, как
правило, специальный модуль СУБД - сервер тиражирования данных, называемый репликатором
(так устроены СУБД CA-OpenIngres и Sybase). В Informix-OnLine Dynamic Server репликатор
встроен в сервер, в Oracle 7 для использования DR необходимо приобрести дополнительно к
Oracle7 DBMS опцию Replication Option.
Специфика механизмов DR зависит от используемой СУБД. Простейший вариант DR -
использование "моментальных снимков" (snapshot). Рассмотрим пример из Oracle:
CREATE SNAPSHOT unfilled_orders
REFRASH COMPLETE
START WITH TO_DATE ('DD-MON-YY HH23:MI:55')
NEXT SYSDATE + 7
AS SELECT customer_name, customer_address, order_date
FROM customer@paris, order@london
WHERE customer.cust_name = order.customer_number AND
order_complete_flag = "N";
"Моментальный снимок" в виде горизонтальной проекции объединения таблиц customer и
order будет выполнен в 23:55 и будет повторятся каждые 7 дней. Каждый раз будут выбираться
только завершенные заказы.
Реальные схемы тиражирования, разумеется, устроены более сложно. В качестве базиса для
тиражирования выступает транзакция к базе данных. В то же время возможен перенос изменений
группами транзакций, периодически или в некоторый момент времени, что дает возможность
исследовать состояние принимающей базы на определенный момент времени.
Детали тиражирования данных полностью скрыты от прикладной программы; ее
функционирование никак не зависят от работы репликатора, который целиком находится в
ведении администратора базы данных. Следовательно, для переноса программы в распределенную
среду с тиражируемыми данными не требуется ее модификации. В этом, собственно, состоит
качество 6 в определении Дэйта.
Синхронное обновление DDB и DR-технология - в определенном смысле антиподы. Краеугольный
камень первой - синхронное завершение транзакций одновременно на нескольких узлах
распределенной системы, то есть синхронная фиксация изменений в DDB. Ee "Ахиллесова пята" -
жесткие требования к производительности и надежности каналов связи. Если база данных
распределена по нескольким территориально удаленным узлам, объединенным медленными и
ненадежными каналами связи, а число одновременно работающих пользователей составляет сотни
и выше, то вероятность того, что распределенная транзакция будет зафиксирована в обозримом
временном интервале, становится чрезвычайно малой. В таких условиях (характерных, кстати, для
большинства отечественных организаций) обработка распределенных данных практически
невозможна.
DR-технология не требует синхронной фиксации изменений, и в этом ее сильная сторона. В
действительности далеко не во всех задачах требуется обеспечение идентичности БД на различных
узлах в любое время. Достаточно поддерживать тождественность данных лишь в определенные
критичные моменты времени. Можно накапливать изменения в данных в виде транзакций в одном
узле и периодически копировать эти изменения на другие узлы.
Налицо преимущества DR-технологии. Во-первых, данные всегда расположены там, где они
обрабатываются - следовательно, скорость доступа к ним существенно увеличивается. Во-вторых,
передача только операций, изменяющих данные (а не всех операций доступа к удаленным данным),
и к тому же в асинхронном режиме позволяет значительно уменьшить трафик. В-третьих, со
стороны исходной базы для принимающих баз репликатор выступает как процесс,
инициированный одним пользователем, в то время как в физически распределенной среде с
каждым локальным сервером работают все пользователи распределенной системы,
конкурирующие за ресурсы друг с другом. Наконец, в-четвертых, никакой продолжительный сбой
связи не в состоянии нарушить передачу изменений. Дело в том, что тиражирование предполагает
буферизацию потока изменений (транзакций); после восстановления связи передача
возобновляется с той транзакции, на которой тиражирование было прервано.
DR-технология данных не лишена недостатков. Например, невозможно полностью исключить
конфликты между двумя версиями одной и той же записи. Он может возникнуть, когда вследствие
все той же асинхронности два пользователя на разных узлах исправят одну и ту же запись в тот
момент, пока изменения в данных из первой базы данных еще не были перенесены во вторую. При
проектировании распределенной среды с использованием DR-технологии необходимо
предусмотреть конфликтные ситуации и запрограммировать репликатор на какой-либо вариант их
разрешения. В этом смысле применение DR-технологии - наиболее сильная угроза целостности
DDB. На мой взгляд, DR-технологию нужно применять крайне осторожно, только для решения
задач с жестко ограниченными условиями и по тщательно продуманной схеме, включающей
осмысленный алгоритм разрешения конфликтов.
