- •Распределенные информационные системы
- •Тема 1. Введение в распределенные системы (3 ч)
- •3. Концепции аппаратных решений
- •1. Что такое распределенная система?
- •2. Основные задачи распределенной обработки
- •2.1. Прозрачность
- •2.2. Открытость
- •2.3. Масштабируемость (возможность расширения)
- •4. Концепции программных решений
- •3. Концепции аппаратных решений
- •5. Модель Клиент-сервер
- •6. Итоги
- •Тема 2. Модели взаимодействия компонентов рс (2 часа)
- •2.1 Понятие промежуточной среды
- •2.2 Модели взаимодействия компонентов рс
- •2.2.1 Обмен сообщениями
- •2.2.2 Удаленный вызов процедур
- •2.2.3 Обращение к удаленным объектам (rmi)
- •2.2.4 Связь на основе потоков данных
- •Тема 3. Распределенные системы объектов (4 часа)
- •Задачи построения рис
- •Преимущества использования
- •Повторное использование кода
- •Изолированная разработка
- •Сопровождение приложений
- •Тонкие клиенты
- •3.2 Объектная модель corba
- •Объектная модель corba
- •Базовый объектный адаптер boa
- •Динамический интерфейс вызова (dii)
- •Репозиторий интерфейсов (Interface Repository)
- •Протоколы взаимодействия различных объектных брокеров (giop, iiop)
- •Основные службы (сервисы) стандарта corba
- •Достоинства orb
- •Выводы. Достоинства и недостатки использования corba
- •Технология ActiveX – основные возможности
- •Технология ole – связывание и вставка объектов
- •3.3.2 Распределенная компонентная модель объектов (dcom)
- •Обеспечение безопасного доступа к удаленному объекту
- •Достоинства и недостатки dcom
- •Балансировка нагрузки
- •Just-in-time-активация и пул объектов
- •Распределенные транзакции
- •Отложенные компоненты
- •Тема 4 Разработка распределенных приложений на платформе Microsoft.Net Framework
- •4.1. Основы платформы .Net Framework
- •4.2 Введение в среду Common Language Runtime
- •Примеры программ для платформы ms.Net
- •Первая программа на c#
- •Первая программа на vb.Net
- •4.3 Преимущества платформы ms.Net
- •4.4 Поддержка средств распределенной разработки
- •4.5 Сервисы и интерфейс программной компоненты
- •4.6 Среда Microsoft Message Queuing (msmq)
- •Базовая модель ejb
- •Средства защиты ejb
- •Транзакции
- •Тема 5. Современные технологи разработки распределенных систем
- •5.1 Технология Web-сервисов
- •5.1.1 Основы Web-сервисов
- •Общее взаимопонимание
- •5.1.2 Взаимодействие с веб-сервисами
- •Документно-ориентированные взаимодействия
- •5.1.3. Технология веб-сервисов
- •5.1.4. Пример использования
- •5.2. Определение сервисно-ориентированной архитектуры
- •5.3. Преимущества soa
- •5.4 Стек технологий веб-сервисов
- •5.5. Принципы взаимодействия веб-сервисов в рамках сервисно-ориентированной архитектуры
- •Тема 7. Распределенные бд
- •7.1. Свойства рбд
- •7.2. Механизм распределенных транзакций
- •7.3. Целостность данных
- •7.4 Прозрачность расположения
- •7.5. Обработка распределенных запросов
- •7.7. Технология тиражирования данных
- •7.8 Архитектура "клиент-сервер"
7.7. Технология тиражирования данных
Принципиальная характеристика тиражирования данных (data replication - dr) заключается в отказе от физического распределения данных. Суть dr состоит в том, что любая база данных (как для СУБД, так и для работающих с ней пользователей) всегда является локальной; данные размещаются локально на том узле сети, где они обрабатываются; все транзакции в системе завершаются локально. Тиражирование данных - это асинхронный перенос изменений объектов исходной базы данных в базы, принадлежащим различным узлам распределенной системы. Функции dr выполняет, как правило, специальный модуль СУБД - сервер тиражирования данных, называемый репликатором (так устроены СУБД ca-openingres и sybase). В informix-online dynamic server репликатор встроен в сервер, в oracle 7 для использования dr необходимо приобрести дополнительно к oracle7 dbms опцию replication option. Специфика механизмов dr зависит от используемой СУБД. Простейший вариант dr - использование "моментальных снимков" (snapshot). Рассмотрим пример из oracle:
create snapshot unfilled_orders refrash complete start with to_date ('dd-mon-yy hh23:mi:55') next sysdate + 7 as select customer_name, customer_address, order_date from customer@paris, order@london where customer.cust_name = order.customer_number and order_complete_flag = "n";
"Моментальный снимок" в виде горизонтальной проекции объединения таблиц customer и order будет выполнен в 23:55 и будет повторятся каждые 7 дней. Каждый раз будут выбираться только завершенные заказы.
Реальные схемы тиражирования, разумеется, устроены более сложно. В качестве базиса для тиражирования выступает транзакция к базе данных. В то же время возможен перенос изменений группами транзакций, периодически или в некоторый момент времени, что дает возможность исследовать состояние принимающей базы на определенный момент времени.
Детали тиражирования данных полностью скрыты от прикладной программы; ее функционирование никак не зависят от работы репликатора, который целиком находится в ведении администратора базы данных. Следовательно, для переноса программы в распределенную среду с тиражируемыми данными не требуется ее модификации. В этом, собственно, состоит качество 6 в определении Дэйта. Синхронное обновление ddb и dr-технология - в определенном смысле антиподы. Краеугольный камень первой - синхронное завершение транзакций одновременно на нескольких узлах распределенной системы, то есть синхронная фиксация изменений в ddb. ee "Ахиллесова пята" - жесткие требования к производительности и надежности каналов связи. Если база данных распределена по нескольким территориально удаленным узлам, объединенным медленными и ненадежными каналами связи, а число одновременно работающих пользователей составляет сотни и выше, то вероятность того, что распределенная транзакция будет зафиксирована в обозримом временном интервале, становится чрезвычайно малой. В таких условиях (характерных, кстати, для большинства отечественных организаций) обработка распределенных данных практически невозможна. dr-технология не требует синхронной фиксации изменений, и в этом ее сильная сторона. В действительности далеко не во всех задачах требуется обеспечение идентичности БД на различных узлах в любое время. Достаточно поддерживать тождественность данных лишь в определенные критичные моменты времени. Можно накапливать изменения в данных в виде транзакций в одном узле и периодически копировать эти изменения на другие узлы. Налицо преимущества dr-технологии. Во-первых, данные всегда расположены там, где они обрабатываются - следовательно, скорость доступа к ним существенно увеличивается. Во-вторых, передача только операций, изменяющих данные (а не всех операций доступа к удаленным данным), и к тому же в асинхронном режиме позволяет значительно уменьшить трафик. В-третьих, со стороны исходной базы для принимающих баз репликатор выступает как процесс, инициированный одним пользователем, в то время как в физически распределенной среде с каждым локальным сервером работают все пользователи распределенной системы, конкурирующие за ресурсы друг с другом. Наконец, в-четвертых, никакой продолжительный сбой связи не в состоянии нарушить передачу изменений. Дело в том, что тиражирование предполагает буферизацию потока изменений (транзакций); после восстановления связи передача возобновляется с той транзакции, на которой тиражирование было прервано.
dr-технология данных не лишена недостатков. Например, невозможно полностью исключить конфликты между двумя версиями одной и той же записи. Он может возникнуть, когда вследствие все той же асинхронности два пользователя на разных узлах исправят одну и ту же запись в тот момент, пока изменения в данных из первой базы данных еще не были перенесены во вторую. При проектировании распределенной среды с использованием dr-технологии необходимо предусмотреть конфликтные ситуации и запрограммировать репликатор на какой-либо вариант их разрешения. В этом смысле применение dr-технологии - наиболее сильная угроза целостности ddb. На мой взгляд, dr-технологию нужно применять крайне осторожно, только для решения задач с жестко ограниченными условиями и по тщательно продуманной схеме, включающей осмысленный алгоритм разрешения конфликтов.
