Ключевая проблема распределенных систем состоит в том, что коммуникационные сети, по крайней мере, сети, которые охватывают большую территорию, или глобальные сети, пока остаются медленными. Поэтому основная задача распределенных систем — минимизировать использование сетей, т. е. минимизировать количество и объем передаваемых сообщений.
Решение этой задачи, в свою очередь, затрудняется из-за проблем в нескольких дополнительных областях. Ниже приведен список таких областей (он не является полным):
‒ обработка запросов;
‒ управление каталогом;
‒ распространение обновлений;
‒ управление восстановлением;
‒ управление параллельностью.
Рассмотрим далее возможные варианты решения данных проблем.
Чтобы решить задачу минимизации использования сети, процесс оптимизации запросов должен быть распределенным, как и процесс выполнения запросов. Иначе говоря, в общем случае процесс оптимизации будет включать этап глобальной оптимизации, за которым последуют этапы локальной оптимизации на каждом участвующем узле. Таким образом, можно будет добиться более быстрой обработки запросов.
В распределенной системе системный каталог включает не только обычные для каталога данные, касающиеся базовых переменных отношения, представлений, ограничений целостности, полномочий и т. д., но также содержит всю необходимую управляющую информацию, которая позволит системе обеспечить независимость от размещения, фрагментации и репликации, то есть такая информация, которая присуща исключительно распределённым системам. Возникает вопрос: «где и каким способом хранить каталог?». Ниже представлены некоторые из возможных способов.
- Централизованное хранение. Единственный общий каталог хранится на отдельном центральном узле.
- Полная репликация. Общий каталог целиком хранится на каждом узле.
- Частичное секционирование. Каждый узел поддерживает собственный каталог для объектов, которые на нем хранятся. Общий каталог представляет собой объединение всех этих непересекающихся локальных каталогов.
- Сочетание подходов 1 и 3. На каждом узле поддерживается свой локальный каталог, как предусмотрено в подходе 3. Кроме того, отдельный центральный узел сопровождает объединенную копию всех этих локальных каталогов, как предусмотрено в подходе 1.
Основная проблема репликации данных заключается в том, что обновление любого заданного логического объекта должно распространяться по всем хранимым копиям этого объекта. Но, если некоторый узел, содержащий копию данного объекта, в момент обновления может оказаться недоступным (в следствии сбоя или отказа сети). Таким образом, очевидная стратегия немедленного распространения обновлений по всем существующим копиям будет неприемлема. Общепринятая схема решения рассматриваемой проблемы состоит в использовании так называемой схемы первичной копии, которая действует описанным ниже образом:
‒ одна копия для каждого реплицируемого объекта устанавливается как первичная копия, а все оставшиеся копии — как вторичные;
‒ первичные копии различных объектов находятся на различных узлах (поэтому данная схема также является распределенной);
‒ операции обновления считаются логически завершенными, как только обновлена первичная копия. Узел, содержащий такую копию, будет отвечать за распространение обновления на вторичные копии в течение некоторого последующего времени.
Управление восстановлением в распределенных системах обычно базируется на протоколе двухфазной фиксации транзакций: недопустима ситуация при которой транзакция, изменяющая данные в нескольких узлах, выполняется в одних узлах и не выполняется в других узлах, транзакция должна быть либо успешно выполнена во всех узлах, либо не выполнена ни в одном узле.
Двухфазная фиксация транзакций требуется в любой среде, где отдельная транзакция может взаимодействовать с несколькими автономными диспетчерами ресурсов. Однако в распределенных системах ее использование приобретает особую важность, поскольку рассматриваемые диспетчеры ресурсов, т. е. локальные СУБД, функционируют на отдельных узлах и поэтому в значительной мере автономны.
Управление параллельным доступом в большинстве распределенных систем строится на использовании механизма блокировки, т. е. точно так, как и в большинстве нераспределенных систем.
Если каждый узел отвечает за блокировку объектов, которые на нем хранятся (как предполагается в соответствии с принципом локальной независимости), то непосредственная реализация будет требовать по крайней мере 5n таких сообщений:
‒ n запросов на блокировку;
‒ n разрешений на блокировку;
‒ n сообщений об обновлении;
‒ n подтверждений;
‒ n запросов на снятие блокировки.
Для решения проблемы обычно выбирается стратегия первичной копии, которая была описана раннее. Для данного объекта А все операции блокировки будет обрабатывать узел, содержащий его первичную копию. При использовании этой стратегии набор всех копий объекта с точки зрения блокировки можно рассматривать как единый объект, а общее количество сообщений будет сокращено с 5n до 2n+3 (один запрос блокировки, одно разрешение блокировки, n обновлений, n подтверждений и один запрос на снятие блокировки).
Литература:
- Дейт К. Дж. Введение в системы баз данных, 8-е издание: Пер. с англ. –М.: Издательский дом «Вильямс», 2005. ‑1328 с.
- Распределённая база данных // Википедия. URL: https://ru.wikipedia.org/wiki/Распределённая_база_данных (дата обращения: 9.04.2017).
