Описание проекта
Для хранения данных приложений в большинстве случаев используются реляционные системы управления базами данных. С их помощью легко составлять различные отчеты, в том числе достаточно сложные (OLAP, data mining) и решать прочие прикладные задачи. Проблемы возникают при работе с распределенными данными, когда объединенным в сеть узлам с обособленными хранилищами необходимо синхронизировать содержимое своих БД. С точки зрения каждого узла такой сети, его хранилище является локальной репликой, хранилища же других узлов – удаленными репликами. Реплицируя лишь строки таблиц, невозможно обеспечить целостность отношений между таблицами. Существует ряд решений для репликации реляционных СУБД, но большинство из них специфичны для конкретной СУБД и несовместимы между собой. В общем случае возможно несколько способов синхронизации данных: при обращении к СУБД на запись соответствующая транзакция проводится на всех синхронизируемых узлах одновременно; создается дамп всей БД одного узла и имортируется в БД другого; используются специфичные для конкретной СУБД средства. Большинство из этих решений неприменимы в сети с низкой отказоустойчивостью и низкой скоростью передачи данных, в особенности первый способ, где отключение узла от сети приводит к необходимости использования других средств для синхронизации с другими узлами кластера. Передача дампа БД по сети с пропускной способностью в несколько десятков КБ/сек может занять очень длительное время, за которое данные на узлах изменятся так, что необходимо будет повторить процесс заново. Таким образом, механизм репликации для таких сетей должен обладать рядом свойств:
Отсюда видно, что приложение никак не связано с системой репликации. А система репликации связана с СУБД посредством библиотеки Layer, что позволяет заменить лишь её при использовании другой библиотеки ORM, нежели Hibernate. Replication Service представляет собой сервер репликатора (набор Java-сервлетов, обрабатывающих HTTP-запросы) и сервис, исполняющий активную роль (клиент, который инициирует соединение с сервером на другом узле).
Возвращаясь к описанным выше требованиям к механизму offline-репликации, следует отметить, что RBDR удовлетворяет всем трем пунктам. После обрыва репликации (например, повреждение сетевого кабеля) она будет продолжена во время следующего сеанса. Это обеспечено за счет того, что под транзакцией в данном случае понимается передача каждого отдельного объекта. Передаваемые данные содержат в себе информацию только о тех изменениях, которые произошли после последнего удачного сеанса репликации, что резко снижает количество передаваемых данных. Использование XML для представления метаинформации и состояния объектов, а также разделение на Replication Service и Layer позволяет использовать не только технологии Java, но и любые другие, поддерживающие ORM, а выделение серверной компоненты предоставляет возможность написания отдельных приложений-клиентов, реализованных любым возможным способом.
Однако, эти отличительные черты RDBR накладывают ряд ограничений и требований к бизнес-приложению как в отношении модели БД, так и в отношении обработки исключительных случаев, когда приложению будет доступно частично отреплицированное множество объектов. К тому же, должен существовать алгоритм составления уникальных идентификаторов объекта. Также должен существовать метод разрешения конфликтов несогласованной модификации. На текущий момент составляются требования к организации БД и производятся соответствующие исправления в выбранном для тестирования приложении — Xwiki.
В данном решении узлы репликационной сети обмениваются информацией в режиме «один к одному», еще не поддерживается частичная репликация. Следующий прототип будет обеспечивать одновременную репликацию с несколькими узлами, полную автоматизацию управления репликацией, представленную выделенным узлом-менеджером и соответствующим протоколом обмена данными между менеджером и остальными узлами. Возможным будет как ручное редактирование топологии репликационной сети, так и автоматическое, основанное на статистике частоты изменений на узле, скорости обмена данными с узлом и средней нагрузки. В дальнейшем планируется реализация частичной репликации.