Технологии тиражирования данных

1. "Центр-филиалы", изменения в БД филиалов переносятся в центральную БД, и /или наоборот;
2. Равноправное, несколько БД разделяют общий набор изменяемых и тиражируемых данных;
3. Каскадное, изменения в одной БД переносятся в другую БД, откуда в свою очередь в третью БД и т. д., эта схема позволяет оптимизировать баланс загрузки серверов баз данных, расположенных на различных узлах;
4. Через шлюзы изменения в базе данных могут переносится в БД другой СУБД;
5. Различные комбинации всех перечисленных выше схем.

В основе описанных схем лежат следующие механизмы, регулирующие взаимоотношения между вовлеченными в сферу тиражирования узлами (с точки зрения принимающего узла):

1. "Равный-с-равным" (peer-to-peer или full peer): все изменения, произведенные с CDDS на первом узле, попадут на второй узел и наоборот, выполняется контроль возможных коллизий;
2. Доступ с обнаружением и разрешением конфликтов (protected read): изменения с первого узла попадают во второй, производится контроль возможных конфликтов (например, если источников несколько); изменения CDDS на втором узле незаконны, игнорируются и на первый узле не передаются;
3. Доступ по чтению без предотвращения конфликтов: то же, что и 2., но конфликты не обнаруживаются и не разрешаются;
4. Доступ через шлюз: то же, что и 3., но второй узел содержит данные, получаемые через шлюз к БД другой СУБД, при этом используется язык запросов OpenSQL.

Когда тиражировать?

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

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

Как разрешать  конфликты?

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

• разрешение конфликта в пользу более раннего или более позднего изменения;
• разрешение конфликта в пользу наивысшего приоритета тиражируемой записи.

Использование репликатора

ASK INGRES/Replicator комплектуется исчерпывающей системой оперативного управления, облегчающей организацию и мониторинг тиражирования.

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

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

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

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

При проработке вариантов  тиражируемой системы следует учесть:

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

Проиллюстрируем применение репликатора на примере решения  трех принципиально различных задач:

• организация доступа к распределенным данным;
• базы данных, нечувствительные к сбоям;
• распределение нагрузки в OLNTP-системах.

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

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

Третий пример использования  репликатора связан с распараллеливанием обработки в сильно загруженных  базах данных, ориентированных на оперативную обработку транзакций (On-Line Transaction Processing - OLTP). При возникновении проблем с возросшим временем реакции системы обычно рекомендуется произвести вертикальное масштабирование, т. е. увеличить вычислительную мощность компьютера - сервера базы данных. С экономической точки зрения обычно это не самое эффективное решение, особенно если рядом находятся свободные вычислительные мощности. С помощью разумно разработанной схемы тиражирования можно перенести часть решаемых задач с единственного компьютера еще на несколько других, уменьшив загрузку каждого узла за счет распределенной обработки данных. Особенно удобно разделить постоянно конфликтующие приложения OLTP (изменения или ввода данных) и приложения для принятия решений (decision support - анализ данных, подготовка отчетов). База данных для анализа могла бы обновляться репликатором периодически, соответствуя состоянию постоянно изменяемой оперативной базы данных на определенных час.

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

Заключение

В последнее время в  отечественной и зарубежной периодике  стали появляться первые статьи о  технологии тиражирования данных, в  которых перспективные средства тиражирования трактуются иногда как  очередное "новое увлечение производителей баз данных". Увы, поверхностный  анализ не позволил авторам подобных статей увидеть главного. Тиражирование  данных - это не очередной технологический  изыск и не прихоть разработчиков  баз данных, это технология востребована жизнью. Достаточно сказать, что продукт ASK Ingres/Replicator появился в результате исследования и разработок, выполненных по конкретным заказам, в частности, в сфере банковских систем.

Сегодня SK Ingres/Replicator уже доступен на ключевых платформах, таких как DEC, IBM, ICI, Sun и других. Несомненно, это сыграет особую роль в продвижении самых современных технологий распределенных вычислений на российский рынок. Новые идеи и подходы, реализованные в SK INGRES/Replicator, выходят за рамки конкретного продукта и обретают черты перспективной информационной технологии, и в этом качестве они, по нашему мнению, представляют для отечественных пользователей особый интерес.

Список  использованной литературы

1. Корнеев В.В. «Базы данных. Интеллектуальная обработка информации.» – М.: / Корнеев В.В., Гареев А.Ф., Васютин С.В. Нолидж, 2003.
2. Барон Г., Ладыженский Г. «Технология тиражирования данных в распределенных системах.» – Открытые системы, №02/1994.