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

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

Для ссылок в дальнейшем мы кратко перечислим некоторые известные реализации распределенных систем. Сначала - прототипы. Среди многочисленных исследовательских систем наиболее известны три системы. Во-первых, система SDD-1, созданная в научно-исследовательском отделении корпорации Computer Coфoration 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 представлены резюме и несколько заключительных замечаний.

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

Правила - это термин, используемый в статье, в которой эти правила впервые были представлены [20.14]. Фундаментальный принцип был назван Правилом Нуль . Однако на самом деле здесь более уместен термин цели - правила звучит слишком категорично. В этой главе будет использоваться более умеренное цели .

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

20.3. Двенадцать основных целей

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

Узлы в распределенной системе должны быть независимы, или автономны. Локальная независимость означает, что все операции на узле контролируются этим узлом. Никакой узел X не должен зависеть от некоторого узла У, чтобы успешно функционировать (иначе, если узел У будет отключен, узел X не сможет функционировать, даже если на самом узле X будет все в порядке; возникновение таких ситуаций, безусловно, нежелательно). Локальная независимость также означает, что локальные данные имеют локальную принадлежность, управление и учет. Все данные реально принадлежат одной и той же локальной базе данных, даже если доступ к ней осушествляется с других, удаленных узлов. Следовательно, такие вопросы, как безопасность, целостность и представление локальных данных в памяти, остаются под контролем и в пределах компетенции локального узла.

В действительности локальная независимость не вполне достижима - есть множество ситуаций, в которых узел X должен отказываться в определенной степени от контроля в пользу узла У. Поэтому цель достижения локальной независимости точнее можно было бы сформулировать так: узлы должны быть независимыми в максимально возможной степени. (См. аннотацию к публикации [20.14], где этот вопрос описан подробнее.)

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

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

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