20.1. Введение

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

Кроме того, в главе 2 обсуждались системы "клиент/сервер", которые можно рас- сматривать как простой частный случай распределенных систем вообще. Системы "клиент/сервер" будут рассмотрены в разделе 20.5.

Общий план данной главы приведен в конце следующего раздела.

20.2. Предварительные сведения

Начнем с рабочих определений, которые на этом этапе неизбежно будут не со- всем точны.

■ Система распределенных баз данных состоит из набора узлов (sites), связанных коммуникационной сетью, в которой:

а) каждый узел — это полноценная СУБД сама по себе, но

б) узлы взаимодействуют между собой таким образом, что пользователь любого из них может получить доступ к любым данным в сети так, как будто они нахо- дятся на его собственном узле.

Из этого определения следует, что так называемая "распределенная база данных" в действительности является виртуальной базой данных, компоненты которой физически хранятся в нескольких "реальных" базах данных на нескольких различных узлах (в сущ- ности, являясь логическим объединением этих реальных баз данных). Пример подобной структуры показан на рис. 20.1.

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

Чаще всего предполагается, что узлы физически распределены (а возможно, и гео- графически, как показано на рис. 20.1), хотя в действительности достаточно того, чтобы они были распределены логически. Два "узла" могут даже сосуществовать на одной и той же машине (в особенности на начальном этапе тестирования). Главная цель создания распределенных систем со временем изменялась. В ранних исследованиях в основном предполагалась географическая распределенность, но в большинстве первых коммерче- ских реализаций предполагалось локальное распределение, когда несколько "узлов" раз- мещалось в одном здании и соединялось с помощью локальной сети (ЛВС). Однако поз- же стремительное распространение глобальных сетей (ГВС) снова пробудило интерес к возможности географического распределения. В любом случае это не имеет большого значения с точки зрения системы баз данных — решать, в основном, требуется одни и те же технические (связанные с базами данных) проблемы. Поэтому в настоящей главе мы можем обоснованно рассматривать представленную на рис 20.1 систему как типичного представителя распределенных систем.

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

Преимущества

Зачем нужны распределенные базы данных? Основная причина заключается в том, что предприятия обычно уже распределены. Распределены по крайней мере логически, т.е. разделены на подразделения, отделы, рабочие группы и т.д. Очень часто они распре- делены и физически, т.е. разделены на заводы, фабрики, лаборатории и т.д. Из этого сле- дует, что данные также обычно распределены, поскольку каждая организационная еди- ница создает и обрабатывает собственные данные, относящиеся к деятельности этой единицы. Таким образом, информация предприятия разбивается на части, которые ино- гда называют островами информации. А распределенная система обеспечивает мосты для их соединения в единое целое. Иначе говоря, распределенная система позволяет структуре базы данных отображать структуру предприятия — локальные данные могут храниться локально, в соответствии с логической принадлежностью, тогда как к удален- ным данным доступ может осуществляться по мере необходимости.

Для того чтобы лучше в этом разобраться, приведем пример. Рассмотрим еще раз рис. 20.1. Для простоты предположим, что есть только два узла, Лос-Анджелес и Сан- Франциско, и что наша система— это банковская система. Данные о счетах Лос- Анджелеса хранятся в Лос-Анджелесе, а данные о счетах Сан-Франциско— в Сан- Франциско. Преимущества подобной распределенной системы очевидны: эффективность обработки (данные хранятся в том месте, где доступ к ним требуется наиболее часто) плюс расширенные возможности доступа (при необходимости с помощью коммуникационной сети из Сан-Франциско можно получить доступ к счетам Лос-Анджелеса и наоборот).

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

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

Примеры распределенных систем

Для ссылок в дальнейшем мы кратко перечислим некоторые известные реализации распределенных систем. Сначала — прототипы. Среди многочисленных исследователь- ских систем наиболее известны три системы. Во-первых, система SDD-1, созданная в на- учно-исследовательском отделении корпорации Computer Corporation of America в конце 70-х и начале 80-х годов [20.34]. Во-вторых, система R* (читается "R-star"), распреде- ленная версия системы-прототипа System R, созданная в исследовательском отделе ком- пании IBM в начале 80-х годов [20.39]. И в-третьих, система Distributed Ingres, распреде- ленная версия прототипа системы Ingres, созданная также в начале 80-х годов в Кали- форнийском университете в Беркли [20.36].

