РАСПРЕДЕЛЕННЫЕ СУБД

Источник:http://mrivkin.narod.ru/Publ/RASPBD.htm

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

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

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

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

Конечно для того, чтобы реализовать такой простой для конечного пользователя и разработчика механизм представления распределенной БД, необходимо решить множество проблем. Наиболее очевидные из них связаны с обеспечением целостности и непротиворечивости данных распределенной БД, реализацией механизма поддержки "прозрачности" распределенной БД, реализацией единого механизма работы с частями БД, находящимися в СУБД различного типа и расположенными на разнотипных компьютерах с различными операционными системами, обеспечением приемлемого быстродействия прикладной системы и т.д.

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

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

- Informix On-Line фирмы Informix Software;

- Ingres Intelligent Database фирмы Ingres Corp;

- Oracle (version 7) фирмы Oracle Corp;

- Sybase System 10 фирмы Sybase Inc.

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

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

"Распределенная СУБД обеспечивает пользователям доступ к информации независимо от того, какое оборудование и какое прикладное программное обеспечение используется в узлах сети. Пользователи при этом не обязаны знать, где физически размещаются данные и как надо выполнять физический доступ к ним. Распределенная СУБД позволяет выполнять горизонтальное и вертикальное "расщепление" таблиц и помещать данные одной таблицы в различных узлах сети. Запросы к данным распределенной БД формулируются так, как будто база данных локальна. При обработке транзакций и выполнении операций копирования/восстановления распределенной БД обеспечивается целостность всей БД.

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

Президент фирмы Alternative Technologies Макговерн сформулировал 13 основных функций, которые должна поддерживать распределенная СУБД [4]. Рассмотрим их подробнее.

1. РАСПРЕДЕЛЕННЫЙ СЛОВАРЬ (ДИРРЕКТОРИЯ) ДАННЫХ. В словаре содержится информация о типе данных, месте их размещения и о способе доступа к данным.

2. "ПРОЗРАЧНЫЙ ПРОТОКОЛ ДВУХФАЗНОй ФИКСАЦИИ ИЗМЕНЕНИЙ. Этот протокол обеспечивает непротиворечивость данных. При выполнении транзакции, изменяющей данные в нескольких узлах, протокол двухфазной фиксации обеспечивает успешное выполнение всей транзакции только в том случае, если успешно выполнилась обработка в каждом узле. Если же в одном из узлов обработка не выполнена успешно, то анулируются результаты работы всей транзакции.

3. ГОРИЗОНТАЛЬНАЯ И ВЕРТИКАЛЬНАЯ ФРАГМЕНТАЦИЯ. Эта функция позволяет "расщеплять" таблицу БД по строкам (горизонтально) и по столбцам (вертикально) и размещать части данных таблицы в разных узлах сети.

4.НЕЗАВИСИМОСТЬ ДУБЛИРОВАНИЯ ДАННЫХ. Это свойство СУБД позволяет создавать в узлах сети дубли данных без снижения производительности приложения и без нарушения непротиворечивости данных.

5. РАСПРЕДЕЛЕННЫЕ ПРЕДСТАВЛЕНИЯ (views). Представления могут формироваться при выполнении операции соединения (join) таблиц, размещающихся в разных узлах.

6. ОПТИМИЗАЦИЯ РАСПРЕДЕЛЕННЫХ ЗАПРОСОВ. Оптимизация алгоритмов выполнения сложных операций, например соединения таблиц, выполняется с учетом размещения данных в глобальной сети. При этом учитывается пропускная способность сети, ее загрузка и объем передаваемой информации, вычислительная мощность узлов. На основе этой информации делается вывод о том, где лучше всего производить операцию соединения таблиц (как наиболее трудоемкую операцию).

7. РАСПРЕДЕЛЕННЫЕ ОГРАНИЧЕНИЯ ЦЕЛОСТНОСТИ. Эта функция обеспечивает ссылочную целостность данных. В узлах могут находиться таблицы, зависящие от некоторой таблицы-мастера. При модификации данных таблицы-мастера автоматически модифицируются зависимые таблицы.

8. ЛОКАЛЬНАЯ АВТОНОМИЯ. Администратор БД конкретного узла полностью контролирует данные локальной БД данного узла. Он может работать независимо от администраторов других узлов.

9. НЕПРЕРЫВНАЯ ОБРАБОТКА (continual operation). Обработка, выполняемая в локальном узле БД, не может быть прервана командами из другого узла. Т.е. в каждом узле обработка выполняется независимо и целиком.

10. НЕЗАВИСИМОСТЬ РАЗМЕЩЕНИЯ. Изменение места хранения данных не ведет к изменению работающих с этими данными приложений.

11. ОБРАБОТКА РАСПРЕДЕЛЕННЫХ ТРАНЗАКЦИЙ. Обеспечение ограничений целостности поддерживается и при выполнении транзакции, изменяющей несколько узлов.

