1. Пересылка записей о деталях на узел А и обработка запроса на узле А.

Т[1] = 0,1 + ( 100000 * 200 ) / 50000 = 400 с (приблизительно 6,67 мин)

2. Пересылка записей о поставщиках и поставках на узел Б и обработка запроса на узле Б.

Т[2] = 0,2 + ( ( 10000 + 1000000 ) * 200 ) / 50000 = 4040 с (приблизительно 1,12 ч)

3. Соединение отношений поставщиков и поставок на узле А, выборка из результирующего отношения кортежей для поставщиков из Лондона с последующей проверкой на узле Б для каждого выбранного поставщика соответствующих деталей, является ли деталь красной. Каждая из таких проверок включает два сообщения: запрос и ответ. Время передачи этих сообщений будет мало по сравнению с задержкой доступа.

Т[3] = 20000 с (приблизительно 5,56 ч)

4. Выборка красных деталей на узле Б и проверка для каждой из выбранных деталей на узле А наличия поставок, связывающих эту деталь с поставщиком из Лондона. Каждая из таких проверок включает два сообщения. Время передачи этих сообщений также будет мало по сравнению с задержкой доступа.

Т[4] = 2 с (приблизительно)

5. Соединение отношений поставщиков и поставок на узле А, выборка из результата кортежей для поставщиков из Лондона, проекция этих кортежей по атрибутам S# и Р# и пересылка результата на узел Б. Завершение обработки на узле Б.

Т[5] = 0,1 + ( 100000 * 200 ) / 50000 = 400 с (приблизительно 6,67 мин)

6. Выборка красных деталей на узле Б и пересылка результата на узел А. Завершение обработки на узле А.

Т[6] = 0,1 + ( 10 * 200 ) / 50000 = 0,1 с (приблизительно)

На рис. 20.4 подведены итоги результатов обработки различных вариантов запроса.

Рис. 20.4. Возможные стратегии распределенной обработки запроса (сводка) Прокомментируем эти результаты.

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

Скорость обмена данными и задержки доступа - важные факторы в выборе стратегии.

Для плохих стратегий время вычислений и ввода-вывода ничтожно мало по сравнению со временем передачи данных. С другой стороны, для лучших стратегий это соотношение может зависеть от дополнительных обстоятельств [20.35]. Такого большого расхождения может не быть в случае использования быстрых локальных сетей.

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

Управление каталогом

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

1. Централизованное хранение. Единственный общий каталог хранится на отдельном центральном узле.

2. Полная репликация. Общий каталог целиком хранится на каждом узле.

3. Частичное хранение. Каждый узел поддерживает собственный каталог для объектов, которые на нем хранятся. Общий каталог представляет собой объединение всех этих несвязанных локальных каталогов.

4. Сочетание подходов 1 и 3. Каждый узел поддерживает свой локальный каталог, как предусмотрено при подходе 3. Кроме того, отдельный центральный узел сопровождает объединенную копию всех этих локальных каталогов, как предусмотрено при подходе 1.

Каждый подход имеет свои недостатки. При подходе 1, очевидно, нарушается принцип Отсутствие опоры на центральный узел . При подходе 2 в значительной мере утрачивается независимость узлов, поскольку всякое обновление каталога должно распространяться на каждый узел. При подходе 3 нелокальные операции становятся слишком затратными (для поиска удаленного объекта требуется досгуп в среднем к половине всех узлов). Подход 4 более эффективный по сравнению с подходом 3 (для поиска удаленного объекта требуется доступ лишь к одному удаленному каталогу), но в этом случае вновь нарушается принцип отсутствия центрального узла. Поэтому на практике системы обычно не используют ни один из этих подходов! В качестве примера рассмотрим подход, который применяется в версии R* системы R [20.39].

Прежде чем описать структуру каталога системы R*, необходимо сказать несколько слов о механизме именования объектов в этой системе. Присвоение имен объектам - это вообще очень важный вопрос для распределенных систем. Поскольку два отдельных узла X и Y могут иметь объект (скажем, базовую переменную-отношение) с именем А, требуется некоторый механизм (обычно - уточнение с помощью имени узла) для того, чтобы устранить неоднозначность , т.е. гарантировать уникальность расширенного системного имени. Однако, если уточненные имена, такие какХ.А и Y.A, будут предостав-

ляться системой и пользователю, будет нарушено требование независимости от разме-шения. Поэтому необходимы средства отображения имен для пользователя в соответствуюшие системные имена.

Теперь изложим подход к рассматриваемой проблеме, принятый в системе R*. В этой системе различаются печатные имена, с помошью которых пользователи обычно обращаются к объектам (например, в предложении SELECT языка SQL), и общесистемные имена, которые представляют собой глобальные уникальные внутренние идентификаторы для этих же объектов. Расширенные системные имена имеют четыре следующих компонента.

Идентификатор создателя, т.е. идентификатор пользователя, который создал объект.

Идентификатор узла создателя, т.е. идентификатор узла, на котором была введена соответствующая операция CREATE (создать).

Локальное имя, т.е. не уточненное имя объекта.

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

Идентификаторы пользователя уникальны на узле, тогда как идентификаторы узла уникальны глобально. Рассмотрим, например, следующее расширенное системное имя.

MARILYN е NEWYORK . STATS g LONDON

Оно обозначает объект (возможно, базовую переменную-отношение) с локальным именем STATS, созданный пользователем MARILYN на узле в Нью-Йорке и первоначально сохраненный на узле в Лондоне. Это имя гарантировано защищено от каких-либо изменений, даже если объект будет перемещен на другой узел (см. ниже).

Как уже указывалось, пользователи обычно ссылаются на объекты с помощью печатных имен. Печатное имя представляет собой простое, не уточненное имя- компонент локальное имя из расширенного системного имени (в примере это STATS) или синоним для соответствующего расширенного системного имени, который в системе R* определяется с помощью специального оператора CREATE SYNONYM, как, например, показано ниже.

CREATE SYNONYM MSTATS FOR MARILYN 8 NEWYORK . STATS 8 LONDON ;

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

SELECT FROM STATS ;

SELECT FROM MSTATS ;

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

В системе R* базовые переменные-отношения физически хранятся так, как они хранятся почти во всех известных автору системах.