Технологии реплицирования данных

Во многих случаях узким местом распределенных систем, построенных на основе технологий “Клиент-сервер” или объек­тного связывания данных, является недостаточно высокая про­изводи-тельность из-за необходимости передачи по сети боль­шого количества данных. Определенную альтернативу постро­ения быстродействующих распределенных систем предоставляют технологии реплицирования данных.

Репликой называют особую копию базы данных для разме­щения на другом компьютере сети с целью автономной рабо­ты пользователей с одинаковыми (согласованными) данными общего пользования.

Основная идея реплицирования заключается в том, что пользователи работают автономно с одинаковыми (общими) данными, растиражированными по локальным базам данных, обеспечивая с учетом отсутствия необходимости передачи и обмена данными по сети максимальную для своих вычисли­тельных установок производи-тельность.

Тиражирование (или репликация ) – создание дублирующих копий (репликатов) объектов данных на разных узлах с целью повышения доступности и/или сокращения времени доступа к критически важным данным.

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

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

1) обеспечение согласованного состояния во всех репли­ках количества и значений общих данных;

2) обеспечение согласованного состояния во всех репли­ках структуры данных.

Обеспечение согласованного состояния общих данных, в свою очередь, основывается на реализации одного из двух принципов:

принципа непрерывного размножения обновлений (любое обновление данных в любой реплике должно быть немедленно размножено);

принципа отложенных обновлений (обновления реплик могут быть отложены до специальной команды или ситуации).

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

Реализация принципа непрерывного размножения обнов­лений заключается в том, что любая транзакция считается ус­пешно завершенной, если она успешно завершена на всех реп­ликах системы. На практике реализация этого принципа встре­чает существенные затруднения, связанные с тупиками, как и в технологиях синхронизационных захватов систем “Клиент-сервер”. Предположим, что на одной вычислительной установке пользователь обновляет данные в своей реплике. На время осу­ществления транзакции (транзакций) соответствующие записи в базе данных этой реплики ядром локальной СУБД заблоки­рованы от изменения другими пользователями. Вместе с тем транзакция может быть зафиксирована и, следовательно, раз­блокированы соответствующие данные только тогда, когда дан­ная транзакция послана и также завершена на других репликах системы. Предположим также, что в другой реплике системы, находящейся на другом компьютере сети, в это же время дру­гой пользователь проводит свои обновления (транзакции) с теми же записями, которые, естественно, в этот момент также забло­кированы от изменений для других пользователей. Так образу­ется тупик. Одна транзакция не может быть зафиксирована в своей реплике, потому что заблокированы соответствующие записи в другой реплике. А разблокировка этих записей в дру­гой реплике также невозможна до тех пор, пока не разблокиру­ются соответствующие записи в первой реплике, т. е. когда за­вершится транзакция в первой реплике. Создается тупиковая ситуация.

Для обнаружения (распознавания) тупиков в реплициро­ванных системах применяются такие же алгоритмы, которые были разработаны в мониторах транзакций централизованных систем “Клиент-сервер”, – строится и поддерживается анало­гичный граф ожидания транзакций и применяются аналогич­ные алгоритмы распознавания и разрушения тупиков, основан­ные в основном на технике приоритетов.

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

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

Решение второй проблемы согласованности данных, а именно – согласованности структуры данных, осуществля­ется через частичное отступление, как и в системах “Клиент-сервер”, от принципа отсутствия центральной установки и основывается на технике главной реплики.

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

Процесс синхронизации реплик в современных СУБД включает обмен только теми данными, которые были измене­ны или добавлены в разных репликах. С этой целью в систем­ном каталоге базы данных создаются специальные таблицы те­кущих изменений и организуется система глобальной иденти­фикации (именования) всех объектов распределенной системы, включая раздельное поименование одинаковых объектов (вплоть до записей таблиц) в разных репликах (так называемая техника глобальных уникальных идентификаторов – GUID). Такой подход несколько увеличивает объем базы данных, но позволяет суще­ственно ограничить транспортные расходы на синхронизацию реплик.

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

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

На рис. 2.9 иллюстрируется подход к организации общей схемы распределенной информационной системы по делопро­изводству некоторой организационной структуры на основе технологий репликации данных.

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

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

Тем не менее развитие и все более широкое распростране­ние распределенных информационных систем, определяемое самой распределенной природой информационных потоков и технологий, является основной перспективой развития автома­тизированных информационных систем.