Что касается коммерческих реализаций, то большинство современных SQL-продуктов включает определенную поддержку распределенных баз данных, но, конечно, с разными уровнями функциональных возможностей. Наиболее известные среди них следующие: Ingres/Star (распределенный компонент базы данных СУБД Ingres), версия для распреде- ленных баз данных СУБД Oracle и средства распределения данных для СУБД DB2.

Замечание. Безусловно, эти два списка не претендуют на полноту. Их назначение — лишь указать системы, которые по тем или иным причинам оказывали или оказывают определенное влияние на развитие данной области либо представляют интерес благодаря своей внутренней структуре.

Также следует отметить, что все перечисленные выше системы, как прототипы, так и коммерческие продукты, являются реляционными (по крайней мере, в них поддер- живается язык SQL). В действительности существует несколько конкретных причин, по которым для успешной реализации распределенная система должна быть реляци- онной. Реляционная технология — это необходимое условия для эффективной распре- деленной технологии [20.15]. Некоторые причины такого положения дел будут рас- смотрены ниже в этой главе.

Фундаментальный принцип

Теперь сформулируем утверждение, которое может рассматриваться как фундамен- тальный принцип создания распределенных баз данных [20.14].

■ Для пользователя распределенная система должна выглядеть так же, как не- распределенная система.

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

Замечание. Понятие "пользователи" в предыдущем абзаце относится к пользователям (конечным пользователям или прикладным программистам), выполняющим операции обработки данных. Все операции манипулирования данными должны оставаться логиче-

ски неизменными. Но для операции определения данных, напротив, в распределенной системе обязательно потребуются некоторые дополнения. Например, пользователь на узле X должен иметь возможность указать, что данная переменная-отношение будет раз- делена на "фрагменты", которые будут храниться на узлах Y и Z (см. обсуждение фраг- ментации в следующем разделе).

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

1. Локальная независимость.

2. Отсутствие опоры на центральный узел.

3. Непрерывное функционирование.

4. Независимость от расположения.

5. Независимость от фрагментации.

6. Независимость от репликации.

7. Обработка распределенных запросов.

8. Управление распределенными транзакциями.

9. Аппаратная независимость.

10. Независимость от операционной системы.

11. Независимость от сети.

12. Независимость от типа СУБД.

Обратите внимание, что не все эти цели независимы одна от другой. Кроме того, они недостаточно исчерпывающие и не все одинаково важны (разные пользователи могут придавать различное значение разным целям в различных средах, и, кроме того, некото- рые из этих целей могут быть вообще неприменимы в некоторых ситуациях). Однако данные цели полезны как основа для понимания самой распределенной технологии и как общая схема описания функциональных возможностей конкретных распределенных сис- тем. Поэтому мы будем использовать список этих целей как организационный принцип для большей части данной главы. В разделе 20.3 кратко обсуждается каждая из целей. В разделе 20.4 некоторые конкретные вопросы рассматриваются более подробно, а в раз- деле 20.5, как уже отмечалось, приводится обсуждение систем "клиент/сервер". В разде- ле 20.6 мы детально обсудим некоторые конкретные проблемы, связанные с достижени- ем независимости от СУБД. И наконец, раздел 20.7 посвящен поддержке языка SQL, а в разделе 20.8 представлены резюме и несколько заключительных замечаний.

И последний дополнительный вопрос в этом разделе. Важно отличать истинные обобщенные системы распределенных баз данных от систем, которые предоставляют просто удаленный доступ к данным (кстати, это все, что на самом деле предоставляет пользователям система "клиент/сервер"). В системах удаленного доступа к данным ко- нечный пользователь может оперировать данными на удаленном узле или даже данными

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