Инструменты пользователя

Инструменты сайта


examination:rsubd:question15

Вопрос №15. Проблема управление каталогом

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

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

  • Централизованное хранение. Единственный общий каталог хранится на отдельном центральном узле.
  • Полная репликация. Общий каталог целиком хранится на каждом узле.
  • Частичное секционирование. Каждый узел поддерживает собственный каталог для объектов, которые на нем хранятся. Общий каталог представляет собой объединение всех этих непересекающихся локальных каталогов.
  • Сочетание подходов 1 и 3. На каждом узле поддерживается свой локальный каталог, как предусмотрено в подходе 3. Кроме того, отдельный центральный узел сопровождает объединенную копию всех этих локальных каталогов, как предусмотрено в подходе 1.


Каждый подход имеет свои недостатки. При подходе 1 очевидно нарушается принцип «отсутствия зависимости от центрального узла». При подходе 2 в значительной мере утрачивается независимость узлов, поскольку всякое обновление каталога должно рас-пространяться на каждый узел. При подходе 3 нелокальные операции становятся слиш-ком дорогостоящими (для поиска удаленного объекта требуется доступ в среднем к поло-вине всех узлов). Подход 4 более эффективен по сравнению с подходом 3 (для поиска удаленного объекта требуется доступ лишь к одному удаленному каталогу), но в этом слу-чае вновь нарушается принцип отсутствия зависимости от центрального узла. Поэтому на практике в системах обычно не используется ни один из этих четырех подходов.

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

Будем различаются вводимые имена, с помощью которых пользователи обычно обращаются к объектам (например, в конструкции SELECT языка SQL), и общесистемные имена, которые представляют собой глобально уникальные внутренние идентификаторы для этих же объектов. Общесистемные имена имеют четыре описанных ниже компонента:

  • Идентификатор создателя, т.е. идентификатор пользователя, который впервые вызвал на выполнению операцию CREATE для создания рассматриваемого объекта.
  • Идентификатор узла создателя, т.е. идентификатор узла, на котором была введена соответствующая операция CREATE.
  • Локальное имя, т.е. неуточненное имя объекта.
  • Идентификатор узла происхождения, т.е. идентификатор узла, на котором объект хранился первоначально.


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

MARILYN @ NEWYORK . STATS @ LONDON



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

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

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



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

SELECT ... FROM STATS ... ;


SELECT ... FROM MSTATS ... ;



В первом случае, т.е. при использовании локального имени, система будет исходить из того, что все компоненты общесистемного имени определяются по умолчанию, а именно – что объект создан данным пользователем, создан на данном узле и сохранен на данном узле. Во втором случае, т.е. при использовании синонима, система для определения общесистемного имени обращается к соответствующей таблице синонимов. Таблицы синонимов могут рассматриваться как первый компонент каталога. Каждый узел поддерживает некоторый набор таких таблиц, созданных для каждого пользователя данного узла, что позволяет системе отображать применяемые пользователем синонимы в соответствующие общесистемные имена.

Кроме таблиц синонимов, на каждом узле поддерживаются описанные ниже данные.

  • Запись каталога для каждого объекта, местом создания которого является указанный узел.
  • Запись каталога для каждого объекта, хранимого в настоящее время на данном узле.


Предположим теперь, что пользователь выдал запрос, содержащий ссылку на синоним MSTATS. Сначала система выполнит поиск соответствующего общесистемного имени в соответствующей таблице синонимов (исключительно локальный просмотр). После того как станет известен узел создания (в нашем примере это узел в Лондоне), можно будет опросить каталог узла в Лондоне (здесь мы для общности подразумеваем удаленный просмотр – первое удаленное обращение). Каталог узла из Лондона будет содержать запись для объекта в соответствии с п. 1. Если объект по-прежнему хранится на узле в Лондоне, он будет найден. Однако, если объект перемещен, скажем, на узел в Лос-Анджелесе, запись каталога на узле в Лондоне будет содержать сведения об этом и система должна будет опросить каталог на узле в Лос-Анджелесе (второе удаленное обращение). Каталог на узле в Лос-Анджелесе будет содержать запись для искомого объекта согласно п. 2. Таким образом, для поиска объекта будет выполнено не больше двух удаленных обращений.

Кроме того, если объект вновь потребуется переместить, скажем, на узел в Сан-Франциско, системой будут выполнены описанные ниже действия.

  • Вставка записи в каталог на узле в Сан-Франциско.
  • Удаление записи из каталога на узле в Лос-Анджелесе.
  • Обновление записи каталога на узле в Лондоне, который теперь будет указывать на узел в Сан-Франциско вместо узла в Лос-Анджелесе.


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

examination/rsubd/question15.txt · Последние изменения: 2014/01/15 12:21 (внешнее изменение)