Главная » SQL, Базы данных » ДВЕНАДЦАТЬ ОСНОВНЫХ ЦЕЛЕЙ РАСПРЕДЕЛЕННЫХ СИСТЕМ 1 .

0

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

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

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

2.      Отсутствие зависимости от центрального узла

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

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

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

В общем случае преимущество распределенных систем состоит в том, что они должны предоставлять более высокую степень надежности и доступности.

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

■  Доступность понимается как высокая степень вероятности того, что система окажется исправной и работоспособной и будет непрерывно функционировать в течение определенного времени. Доступность, как и  надежность распределенных систем также повышается — частично по тем  же причинам, а также благодаря возможности дублирования данных  (подробности приводятся в комментарии к цели 6).

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

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

!                                          Основная идея независимости от расположения, или так называемой

прозрачности

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

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

Примечание. Нетрудно заметить, что независимость от расположения  представляет собой простое расширение обычной концепции физической  независимости от данных применительно к распределенным системам. Забегая несколько вперед, следует сказать, что на самом деле каждую из целей, в названии которой употреблено слово "независимость", можно рассматривать  как  расширение обычной концепции физической независимости от данных, в чем мы скоро убедимся. Мы еще возвратимся к вопросу независимости от расположения в разделе 21.4, в котором будет обсуждаться присваивание имен объектам (подраздел "Управление каталогом").

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

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

FRAGMENT EMP AS

N_EMP AT SITE ‘New York1 WHERE DEPT#    =  DEPT# (‘Dl’)

OR   DEPT# =    DEPT#     (‘D3′) , L_EMP AT SITE ‘London’  WHERE DEPT#    =  DEPT# (‘D2′) ;

Примечание. Здесь подразумевается, что кортежи с данными о служащих переменной отношения ЕМР отображаются в физической памяти каким-то непосредственным способом, причем D1 и D3 — отделы, расположенные в Нью-Йорке, a D2 — отдел, расположенный в Лондоне. Таким образом, кортежи с данными о служащих из Нью-Йорка хранятся на узле в Нью-Йорке, а кортежи с данными о служащих из Лондона — на узле в Лондоне. Отметим, что внутрисистемные имена фрагментов— N_EMP И L_EMP.

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

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

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

Примечание. Если действительно необходимо хранить одну и ту же часть данных в нескольких различных местах, можно воспользоваться системным механизмом репликации

для достижения такого эффекта; см. следующий подраздел.

Рис. 21.2. Пример фрагментации

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

