Проблемы распределенных систем
Ниже более подробно описываются некоторые уже упомянутые проблемы. Основная проблема информационных сетей, по крайней мере глобальных, заключается в том, что они достаточно медленны. В типичной глобальной сети интенсивность обмена данными равна приблизительно 5 или 10 тыс. байт в секунду, а для обычного жесткого диска интенсивность обмена данными - около 5 или 10.млн байт в секунду. (С другой стороны, в локальных вычислительных сетях уже может поддерживаться скорость обмена данными, сравнимая с интенсивностью обмена на жестких дисках.) Вследствие этого основным требованием к распределенным системам является минимизация использования сети, т.е. сокращение до минимума количества и объема пересылаемых в сети сообщений.
Стремление к достижению-этой цели приводит, в свою очередь, к необходимости решения перечисленных ниже проблем:
• Обработка запросов.
• Управление каталогом.
• Распространение обновления.
• Управление восстановлением.
• Управление параллелизмом.
Обработка запросов
При минимизации использования сети предполагается, что сама по себе оптимизация запроса, как и его исполнение, должна быть распределенной. Иначе говоря, общий процесс оптимизации обычно состоит из этапа глобальной оптимизации, который сопровождается несколькими этапами локальной оптимизации.
Например, допустим, что запрос Q задан на узле X и включает объединение отношения Rу, содержащего сто кортежей (строки таблицы) на узле Y, и отношения Rz, содержащего миллион кортежей на узле Z. Оптимизатор на узле X выберет глобальную стратегию для выполнения запроса Q, при этом, очевидно, лучше переместить отношение Ry на узел Z, а не отношение Rz на узел Y (и конечно же, не следует перемещать оба отношения Ry и Rz на узел X. Тогда сразу после перемещения отношения Ry на узел Z стратегия выполнения объединения на узле Z будет выбрана локальным оптимизатором на узле Z.
Управление каталогом
Каталог распределенной системы содержит не только обычные данные, касающиеся базовых отношений, представлений, индексов, пользователей и т.д., но также и всю информацию, необходимую для обеспечения независимости размещения, фрагментации и репликации. В таком случае возникает вопрос: где и как следует хранить системный каталог? Ниже перечислены некоторые варианты хранения системного каталога.
1. Централизованный каталог. Весь каталог хранится в одном месте, т.е. на центральном узле.
2. Полностью реплицированный каталог. Весь каталог полностью хранится на каждом узле.
3. Секционированный каталог. На каждом узле содержится его собственный каталог для объектов, хранимых на этом узле. Общий каталог является объединением всех разъединенных локальных каталогов.
4. Комбинация первого и третьего вариантов. На каждом узле хранится собственный локальный каталог (как в п. 3), кроме того, на одном центральном узле хранится унифицированная копия всех этих локальных каталогов (как в п. 1).
Для каждого подхода характерны определенные недостатки и проблемы. В первом подходе, очевидно, не достигается "независимость от центрального узла". Во втором утрачивается автономность функционирования, поскольку при обновлении каждого каталога это обновление придется распространить на каждый узел. В третьем выполнение нелокальных операций становится весьма дорогостоящим (для поиска удаленного объекта потребуется в среднем осуществить доступ к половине имеющихся узлов). Четвертый подход более эффективен, чем третий (для поиска удаленного объекта потребуется осуществить доступ только к одному удаленному каталогу), но в нем снова не достигается "независимость от центрального узла".
Распространение обновления
Как указывалось выше, основной проблемой репликации данных является то, что обновление любого логического объекта должно распространяться на все хранимые копии этого объекта. Трудности возникают из-за того, что некоторый узел, содержащий данный объект, может быть недоступен (например, из-за краха системы или данного узла) именно в момент обновления. В таком случае очевидная стратегия немедленного распространения обновлений на все копии может оказаться неприемлемой, поскольку предполагается, что обновление (а значит, и исполнение транзакции) будет провалено, если одна из этих копий будет недоступна в текущий момент. В некотором смысле, при использовании такой стратегии данные действительно будут менее доступны, чем при их использовании в нереплицированном виде.
Общая схема устранения этой проблемы (и не единственно возможная в этом случае), называемая схемой первичной копии, описана ниже.
• Одна копия каждого реплицируемого объекта называется первичной копией, а все остальные - вторичными.
• Первичные копии различных объектов находятся на различных узлах (таким образом, эта схема является распределенной).
• Операции обновления считаются завершенными, если обновлены все первичные копии. В таком случае в некоторый момент времени узел, содержащий такую копию, несет ответственность за распространение операции обновления на вторичные копии.