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

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

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

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

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

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

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

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

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