Технологии реплицирования данных
Во многих случаях узким местом распределенных систем, построенных на основе технологий “Клиент-сервер” или объектного связывания данных, является недостаточно высокая производи-тельность из-за необходимости передачи по сети большого количества данных. Определенную альтернативу построения быстродействующих распределенных систем предоставляют технологии реплицирования данных.
Репликой называют особую копию базы данных для размещения на другом компьютере сети с целью автономной работы пользователей с одинаковыми (согласованными) данными общего пользования.
Основная идея реплицирования заключается в том, что пользователи работают автономно с одинаковыми (общими) данными, растиражированными по локальным базам данных, обеспечивая с учетом отсутствия необходимости передачи и обмена данными по сети максимальную для своих вычислительных установок производи-тельность.
Тиражирование (или репликация) – создание дублирующих копий (репликатов) объектов данных на разных узлах с целью повышения доступности и/или сокращения времени доступа к критически важным данным.
Программное обеспечение СУБД для реализации такого подхода соответственно дополняется функциями тиражирования (реплицирования) баз данных, включая тиражирование как самих данных и их структуры, так и системного каталога с информацией о размещении реплик, иначе говоря, с информацией о конфигурировании построенной таким образом распределенной системы.
При этом, однако, возникают две проблемы обеспечения одного из основополагающих принципов построения и функционирования распределенных систем, а именно – непрерывности согласованного состояния данных:
1) обеспечение согласованного состояния во всех репликах количества и значений общих данных;
2) обеспечение согласованного состояния во всех репликах структуры данных.
Обеспечение согласованного состояния общих данных, в свою очередь, основывается на реализации одного из двух принципов:
принципа непрерывного размножения обновлений (любое обновление данных в любой реплике должно быть немедленно размножено);
принципа отложенных обновлений (обновления реплик могут быть отложены до специальной команды или ситуации).
Принцип непрерывного размножения обновлений является основополагающим при построении так называемых систем реального времени, таких, например, как системы управления воздушным движением, системы бронирования билетов пассажирского транспорта и т.п., где требуется непрерывное и точное соответствие реплик или других растиражированных данных во всех узлах и компонентах подобных распределенных систем.
Реализация принципа непрерывного размножения обновлений заключается в том, что любая транзакция считается успешно завершенной, если она успешно завершена на всех репликах системы. На практике реализация этого принципа встречает существенные затруднения, связанные с тупиками, как и в технологиях синхронизационных захватов систем “Клиент-сервер”. Предположим, что на одной вычислительной установке пользователь обновляет данные в своей реплике. На время осуществления транзакции (транзакций) соответствующие записи в базе данных этой реплики ядром локальной СУБД заблокированы от изменения другими пользователями. Вместе с тем транзакция может быть зафиксирована и, следовательно, разблокированы соответствующие данные только тогда, когда данная транзакция послана и также завершена на других репликах системы. Предположим также, что в другой реплике системы, находящейся на другом компьютере сети, в это же время другой пользователь проводит свои обновления (транзакции) с теми же записями, которые, естественно, в этот момент также заблокированы от изменений для других пользователей. Так образуется тупик. Одна транзакция не может быть зафиксирована в своей реплике, потому что заблокированы соответствующие записи в другой реплике. А разблокировка этих записей в другой реплике также невозможна до тех пор, пока не разблокируются соответствующие записи в первой реплике, т. е. когда завершится транзакция в первой реплике. Создается тупиковая ситуация.
Для обнаружения (распознавания) тупиков в реплицированных системах применяются такие же алгоритмы, которые были разработаны в мониторах транзакций централизованных систем “Клиент-сервер”, – строится и поддерживается аналогичный граф ожидания транзакций и применяются аналогичные алгоритмы распознавания и разрушения тупиков, основанные в основном на технике приоритетов.
В целом ряде предметных областей распределенных информационных систем режим реального времени с точки зрения непрерывности согласования данных не требуется. Такие системы автоматизируют те организационно-технологические структуры, в которых информационные процессы не столь динамичны. Если взять, к примеру, автоматизированную информационную систему документооборота, то традиционная “скорость” перемещения и движения служебных документов соответствует рабочему дню или в лучшем случае рабочим часам. В этом случае обновление реплик распределенной информационной системы, если она будет построена на технологии реплицирования, требуется, скажем, только лишь один раз за каждый рабочий час, или за каждый рабочий день.
Такого рода информационные системы можно строить на основе принципа отложенных обновлений. Накопленные в какой-либо реплике изменения данных специальной командой пользователя направляются для обновления всех остальных реплик систем. Такая операция называется синхронизацией реплик. Возможность конфликтов и тупиков в этом случае при синхронизации реплик существенно снижается, а немногочисленные подобные конфликтные ситуации легко разрешить организационными мерами.
Решение второй проблемы согласованности данных, а именно – согласованности структуры данных, осуществляется через частичное отступление, как и в системах “Клиент-сервер”, от принципа отсутствия центральной установки и основывается на технике главной реплики.
Суть этой техники заключается в том, что одна из реплик базы данных системы объявляется главной. При этом изменять структуру базы данных можно только в главной реплике. Эти изменения структуры данных тиражируются на основе принципа отложенных обновлений, т.е. через специальную синхронизацию реплик. Частичность отступления от принципа отсутствия центральной установки заключается в том, что в отличие от чисто централизованных систем, выход из строя главной реплики не влечет сразу гибель всей распределенной системы, так как остальные реплики продолжают функционировать автономно. Более того, на практике СУБД, поддерживающие технологию реплицирования, позволяют пользователю с определенными полномочиями (администратору системы) преобразовать любую реплику в главную и тем самым полностью восстановить работоспособность всей системы.
Процесс синхронизации реплик в современных СУБД включает обмен только теми данными, которые были изменены или добавлены в разных репликах. С этой целью в системном каталоге базы данных создаются специальные таблицы текущих изменений и организуется система глобальной идентификации (именования) всех объектов распределенной системы, включая раздельное поименование одинаковых объектов (вплоть до записей таблиц) в разных репликах (так называемая техника глобальных уникальных идентификаторов – GUID). Такой подход несколько увеличивает объем базы данных, но позволяет существенно ограничить транспортные расходы на синхронизацию реплик.
Важным с точки зрения гибкости и эффективности функционирования распределенных информационных систем, построенных на технологиях реплицирования, является возможность создания так называемых частичных реплик и включения в реплики как реплицируемых, так и нереплицируемых объектов. Частичной репликой называется база данных, содержащая ограниченное подмножество записей полной реплики. Распространенным способом создания частичных реплик является использование фильтров, устанавливаемых для конкретных таблиц полной (главной) реплики. Частичные реплики позволяют решить некоторые проблемы, связанные с разграничением доступа к данным и повышают производительность обработки данных. Так, к примеру, в реплику базы данных для определенного подразделения целесообразно реплицировать только те записи таблицы “Сотрудники”, которые относятся к данному подразделению, исключив тем самым доступ к другим записям. Техника частичных реплик также снижает затраты на синхронизацию реплик, так как ограничивает количество передаваемых по сети изменений данных.
Возможность включения в реплики объектов базы данных, которые не подлежат репликации, позволяет более гибко и адекватно настроить схему и прочие объекты БД (запросы, формы и отчеты) на специфику предметной области, особенности ввода данных и решаемые информационные задачи по конкретному элементу распределенной системы.
На рис. 2.9 иллюстрируется подход к организации общей схемы распределенной информационной системы по делопроизводству некоторой организационной структуры на основе технологий репликации данных.
Технологии репликации данных в тех случаях, когда не требуется обеспечивать большие потоки и интенсивность обновляемых в информационной сети данных, являются экономичным решением проблемы создания распределенных информационных систем с элементами централизации по сравнению с использованием дорогостоящих “тяжелых” клиент-серверных систем.
На практике для совместной коллективной обработки данных применяются смешанные технологии, включающие элементы объектного связывания данных, репликаций и клиент-серверных решений. При этом дополнительно к проблеме логического проектирования, т. е. проектирования логической схемы организации данных (таблицы, поля, ключи, связи, ограничения целостности), добавляется не менее сложная проблема транспортно-технологического проектирования информационных потоков, разграничения доступа и т. д. К сожалению, пока не проработаны теоретико-методологические и инструментальные подходы для автоматизации проектирования распределенных информационных систем с учетом факторов как логики, так и информационно-технологической инфраструктуры предметной области.
Тем не менее развитие и все более широкое распространение распределенных информационных систем, определяемое самой распределенной природой информационных потоков и технологий, является основной перспективой развития автоматизированных информационных систем.