12. ГЛОБАЛЬНАЯ ОБРАБОТКА ВЗАИМОБЛОКИРОВОК И ПРОБЛЕМ, ВОЗНИКАЮЩИХ ПРИ ОДНОВРЕМЕННОМ ДОСТУПЕ К ДАННЫМ. Блокировка данных может выполняться во всех узлах БД. Необходимо выявлять и разрешать ситуации, когда два узла взаимно блокируют друг друга.

13. НЕЗАВИСИМОСТЬ ОТ ТИПА КОМПЬЮТЕРОВ, ОПЕРАЦИОННЫХ СИСТЕМ, СЕТЕВЫХ ПРОТОКОЛОВ, ТИПОВ СУБД. Эта независимость осуществляется путем использования как встроенных в СУБД средств, так и шлюзов (gateways).

СВОЙСТВА И ХАРАКТЕРИСТИКИ КОММЕРЧЕСКИХ РАСПРЕДЕЛЕННЫХ СУБД

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

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

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

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

Результаты сравнения характеристик и функций 4 распределенных СУБД приведены в таблице. Из нее видно, что наиболее полно функции распределенной СУБД реализованы в СУБД Ingres и Oracle. Коротко рассмотрим возможности этих пакетов и то, как они реализуют требования Макговерна.

СУБД Ingres работает на множестве UNIX-платформ, на платформах DEC VMS, Hewlett-Packard MPE, DOS, Microsoft Windows 3.1, OS/2, Macintosh. Она также работает со многими сетевыми протоколами, включая Open System Interconnection Transport Class 4. Ingres имеет средства для доступа к данным СУБД DB2, Rdb, Allbase. Основные функции распределенной СУБД обеспечиваются дополнительной компонентой Ingres/Star. Она поддерживает оптимизацию распределенных запросов, позволяет читать и обновлять в рамках одной транзакции данные разных узлов, обеспечивает возможность удалять записи одновременно в нескольких узлах.

СУБД Informix-Online разработана для среды UNIX, но может также работать под Novell. Informix-Online имеет оптимизатор запросов и реализует те же функции работы с распределенной БД, что и Ingres, однако у Informix более жесткие требования к ресурсам компьютера, в частности ему требуется больше оперативной памяти.

СУБД System 10 фирмы Sybase в настоящее время находится в состоянии разработки. Она должна работать на UNIX-платформах, на платформах OS/2, Window NT, NetWare. System 10 будет работать с несколькими сетевыми протоколами и поддерживать связь с СУБД DB2, Oracle 7, Informix-Online, Rdb. System 10 будет иметь оптимизатор распределенных запросов, она позволит читать и обновлять данные нескольких узлов. Функции работы с распределенной БД будут реализованы с помощью дополнительной компоненты Replication Server.

В 7 версии СУБД Oracle реализовано множество функций для работы с распределенной БД. Среди них следует выделить оптимизатор распределенных запросов и средство чтения и обновления данных нескольких узлов в рамках одной транзакции. Oracle v 7 работает на более чем 80 вычислительных платформах, поддерживает большинство существующих коммерческих сетевых протоколов и может обмениваться данными с СУБД DB2, SQL/DS, Tandem Computers, NonStop SQL, Rdb, HP TurboImage. Разрабатываются шлюзы еще к 18 СУБД.

В Oracle 7 реализованы и остальные требования Макговерна. Так дублирование таблиц может выполняться 2 путями: с помощью триггеров (процедурно) и с помощью декларативного описания (средство копирования таблиц SNAPSHOT). Оптимизатор распределенных запросов позволяет выполнить как автоматическую, так и автоматизированную (с учетом пожеланий разработчика) оптимизацию. Он учитывает текущие объемные характеристики таблиц. Кроме распределенной ссылочной целостности Oracle поддерживает и ряд других распределенных декларативных ограничений целостности.

Все 4 рассмотренные СУБД поддерживают локальную автономию узлов. Это означает, что администратор БД может рассматривать локальную БД конкретного узла как самостоятельную БД. Все СУБД поддерживают ANSI стандарт языка SQL - ANSI SQL-89 и расширение этого стандарта. Запросы к БД формулируются на языке SQL. Дополнительно к непроцедурному языку SQL Oracle поддерживает свой собственный процедурный язык PL/SQL, а Sybase поддерживает свой язык Transact-SQL. Все 4 СУБД обеспечивают "прозрачный" механизм запроса, обновления и просмотра данных, размещенных в нескольких узлах. Уже отмечалось, что все 4 СУБД могут обмениваться данными с другими СУБД. Однако только двухфазный протокол фиксации Oracle 7 позволяет выполнять распределенные обновления данных в разных СУБД. Проблема заключается в том, что двухфазные протоколы фиксации изменений разных СУБД плохо совместимы между собой.