Обмен информацией

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

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

Многие компании для решения задачи обмена информацией приобретают специальные программные пакеты разных фирм для поддержки этих функций. В этом случае им приходится приобретать сервер репликации, пакет для работы с очередями сообщений, средства загрузки данных в хранилища и витрины данных, ПО для нотификации (извещения о событиях) и управления событиями и т д. Иногда достаточно приобрести только часть этих средств. Не будем говорить о стоимости этого дополнительного программного обеспечения и недостатках многих из этих пакетов. Главная проблема здесь – интеграция. Сложность интеграции этих разнородных систем с различной архитектурой, языками, средствами доступа и т д настолько велика, что большинство интеграционных проектов оканчивается неудачей.

Пользователям СУБД Oracle несколько проще, поскольку средства для репликации, обмена сообщениями, организации резервной БД, захвата изменений и загрузки хранилищ и витрин данных входят в состав сервера Oracle 9i без дополнительной платы (см. табл. 1). Однако и у такого подхода есть много недостатков.

Таблица 1. Типичные решения для обмена информацией

Купить у разных фирм	Oracle
Replication Tools	Advanced Replication
Messaging Software	Advanced Queueing
Warehouse Loaders	CMC + Loader + WB
HA, Performance SW	Standby
Middleware	Integration in iAS
Event Management apps	----
Notification apps	----

Если у нас есть совокупность приложений, включающая хранилища и витрины данных, оперативные системы, резервные узлы, приложения, использующие обмен сообщениями (как с приложениями Oracle, так и с другими пакетами, например с MQ Series) и т д и между ними надо организовать обмен информацией, то картинка будет выглядеть как на рисунке 1. Т. е. придется поддерживать огромное количество связей, передавать огромное количество информации.

Рис 1. Традиционная интеграция данных

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

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

Oracle Streams состоит из трех основных элементов:

захват изменений (Capture)
складирование, хранение и распространение изменений (Staging)
применение изменений (Consumption или Apply)

Теперь в исходной системе вся необходимая для различных механизмов обмена информация автоматически захватывается, упорядочивается, преобразуется в универсальный формат и помещается в область хранения. Далее она автоматически перемещается между областями хранения и в тех целевых узлах, где она нужна, эта информация используется Apply процессами, которые выполняют репликацию или загружают хранилище данных или обновляют резервную БД и т д. Приложениям – потребителям достаточно просто подписаться на необходимую им информацию и они будут ее автоматически получать, а Apply процессы будут ее автоматически применять. Мы видим, что теперь картинка с рисунка 1 значительно упростилась (см рис. 2). Количество связей уменьшилось, механизм упростился. Заказчик теперь должен покупать, изучать, конфигурировать и поддерживать только один продукт, добавление новых публикаторов (добавляющих информацию об изменениях в поток) и новых подписчиков (потребляющих информацию из потока) осуществляется легко, замена одного механизма обмена информацией на другой выполняется просто. И главное, падает нагрузка на сеть и эксплуатационную систему. Oracle Streams захватывает информацию об изменениях из журнальных файлов, не нагружая эксплуатационную систему, причем он захватывает и передает ее только один раз, не дублируя информацию. Кстати Oracle Streams входит в состав сервера Oracle без дополнительной платы.

Рис. 2. Интеграция данных в Oracle Streams

Содержание раздела