Реализация распределенной базы данных с удаленным доступом

      Тиражирование данных - это асинхронный перенос  изменений объектов исходной базы данных (source database) в БД, принадлежащие различным  узлам распределенной системы. Функции  тиражирования данных выполняет специальный модуль СУБД - сервер тиражирования данных, называемый репликатором (replicator). Его задача - поддержка идентичности данных в принимающих базах данных (target database) данным в исходной БД. Сигналом для запуска репликатора служит срабатывание триггера, перехватывающего любые изменения тиражируемого объекта БД. Возможно и программное управление репликатором посредством сигнализаторов о событиях в базе данных.

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

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

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

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

      Преимущества  технологии тиражирования данных:  

1. Данные  всегда расположены там, где они  обрабатываются - следовательно, скорость доступа к ним существенно увеличивается.
2. Передача только операций, изменяющих данные (а не всех операций доступа к удаленным данным, как в технологии STAR), и к тому же в асинхронном режиме позволяет значительно уменьшить трафик.
3. Со стороны исходной БД для принимающих БД репликатор выступает как процесс, инициированный одним пользователем, в то время как в физически распределенной среде с каждым локальным сервером работают все пользователи распределенной системы, конкурирующие за ресурсы друг с другом.
4. Никакой продолжительный сбой связи не в состоянии нарушить передачу изменений. Дело в том, что тиражирование предполагает буферизацию потока изменений (транзакций); после восстановления связи передача возобновляется с той транзакции, на которой тиражирование было прервано.

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

1.4 Взаимодействие  с PC-ориентированными СУБД

      Первоначально профессиональные СУБД создавались  для мощных высокопроизводительных платформ - IBM, DEC, Helwett-Packard, Sun. Но затем, учитывая все возрастающую популярность и широкое распространение персональных компьютеров, разработчики приступили к переносу (портированию) СУБД в операционные среды desktop-компьютеров (OS/2, NetWare, UnixWare, SCO UNIX).

      В настоящее время большинство  компаний - поставщиков СУБД развивает  три направления своих систем. Во-первых, совершенствование СУБД для корпоративных информационных систем, которые характеризуются  большим числом пользователей (от 100 и выше), базами данных огромного объема (их часто называют сверхбольшими базами данных - Very Large Data Base - VLDB), смешанным характером обработки данных (решение задач оперативной обработки транзакций и поддержки принятия решений) и т.д. Это - традиционная область mainframe-систем и приближающихся к ним по производительности RISC-компьютеров.

      Другое  направление - СУБД, поддерживающие так  называемые рабочие группы. Это направление  характеризуется относительно небольшим  количеством пользователей  с  сохранением, тем не менее, всех "многопользовательских" качеств. Системы этого класса ориентированы преимущественно на "офисные" применения, не требующие специальных возможностей. Так, большинство современных многопользовательских СУБД имеют версии системы, функционирующие в сетевой операционной системе Novell NetWare. Ядро СУБД оформлено здесь как загружаемый модуль NetWare (NetWare Loadable Module - NLM), выполняющийся на файловом сервере. База данных также располагается на файловом сервере. SQL-запросы поступают к ядру СУБД от прикладных программ, которые запускаются на станциях сети - персональных компьютерах (отметим, что, несмотря на использование файлового сервера, здесь мы имеем дело с RDA-моделью).

      Наконец, новый импульс в развитии получило направление настольных (desktop) версий СУБД, ориентированных на персональное использование - преимущественно в операционной среде MS Windows (системы этого класса получили неформальное определение "light" или "local").

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

      В последние годы (1987-94) в нашей стране было разработано множество программ, ориентированных на использование СУБД типа PARADOX, FoxPRO, dBASE IV, Clipper. При переходе на более мощную многопользовательскую СУБД у пользователей возникает естественное желание интегрировать уже существующие разработки в эту среду. Например, может возникнуть потребность хранить локальные данные на персональном компьютере и осуществлять к ним доступ с помощью системы FoxPRO, и одновременно иметь доступ к глобальной базе данных под управлением СУБД Oracle. Организация такого доступа, когда программа может одновременно работать и с персональной, и с многопользовательской СУБД, представляет собой сложную проблему по следующей причине.

      Как известно, разработчики PC-ориентированных  СУБД первоначально использовали свой собственный интерфейс к базам данных, никак не учитывая требования стандарта языка SQL. Лишь впоследствии они стали постепенно включать в свои системы возможности работы с базой данных при помощи SQL. В то же время для истинно многопользовательских СУБД интерфейс SQL - фактический стандарт. При этом возникла задача согласования интерфейсов СУБД различных классов. Она может решаться несколькими способами, но большинство из них имеют частный характер. Рассмотрим наиболее общее решение этой задачи.

      Специалисты фирмы Microsoft разработали стандарт Open Database Connectivity (ODBC). Он представляет собой стандарт прикладного программного интерфейса прикладных (Application Programming Interface - API) и позволяет программам, работающим в среде Microsoft Windows, взаимодействовать (посредством операторов языка SQL) с различными СУБД, как персональными, так и многопользовательскими, функционирующими в различных операционных системах. Фактически, интерфейс ODBC универсальным образом отделяет чисто прикладную, содержательную сторону приложений (обработка электронных таблиц, статистический анализ, деловая графика) от собственно обработки и обмена данными с СУБД. Основная цель ODBC - сделать взаимодействие приложения и СУБД прозрачным, не зависящим от класса и особенностей используемой СУБД (мобильным с точки зрения используемой СУБД).

      Отметим, что стандарт ODBC является неотъемлемой частью семейства стандартов, облегчающих  написание и обеспечивающих вертикальную открытость приложений (WOSA - Windows Open Services Architecture - открытая архитектура сервисов системы Windows).

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

      ODBC-архитектура  содержит четыре компонента:  

