Распределенная обработка данных. Найханова Л.В. - 26 стр.

красных деталей", причем допустим, что пользователь находится в Нью-Йорке, а данные
хранятся на узле в Лондоне. Предположим также, что такому запросу удовлетворяют n
поставщиков. Если система является реляционной, то в запросе будут содержаться два
сообщения - одно с запросом из Нью-Йорка для Лондона, а другое с возвращаемым
результатом, т.е. набором из и кортежей, которые пересылаются из Лондона в Нью-Йорк.
С другой стороны, если система не является реляционной, а работает в режиме
последовательной обработки данных, то в запрос будет включено 2n сообщений - n из
Нью-Йорка в Лондон с запросом сведений о "следующем" поставщике, а также n из
Лондона в Нью-Йорк для возвращения сведений о "следующем" поставщике. Этот пример
иллюстрирует, что реляционная система по производительности может на несколько
порядков превосходить нереляционную (по крайней мере на уровне множеств).
       2. Вопрос оптимизации более важен для распределенной, нежели для централизо-
ванной системы. Основная причина заключается в том, что для выполнения охва-
тывающего несколько узлов запроса существует довольно много способов перемещения
данных по сети. В таком случае чрезвычайно важно найти наиболее эффективную
стратегию. Например, запрос на объединение отношения Rx, хранимого на узле X, и
отношения Ry, хранимого на узле Y, мог бы быть выполнен с помощью перемещения
отношения Rx на узел Y, перемещения отношения Ry на узел X или перемещения этих двух
отношений на третий узел Z (и т.д.). Эта ситуация подробно рассматривается ниже, а здесь
следует отметить, что на основе некоторых правдоподобных предположений можно
составить шесть различных стратегий обработки такого запроса. При этом время отклика
может варьироваться от минимального значения, равного одной десятой секунды, до
максимального, равного приблизительно шести часам! Таким образом, оптимизация
может оказаться весьма существенной, и этот факт, в свою очередь, может
рассматриваться как еще одна причина, по которой распределенные системы всегда
являются реляционными. Особенность заключается в том, что запросы могут быть
оптимизированы на уровне множеств, но не на уровне записей.
8. Управление распределенными транзакциями
      Существует два основных аспекта управления обработкой транзакций, а именно:
управление восстановлением и управление параллелизмом, каждому из которых в
распределенных системах должно уделяться повышенное внимание. Однако, прежде чем
перейти к подробному описанию, следует ввести новое понятие "агент". В рас-
пределенной системе выполнение одной транзакции может быть связано с исполнением
кода на нескольких узлах, в частности она может выполнять операции обновления на
нескольких узлах. В таком случае говорят, что каждая транзакция состоит из нескольких
агентов, т.е. процессов, выполняемых на данном узле по указанию заданной транзакции.
Системе необходимо указать, что некоторые два агента представляют собой части одной и
той же транзакции, например для того, чтобы избежать возникновения тупиковой
ситуации для двух агентов, которые содержит одна и та же транзакция.
      Несколько слов об управлении восстановлением. Для подтверждения того, что в
распределенном окружении данная транзакция является атомарной (типа «все-или-
ничего»), система должна убедиться, что агенты заданного набора должны быть все
вместе либо завершены, либо отменены. Эта цель может быть достигнута только за счет
реализации протокола двухфазной фиксации. Несколько более подробных замечаний на
эту тему представлено ниже.
      Что касается управления параллелизмом, то в распределенных системах, так же как
и в нераспределенных, это управление обычно основано на блокировке. (В нескольких
более современных системах уже используются средства многовариантного управления,
однако в большинстве систем для этого все же продолжает использоваться метод
блокировки). Более подробно эта тема рассматривается ниже.


26