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

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

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

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

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

9. Аппаратная независимость

По этому вопросу фактически нечего сказать - заголовок раздела говорит сам за себя. Парк вычислительных мащин современных организаций обычно включает множество разных компьютеров - машины IBM, машины ICL, машины HP, персональные компьютеры, различного рода рабочие станции и т.д. Поэтому действительно существует необходимость интегрировать данные всех этих систем и предоставить пользователю образ единой системы . Следовательно, желательно иметь возможность запускать одну и ту же СУБД на различных аппаратных платформах и, более того, добиться, чтобы различные машины участвовали в работе распределенной системы как равноправные партнеры.

10. Независимость от операционной системы

Достижение этой цели частично зависит от достижения предыдущей и также не требует дополнительного обсуждения. Очевидно, что необходима не только возможность функционирования одной и той же СУБД на различных аппаратных платформах, но и возможность ее

функционирования под различными операционными системами для многих платформ - включая различные операционные системы на одном и том же оборудовании (например, чтобы версия СУБД для операционной системы MVS, версия для UNIX и версия для Windows NT могли совместно использоваться в одной и той же распределенной системе).

11. Независимость от сети

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

12. Независимость от типа СУБД

в этом разделе мы рассмотрим, с чем приходится сталкиваться при отказе от требования строгой однородности системы. Необходимость такого сильного ограничения вызывает сомнения. Действительно, все, что необходимо, - так это то, чтобы экземпляры СУБД на различных узлах все вместе поддерживали один и тот же интерфейс, и совсем необязательно, чтобы это были копии одной и той же версии СУБД. Например, СУБД Ingres и Oracle обе поддерживают официальный стандарт языка SQL, а значит, можно добиться, чтобы узел с СУБД Ingres и узел с СУБД Oracle обменивались сообщениями между собой в контексте распределенной системы. Иными словами, распределенные системы вполне могут быть, по крайней мере в некоторой степени, неоднородными.

Поддержка неоднородности весьма заманчива. На практике современное программное обеспечение обычно используется не только на многих различных компьютерах и в среде многих различных операционных систем. Оно довольно часто используется и с различными СУБД, и было бы очень хорошо, если бы различные СУБД можно было каким-то образом включить в распределенную систему. Иными словами, идеальная распределенная система должна обеспечивать независимость от СУБД.

Однако эта тема слишком обширна (и важна на практике), поэтому ниже ей посвящен отдельный раздел (см. раздел 20.6).

20.4. Проблемы распределенных систем

в этом разделе подробно рассматриваются проблемы, которые упоминались в разделе 20.3. Ключевая проблема распределенных систем состоит в том, что коммуникационные сети, по крайней мере сети с большой протяженностью или глобальные сети, пока являются медленными. Обычная глобальная сеть чаще всего имеет среднюю скорость передачи данных от 5 до 10 тысяч байтов в секунду. Обычный же жесткий диск имеет скорость обмена данными около 5-10 миллионов байтов в секунду. (С другой стороны, некоторые локальные сети поддерживают скорость обмена данными того же порядка, что и диски.) Поэтому основная задача распределенных систем - минимизировать использование сетей, т.е. минимизировать количество и объем передаваемых сообщений. Эта задача, в свою очередь, сталкивается с проблемами в нескольких дополнительных областях. Приведем список таких областей, хотя мы и не гарантируем, что он полный.

Обработка запросов

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

Распространение обновлений

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

Управление параллельностью

Обработка запросов

Чтобы решить задачу минимизации использования сети, процесс оптимизации запросов должен быть распределенным, как и процесс выполнения запросов. Иначе говоря, в обшем случае процесс оптимизации будет содержать этап глобальной оптимизации, за которым последуют этапы локальной оптимизации на каждом задействованном узле. Например, предположим, что запрос Q представлен на рассмотрение узлу X, и предположим, что запрос Q включает объединение отношения Ry, в котором сто кортежей на узле Y, с отношением Rz, в котором миллион кортежей на узле Z. Оптимизатор на узле X должен выбрать глобальную стратегию выполнения запроса Q. В данном случае очевидно, что было бы выгоднее переслать отношение Ry на узел Z, а не отношение Rz на узел Y (ну и, конечно же, не оба отношения Ry и Rz на узел X). Затем, после принятия решения о пересылке отношения Ry на узел Z, реальная стратегия выполнения объединения на узле Z будет определяться локальным оптимизатором этого узла.

Приведенная ниже подробная иллюстрация процесса выполнения запроса основана на примере, взятом из [20.13], который, в свою очередь, заимствован из ранней работы Ротни (Rothnie) и Гудмана (Goodman) [20.33].

База данных поставщиков и деталей (упрошенная)

S { Sl, CITY } 10 ООО хранимых кортежей на узле А

Р { Р, COLOR } 100 ООО хранимых кортежей на узле Б

SP { Sl, Р } 1 ООО ООО хранимых кортежей на узле А

Предположим, что каждый хранимый кортеж имеет длину 25 байт (200 бит).

Запрос ( Получить номера лондонских поставщиков красных деталей )

( ( S JOIN SP JOIN Р ) WHERE CITY = London AND

COLOR = COLOR {Red) ) { Sl }

Расчетные количества некоторых промежуточных результатов Количество красных деталей 10 Количество поставок, выполненных поставщиками из Лондона 100 ООО

Предполагаемые параметры линий передачи данных Скорость передачи данных 50 ООО бит/с Задержка доступа 0,1 с

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

( общая задержка доступа ) +

( общий объем данных / скорость передачи данных )

В этом случае она сводится к следующей формуле (время в секундах). ( количество сообщений / 10 ) + (количество битов / 50000 )