Сегодня в распределенных вычислениях актуальной становится технология тиражирования данных, выступающая как альтернатива технологии распределенных баз данных. Какие идеи положены в ее основу? В чем ее преимущества? В этой статье мы попытались дать ответ на эти и другие вопросы.
Введение
Идея организации единой информационной Среды крупного современного предприятия на принципах распределенной обработки данных становится все более популярной. Переход к реализации таких принципов от дорогостоящих и недостаточно гибких централизованных много пользовательских mainframe-систем, либо от мало мощных и слабо интегрированных систем на базе персональных компьютеров (что характерно для стран Восточной Европы и России в частности), происходит сейчас во всем компьютерном мире и встречается со сходными концептуальными трудностями.
Их преодолению в значительной степени могла бы помочь новая технология обработки данных, опирающаяся на принципы тиражирования данных. Она нашла свое воплощение в последней версии ASK INGRES/Replicator - одного из ключевых компонентов реляционной СУБД INGRES. Удачную реализацию в этом продукте в общем-то несложного принципа тиражирования или дублирования всех изменений в нескольких БД в силу ее универсальности и мощности без преувеличения можно рассматривать как технологический прорыв в области распределенных вычислений.
Другие ведущие разработчики СУБД (Sybase, Informix, Oracle) также не обошли своим вниманием технологию тиражирования. Sybase имеет готовый продукт, а Informix планирует выпустить свою версию в середине 1994 года. В состав СУБД Oracle 7.0 входят отдельные процедуры, позволяющие запрограммировать копирование данных; в то же время дата выпуска отдельного продукта в составе Oracle, по нашим сведениям, пока не определена.
Принцип тиражирования - сопоставление с физическим распределением данных
Использование современными организациями технологии "клиент-сервер" делает актуальной проблему доступа к удаленным базам данных и комбинирование информации из двух или более физически разделенных узлов информационной системы. Ответом на требования реальной жизни стали такие возможности обработки распределенных данных, как двухфазовая фиксация транзакций.
Напомним, что под распределенной поднимают базу данных, включающую в себя фрагменты локальных БД, расположенных, возможно, на различных узлах распределенной системы. Так называемая топология (и технология) STAR подразумевает физическое распределение данных с целью размещения каждого фрагмента распределенной БД там, где он преимущественно будет обрабатываться и, следовательно, уменьшения времени доступа к данным для локальных пользователей. При этом вся работа с распределенной БД происходит так, как будто это - просто локальная база данных ("распределенность базы данных не видна извне). Распределенная БД обслуживается в большинстве многопользовательских СУБД одноименным компонентом STAR - сервером распределенных баз данных.
Распределенная транзакция (транзакция распределенной БД) включает в себя несколько локальных транзакций, каждая из которых либо фиксируется, либо прерывается. Распределенная транзакция фиксируется только в том случае, когда зафиксированы все локальные транзакции, ее составляющие, Если хотя одна из них была прервана, то должна быть прервана и распределенная транзакция. Как на практике учесть это требование?
Для этого в современных СУБД предусмотрен так называемый протокол двухфазовой фиксации транзакций (two-phase commit protocol - 2PC). Название отражает то, что фиксация распределенной транзакции выполняется в две фазы.
Первая фаза начинается, когда клиент выполняет оператор COMMIT. Сервер распределенной БД направляет уведомление PREPARE TO COMMIT - "подготовиться к фиксации" всем серверам локальных БД, выполняющим транзакцию. Последние после подготовки к фиксации остаются в состоянии готовности и ожидают от сервера распределенной БД команды фиксации. Если хотя бы одни из серверов не откликнулся на уведомление в силу каких-либо причин, будь то аппаратная или программная ошибка, то сервер распределенной БД открывает локальные транзакции на всех узлах, включая даже те, на которых серверы подготовились к фиксации и оповестили его об этом.
Выполнение второй фазы заключается в том, что сервер распределенной БД направляет команду COMMIT серверам на всех узлах, затронутых транзакцией. Выполняя команду, последние фиксируют изменения, достигнутые в процессе выполнения распределенной транзакции. В результате гарантируется одновременное синхронное завершение (удачное или неудачное) распределенной транзакции на всех участвующих в ней узлах.
Основной недостаток технологии физического распределения данных - жесткие требования к скорости и надежности каналов связи. Действительно, когда узлы с локальными БД соединены локальной вычислительной сетью, а распределенная транзакция затрагивает два-три узла сети, то, как правило, серьезных проблем с фиксацией распределенных транзакций не возникает.
Совершенно иная ситуация складывается в том случае, когда база данных распределена по нескольким территориально удаленным узлам, объединенными медлительными и ненадежными каналами связи, а число одновременно работающих в распределенной среде пользователей составляет десятки. В этом случае вероятность того, что распределенная транзакция будет зафиксирована в обозримом временном интервале, становится чрезвычайно малой. Время реакции системы может оказаться неприемлемо большим даже в случае простого чтения данных. В таких условиях обработка распределенных данных практически невозможна.
Ни для кого не секрет, что именно с такой ситуацией сталкивается большинство отечественных организаций. Несмотря на то, что несколько последних лет положение с каналами оперативной связи несколько улучшилось, изменения происходят отнюдь не так быстро, как этого бы хотелось. Указанные ограничения топологии STAR заставляют уже сегодня подумать о реальной альтернативе технологии распределенных баз данных.
На наш взгляд, в этом качестве можно рассматривать технологию тиражирования (replication) данных. Ее принципиальное отличие от технологии STAR заключается в отказе от ведения распределенных БД в общепринятом смысле. Идея состоит в том, что каждая база данных (как для СУБД, так и для множества работающих с ней пользователей) всегда является локальной: локально размещаются данные, необходимые в данном узле распределенной системы, локально завершаются все транзакции, не требуя сложных механизмов и проверок 2PC.
Тиражирование данных - это асинхронный перенос изменений объектов исходной базы данных (source database) в базы данных, принадлежащие к различным узлам распределенной системы. Функции тиражирования данных возложены на специальный компонент СУБД - сервер тиражирования данных, называемый репликатором (replicator), задача которого состоит в обеспечении идентичности данных в принимающих базах данных (target database) данным в исходной БД.
Сигналом для запуска репликатора служит срабатывание правила (rule), перехватывающего любые изменения тиражируемого объекта БД, а для обеспечения надежности передачи репликатор использует протокол двухфазовой фиксации транзакции.
передача только операций, изменяющих данные, а не всех операций доступа к удаленным данным (как в технологии STAR), и к тому же в асинхронном режиме позволяет значительно уменьшить сетевой трафик, что особенно важно при низком быстродействии каналов связи. Не менее важно то, что со стороны исходной базы данных репликатор выступает как процесс, инициированный одним пользователем, в то время как в физически распределенной среде с каждым локальным сервером баз данных работают все пользователи распределенной системы, конкурирующие за ресурсы друг с другом, что отнюдь не уменьшает времени реакции системы.
Тиражирование данных полностью прозрачно для прикладной программы. Точно так же, как и в технологии STAR, она ничего не знает и репликаторе, который находится целиком в ведении администратора БД. Для переноса программы в распределенную системы с тиражируемыми данными не требуется ее модификации. Отметим, что возможно и программное управление репликатором через механизм сигнализаторов о событиях в базе данных.
Как определить элементарное изменение - базис для тиражирования? Очевидно, что им не может быть элементарная операция с базой данных, поскольку прерывание тиражирования в середине транзакции (например, в результате сбоя в канале связи) нарушит целостность транзакции и вызовет несогласованность в принимающей базе данных. Следовательно, изменение в исходной БД может быть тиражировано только после фиксации транзакции. В то же время возможен перенос изменений группами транзакций, периодически или в некоторый момент времени, что дает возможность наблюдать и исследовать состояние принимающей БД на определенный час.
Нарушит ли передачу изменений продолжительный сбой связи? Нет, не нарушит. В силу того, что тиражирование является асинхронным процессом, предусмотрена буферизация потока изменений (транзакций) и, после восстановления связи, возобновление передачи с той транзакции, на которой тиражирование было прервано.
Как быть, если вследствие все той же асинхронности два пользователя на разных узлах исправят одну и ту же запись в том момент, пока данные из первой БД еще не успели реплицироваться во вторую? Увы, за все преимущества тиражирования необходимо платить и только применение протокола двухфазовой фиксации каждым клиентом гарантирует одновременное завершение транзакции на всех узлах. В данной ситуации репликатор обязательно обнаружит противоречие - конфликт между двумя версиями одной и той же записи. Предварительно он должен быть запрограммирован на какой-либо вариант ее разрешения, но, безусловно, непредвиденных конфликтов следует избегать, причем делать это можно различными способами.
Один из них состоит в том, что для каждого узла (базы данных) должны быть определены некие уникальные функции, исключающие коллизии. Другой предполагает правильный реляционный дизайн, в частности, отказ от тиражирования вычисляемых данных в пользу первичных. Например, в банковских приложениях верным решением была бы репликация проводок, а не остатков на счетах. Можно попытаться перенести центр тяжести с операций обновления данных (update) на операции удаления (delete) или вставки (insert) записей в тиражируемом наборе. Интересны также сочетания репликатора и прямого применения двухфазовой фиксации распределенных транзакций в топологии STAR, реализующие необходимые блокировки.
Так или иначе, жизненность концепции тиражирования подтверждена практикой ее использования в области, характеризуемой максимальной ответственностью - в банковской сфере. Отметим, что именно в расчете на распределенные банковские приложения, обеспечивающие повышенную надежность и быстродействие систем, и была разработана технология тиражирования данных.
Инструментарий тиражирования
На практике установка тиражируемой системы сводится к чисто административным действиям, для выполнения которых необходимо получить ответы на четыре вопроса: Что тиражировать? Где тиражировать? Когда тиражировать? Как разрешать предполагаемые конфликты? Напомним, прикладной программе не обязательно знать детали организации данных в системе - ведь они со временем могут измениться! Рассмотрим ответы, которые дает репликатор на эти вопросы.
Что тиражировать?
Как и любая другая методология, тиражирование имеет собственную терминологию. Краеугольным камнем тиражирования является понятие согласованного распределенного набора данных (consistent distributed data set - CDDS). Фактически, это тот самый набор данных в базе (или база данных целиком), идентичность которого на всех узлах, вовлеченных в процесс тиражирования, и поддерживает репликатор. Здесь и далее мы будем говорить об узлах распределенной системы, хотя участвовать в тиражировании могут и базы данных, расположенные на одном узле.
CDDS может быть представлен следующими конфигурациями данных:
- Вся база данных:
- Избранные объекты базы данных: таблицы или представления;
- Вертикальные проекции объектов БД: избранные столбцы таблиц и/или представлений;
- Горизонтальные подмножества объектов: избранные записи из таблиц и/или представлений;
- Сочетание наборов 2-4.
Строгое определение CDDS заключается в выполнении следующих условий:
- Набор данных, претендующий на определение в качестве CDDS, должен располагаться в нескольких базах данных в идентичных копиях;
- Данные из различных CDDS должны быть взаимно ортогональны, т. е. одни и те же данные не могут входить в различные CDDS;
- CDDS должен обладать свойством полноты, т. е. включать все идентичные копии данных, существующие в распределенной системе.
Идентичность здесь понимается как одинаковость определения и состава данных. При установке тиражируемой системы идентичность состава данных может обеспечиваться средствами репликатора.
В результате, согласованность CDDS автоматически поддерживается репликатором и проявляется в том, что:
- Любое изменение любой копии CDDS автоматически распространяется на все остальные копии;
- Внутри CDDS ни одна копия данных не имеет преимущества перед другой копией - они абсолютно равноправны;
- Все объекты, составляющие каждую копию CDDS, имеют одинаковые имена.
Принципиально то, что ни один узел - хранитель своей части CDDS - ничем не отличается от других, если не оговорено обратное. Все узлы равноправны и могут быть источниками и приемниками изменений, хотя при необходимости внутри CDDS определяется приоритет данных каждого узла, используемый при автоматическом разрешении конфликтов в тиражируемых данных.
Где тиражировать?
Следующий основополагающий элемент схемы тиражирования - это путь переноса изменений (data propagation path - DPP) из каждой тиражируемой базы данных в другие БД. Гибкость тиражирования в значительной степени обеспечивается богатством выбора способа передачи данных между узлами распределенной системы.
Практика эксплуатации распределенных систем подсказала следующие схемы тиражирования данных, реализуемые репликатором:
- "Центр-филиалы", изменения в БД филиалов переносятся в центральную БД, и /или наоборот;
- Равноправное, несколько БД разделяют общий набор изменяемых и тиражируемых данных;
- Каскадное, изменения в одной БД переносятся в другую БД, откуда в свою очередь в третью БД и т. д., эта схема позволяет оптимизировать баланс загрузки серверов баз данных, расположенных на различных узлах;
- Через шлюзы изменения в базе данных могут переносится в БД другой СУБД;
- Различные комбинации всех перечисленных выше схем.
В основе описанных схем лежат следующие механизмы, регулирующие взаимоотношения между вовлеченными в сферу тиражирования узлами (с точки зрения принимающего узла):
- "Равный-с-равным" (peer-to-peer или full peer): все изменения, произведенные с CDDS на первом узле, попадут на второй узел и наоборот, выполняется контроль возможных коллизий;
- Доступ с обнаружением и разрешением конфликтов (protected read): изменения с первого узла попадают во второй, производится контроль возможных конфликтов (например, если источников несколько); изменения CDDS на втором узле незаконны, игнорируются и на первый узле не передаются;
- Доступ по чтению без предотвращения конфликтов: то же, что и 2., но конфликты не обнаруживаются и не разрешаются;
- Доступ через шлюз: то же, что и 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, выходят за рамки конкретного продукта и обретают черты перспективной информационной технологии, и в этом качестве они, по нашему мнению, представляют для отечественных пользователей особый интерес.
