3. Прозрачность выполнения

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

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

• к какому фрагменту следует обратиться;

• какую копию фрагмента использовать, если его данные реплицируются;

• какое из местоположений должно использоваться.

Обработчик распределенных запросов вырабатывает стратегию выполнения, кото­рая является оптимальной с точки зрения некоторой стоимостной функции. Обычно распределенные запросы оцениваются по таким показателям:

• время доступа, включающее физический доступ к данным на диске;

• время работы центрального процессора, затрачиваемое на обработку дан­ных в первичной памяти;

• время, необходимое для передачи данных по сетевым соединениям,

Первые два фактора аналогичны тем, которые учитываются в централизованных системах, Однако в распределенной среде РСУБД необходимо учитывать и затраты на передачу данных, которые во многих случаях среди прочих затрат оказываются доминирующими. Последнее замечание будет особенно справедливо в случае исполь­зования медленных сетевых соединений, характерных для глобальных сетей. Ско­рость передачи данных в таких каналах может составлять лишь несколько килобайт в секунду. В подобных ситуациях при оптимизации можно игнорировать затраты на ввод/вывод и использование ЦП. Однако некоторые сетевые соединения имеют ско­рость передачи данных, сравнимую со скоростью доступа к дискам (например, ло­кальные сетевые соединения). В этом случае при оптимизации должны учитываться все три показателя затрат,

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

Пример обработки распределенного запроса

Рассмотрим упрощенный вариант реляционной схемы приложения DreamНоmе,

включающий следующих три отношения:

Property (Pno, City) 10 000 записей, хранимых в Лондоне

Renter (Rno, Max_Price) 100 000 записей, хранимых в Глазго

Viewing (Pno, Rno) 1 000 000 записей, хранимых в Лондоне

Текст запроса: Получить список объектов недвижимости в Абердине, которые были осмот­рены потенциальными покупателями, согласными приобрести объекты недвижи­мости дороже 200 000 фунтов стерлингов.

SQL-запрос:

FROM property p INNER JOIN

(renter r INNER JOIN viewing v ON r.rno= v.rno)

ON p.pno = v.pno

WHERE p.city = ‘Aberden’ AND r.max_ rent >200000;

Для простоты предположим, что каждый кортеж в отношениях имеет длину, равную 100 символам, что существует только 10 покупателей, согласных приобрести недвижимость по цене больше 200 000 фунтов стерлингов, и что в городе Абердин было проведено 100 000 осмотров объектов недвижимости, Примем также, что время выполнения вычислений несущественно по сравнению с временем передачи данных, а скорость передачи данных по каналам связи составляет 10 000 символов в секунду, причем на каждое отправляемое между двумя сообщениями приходится задержка доступа, равная 1 секунде. Для определения времени передачи данных применялся следующий алгоритм:

Время передачи данных= С₀ + количество бит сообщения/скорость передачи ,

где С₀ - задержка доступа. Это затраты времени на инициацию сообщения.

Стратегия 1. Переслать отношение renter в Лондон и выполнить там обработку запроса:

Время = 14(100 000 * 100/10 000) = 16,7 мин.

Стратегия 2. Переслать отношения Ргорегy и Vieving в Глазго и выполнить там обработку запроса:

Время = 2+[(1 000 000 + 10 000) * 100/10 000] = 28 час.

Стратегия 3. Соединить отношения Ргорегy и Vieving в Лондоне, выбрать кор­тежи для объектов недвижимости, расположенных в Абердине, а затем для каждого из отобранных кортежей проверить в Глазго, установил ли данный клиент значение потолка допустимой стои­мости недвижимости Мах_rent >200 000 фунтов стерлингов. Про­верка каждого кортежа предполагает отправку двух сообщений: запроса и ответа.

Время = 100 000 * (1-100/10 000) + 100 000 * 1 = 2.3 дня.

Стратегия 4. Выбрать в Глазго кортежи клиентов, установивших значение Мах_rent > 200 000 фунтов стерлингов, после чего для каждого из них проверить в Лондоне, осматривал ли этот клиент объекты не­движимости в Абердине. И в этом случае каждая проверка вклю­чает отправку двух сообщений.

Время = 10*(1-100/10 000) - 10* 1 = 20 сек.

Стратегия 5. Соединить отношения Ргорегtу и Vieving в Лондоне, выбрать сведе­ния об осмотрах объектов в Абердине, выполнить проекцию ре­зультирующей таблицы по атрибутам Pno и Rno, после чего пере­слать полученный результат в Глазго для отбора кортежей по ус­ловию Мaх_rent > 200 000 фунтов стерлингов. Для упрощения предположим, что длина кортежа после операции проекции также равна 100 символам.

Время = 1 + (100 000 * 100/10 000)= 16.7 мин.

Стратегия 6. Выбрать клиентов со значением атрибута Мах_rent > 200 000 фун­тов стерлингов в Глазго и переслать результирующую таблицу в Лондон для отбора сведений об осмотрах объектов недвижимости в

г. Абердин:

Время - 1 + (10 * 100/10 000) = 1 сек.

Как можно видеть, время ответа системы изменяется в диапазоне от 1 секунды до 2.3 дней, хотя каждая из предложенных стратегий является вполне кор­ректной и позволяет получить ответ на данный запрос! Вполне очевидно, что, если для выполнения запроса будет выбрана неподходящая стратегия, это может оказать крайне негативное влияние на уровень производительности системы.