Необходимо сказать еще несколько слов относительно вертикальной фрагментации. Как утверждалось выше, несомненно, что такая фрагментация должна выполняться без потерь. Поэтому разбиение переменной отношения  ЕМР,  показанной на рис. 21.2, на фрагменты-проекции, например, вида {EMP#,DEPT#} и {SALARY} было бы недопустимым. Однако в некоторых системах хранимые переменные отношения рассматриваются

как имеющие скрытый, предоставляемый системой атрибут идентификатор кортежа, или сокращенно — атрибут TID (Tuple ID). Для каждого хранимого кортежа атрибут TID, грубо говоря, является адресом. Очевидно, что он является одним из потенциальных ключей для соответствующей переменной отношения. Поэтому, например, если бы переменная отношения ЕМР содержала такой атрибут, то она могла бы быть фрагментирована на проекции {TID,EMP#,DEPT#} и {TID, SALARY}, поскольку такая фрагментация уже, безусловно, выполняется без потерь. Также обратите внимание на то, что если, например, атрибут TID является скрытым, то это никак не нарушает  информационный принцип, поскольку независимость от фрагментации (которая  вскоре будет рассматриваться в данной главе) означает, что пользователь не  должен знать о существовании фрагментации.

Кстати, отметим, что простота осуществления и фрагментации, и восстановления —

это две основные причины, по которым распределенные базы данных должны  быть именно реляционными. Реляционная модель предоставляет все те  операции,  которые

необходимы для решения таких задач [15.6].

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

называют прозрачностью фрагментации). Другими словами, пользователи должны иметь

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

Таким образом, если обеспечивается независимость от фрагментации,  пользователи получают данные в виде некоторого представления, в котором  фрагменты логически

скомбинированы с помощью соответствующих операций соединения и объединения.

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

ЕМР WHERE SALARY > 40K AND DEPT# = DEPT# ( ‘ Dl ‘ )

Из определений фрагментов (которые хранятся, конечно же, в каталоге; оптимизатору должно быть известно, что весь требуемый результат может быть получен только по данным узла в Нью-Йорке, а значит, нет никакой  необходимости обращаться к узлу в Лондоне.

Рассмотрим этот пример более подробно. Переменная отношения ЕМР с точки зрения пользователя может рассматриваться (упрощенно) как некоторое представление, сформированное на основе базовых фрагментовNJEMP и L_EMP, следующим образом.

VAR ЕМР "VIEW"                                                                                                                            /* Псевдокод */ N_EMP UNION L_EMP ;

Тогда оптимизатор преобразует исходный запрос пользователя в следующее выражение.

{ N_EMP UNION L_EMP ) WHERE SALARY > 4OK AMD DEPT# = DEPT# (‘Dl’)

В процессе дальнейшей оптимизации это выражение будет преобразовано в следующее выражение (поскольку операция сокращения распределяется по объединению).

( N_EMP WHERE SALARY > 4OK AND DEPT# = DEPT# (‘Dl’) ) UNION ( L_EMP WHERE SALARY > 40K AND DEPT# =

DEPT# (‘Dl’) )

Из определения фрагмента L_EMP в каталоге оптимизатору будет известно, что второй из этих двух операндов объединения UNION эквивалентен следующему выражению.

EMP WHERE SALARY > 4OK AND DEPT# =

DEPT# (‘Dl’) AND DEPT# = DEPT# (‘D2′)

Это выражение в результате вычисления даст пустое отношение, поскольку соответствующее условие в конструкции WHERE никогда не может стать истинным (TRUE). Таким образом, весь первоначальный запрос может быть приведен к следующему виду.

N_EMP WHERE SALARY > 40К AND DEPT# = DEPT# (‘Dl’)

Теперь оптимизатор определит, что требуется доступ лишь к данным узла в НьюЙорке.

Упражнение.  Рассмотрите,  какие  действия  должен  будет  выполнить  оптимизатор

при  обработке следующего запроса.

EMP WHERE SALARY > 4OK

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

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

Система поддерживает репликацию данных, если данная хранимая переменная отношения (или в общем случае данный фрагмент данной хранимой переменной отношения) может быть представлена несколькими отдельными копиями, или репликами, которые хранятся на нескольких отдельных узлах.  Рассмотрим конкретный пример (рис. 21.3). Обратите внимание на то, что внутри системы реплики имеют имена NL_EMP И LN_EMP.

REPLICATE N_EMP AS

LN_EMP AT SITE ‘London’ ;

REPLICATE L_EMP AS

NL_EMP AT SITE ‘New York’ ;

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

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

Рис. 21.3. Пример репликации данных

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

Из требования независимости от репликации следует, что к обязанностям системного оптимизатора также относится определение, какой именно из  физических дубликатов

будет применен для доступа к данным при выполнении каждого введенного пользователем запроса. Здесь не приведены подробные сведения по этому вопросу.

Завершая подраздел, отметим, что многие коммерческие продукты в настоящее время поддерживают такой вид репликации, который не обеспечивает полной независимости от

репликации, т.е. репликация будет не полностью "прозрачна для пользователя". Некоторые

дополнительные замечания по этому вопросу будут приведены в подразделе о распространении обновления в разделе 21.4.

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

Существует две особенности, касающиеся темы этого раздела, которые необходимо предварительно прокомментировать.

■     Во-первых, рассмотрим запрос: "Получить сведения о лондонских поставщиках деталей красного цвета". Предположим, что пользователь работает на узле в НьюЙорке, а данные размещены на узле в Лондоне. Предположим также, что имеется л поставщиков, которые удовлетворяют данному запросу. Если система реляци онная, то для выполнения этого запроса, по существу, потребуется пересылка двух сообщений: одно — с запросом из Нью-Йорка в Лондон, а другое — с возвращае мым результатом, т.е. набором из л кортежей, пересылаемых из Лондона в НьюЙорк. Если, с другой стороны, система — не реляционная и использует операции с таблицами на уровне отдельных записей, выполнение запроса будет, по существу, включать пересылку 2п сообщений — л сообщений из Нью-Йорка в Лондон, ко торые запрашивают данные следующего поставщика, и л сообщений из Лондона в Нью-Йорк, которые возвращают информацию об очередном поставщике. Этот пример показывает, что по производительности распределенная реляционная сис тема может на несколько порядков превосходить нереляционную.

■     Во-вторых, оптимизация в распределенных системах даже более важна, чем в цен трализованных. Суть в том, что для запроса, подобного рассмотренному выше, может потребоваться обращение к нескольким узлам. В такой системе может быть много возможных способов пересылки данных, позволяющих выполнить рассмат риваемый запрос. Поэтому крайне важно, чтобы была найдена эффективная стра тегия. Например, запрос для объединения, скажем, отношения Rx, хранимого на узле X, и отношения Ry, хранимого на узле Y, может быть выполнен посредством пересылки отношения Rx на узел Y или отношения Ry на узел X, или обоих отно шений на какой-либо узел Z и т.п. Наглядная иллюстрация важности оптимиза ции, включающая упомянутый выше запрос ("Получить сведения о лондонских поставщиках деталей красного цвета"), представлена в разделе 21.4. Подводя краткий итог этого примера, можно отметить, что для обработки данного запроса анализируется шесть различных стратегий с учетом определенного набора вероят ных допущений. В результате показано, что время ответа в каждом случае различ но и изменяется в широких пределах от минимального (от одной десятой секунды) до максимального (около шести часов!). Таким образом, оптимизация, несомнен но, весьма важна для распределенной системы и, кроме того, эту особенность можно считать еще одной причиной, по которой распределенные системы всегда должны быть реляционными (ответ прост: реляционные системы позволяют оп тимизировать обработку запросов, а нереляционные— нет).

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

Как известно, существует два главных аспекта управления транзакциями, а именно: управление восстановлением и управление параллельностью обработки. Оба этих аспекта имеют расширенную трактовку в среде распределенных систем. Чтобы разъяснить

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

Теперь обратимся непосредственно к управлению восстановлением. Чтобы  обеспечить неразрывность транзакции (выполнение ее по принципу "все или  ничего") в распределенной среде, система должна гарантировать, что все  множество относящихся к данной транзакции агентов или зафиксировало свои результаты, или выполнило откат. Такого результата можно достичь с помощью  протокола двухфазной фиксации транзакции, который уже обсуждался в главе 15, хотя это обсуждение и не было прямо связано с распределенными системами. Подробнее об использовании протокола  двухфазной фиксации в распределенных системах речь пойдет в разделе 21.4.

Что касается управления параллельностью, то оно в большинстве  распределенных систем базируется на механизме блокировки, точно так, как и в нераспределенных системах. В нескольких более новых коммерческих продуктах используется управление параллельной работой на основе одновременной поддержки многих версий [16.1]. Но на практике обычная блокировка, по-видимому, все еще остается тем методом, который лучше всего подходит для большинства систем. Подробнее этот вопрос также будет обсуждаться в разделе 21.4.

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

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

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

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

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

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

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

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

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

Однако эта тема слишком обширна (и важна на практике), поэтому ниже ей посвящен отдельный раздел (см. раздел 21.6).

Источник: Дейт К. Дж., Введение в системы баз данных, 8-е издание.: Пер. с англ. — М.: Издательский дом «Вильямс», 2005. — 1328 с.: ил. — Парал. тит. англ.

По теме:

  • Комментарии