• приложение;
• менеджер драйверов;
• драйверы;
• источники данных.

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

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

      Слой  доступа к данным, подобный ODBC использует в своих продуктах компания Borland. Эта система носит название Borland Database Engine (BDE) и имеет некоторые преимущества по сравнению с ODBC.

1.5 Обработка  транзакций

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

      Существуют  различные модели транзакций, которые  могут быть классифицированы на основании  различных свойств, включающих структуру  транзакции, параллельность внутри транзакции, продолжительность и т.д. Чаще всего  имеют в виду традиционные транзакции, характеризуемые четырьмя классическими свойствами: атомарности, согласованности, изолированности, долговечности (прочности) - ACID (Atomicity, Consistency, Isolation, Durability). Иногда традиционные транзакции называют ACID-транзакциями. Упомянутые выше свойства означают следующее: 

1. Свойство  атомарности выражается в том, что  транзакция должна быть выполнена в  целом или не выполнена вовсе.
2. Свойство согласованности гарантирует, что по мере выполнения транзакций данные переходят из одного согласованного состояния в другое - транзакция не разрушает взаимной согласованности данных.
3. Свойство изолированности означает, что конкурирующие за доступ к базе данных транзакции физически обрабатываются последовательно, изолированно друг от друга, но для пользователей это выглядит так, как будто они выполняются параллельно.
4. Свойство долговечности трактуется следующим образом: если транзакция завершена успешно, то те изменения в данных, которые были ею произведены, не могут быть потеряны ни при каких обстоятельствах (даже в случае последующих ошибок).

      Расширенные транзакции допускают формирование из ACID-транзакций иерархических структур. Если конкретная модель ослабляет некоторые  из требований ACID, то речь идет об ослабленной  транзакции.

      Возможны  два варианта завершения транзакции. Если все операторы выполнены успешно, и в процессе выполнения транзакции не произошло никаких сбоев программного или аппаратного обеспечения, транзакция фиксируется.