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

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

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

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

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

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

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

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

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