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

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

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

8. Обработка распределенных транзакций

Существует два главных аспекта управления транзакциями, а именно

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

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

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

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

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

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

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

11.Независимость от сетевой архитектуры.

Необходимо, чтобы СУБД поддерживала различные типы коммуникационных сетей (Ethernet, TR, FDDI, X.25, etc.)

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

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

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

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

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