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

Рассмотрим упрощенный вариант реляционной схемы приложения 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 дней, хотя каждая из предложенных стратегий является вполне кор­ректной и позволяет получить ответ на данный запрос! Вполне очевидно, что, если для выполнения запроса будет выбрана неподходящая стратегия, это может оказать крайне негативное влияние на уровень производительности системы.

Дата добавления: 2014-01-20