Добавил:
ivanov666
Опубликованный материал нарушает ваши авторские права? Сообщите нам.
Вуз:
Предмет:
Файл:Методы и средства интеграции независимых баз данных в распределенных телекоммуникационных сетях. Монография
.pdf
оптимизаторы могут оценить общую стоимость выполнения
запроса [34].
1.3.2. Методы обработки и оптимизации запросов в
распределенных СУБД
При обработке запросов в распределенных СУБД (РСУБД)
наиболее ценным ресурсом, как правило, считается пропускная
способность сети, поэтому основной целью оптимизатора является
уменьшение объемов передаваемых между узлами системы
данных.
В работе [35] описываются алгоритмы обработки и
оптимизации запросов, используемый в РСУБД SDD-1. В SDD-1
запрос формулируется на специализированном процедурном
языке, затем переводится в программу реляционного исчисления
(РИ). Вначале дается определение конверта и редюсера.
Обозначим множество атрибутов отношения .
Назовем отношение R' подотношением R, если и
. Назовем БД
подбазой данных
(и обозначим ), если является
подотношением . Конверт состоит из ограничивающих условий q
формы или и целевого списка , где имеет
вид . Конверт отображает БД D в подбазу данных ,
определяемую набором выражений РИ: . Назовем E
конвертом для запроса Q, если для всех БД D .
Редюсером для конверта E называется программа РИ P, такая, что
для всех БД D .
В целом, задача оптимизации запроса в SDD-1 сводится к
построению редюсера P и выбору узла РСУБД , таких что
стоимость вычисления P(D) и переноса результатов на узел
минимальна среди всех возможных узлов и редюсеров. Назовем
21
выгодой одной операции редюсера размер данных, которое она
уничтожает, а стоимостью — размер данных, которые нужно
переслать между узлами для ее выполнения.
Для построения эффективных (имеющих большую выгоду и
малую стоимость) редюсеров прежде всего используются
распространение проекций и условий из конверта в редюсер. Для
дальнейшей оптимизации редюсеров используются операции
SEMIJOIN, которая определяется как
(то есть
как результат операции JOIN, усеченный проекцией до атрибутов
). Преимущества операций SEMIJOIN перед операциями JOIN
заключается в том, что они монотонно сокращают размер БД,
могут быть вычислены с меньшим количеством пересылаемых
данных, поскольку между узлами необходимо пересылать только
данные атрибутов, по которым происходит соединение. Поэтому
выгоду, достигаемую операцией JOIN, можно достичь с меньшей
стоимостью с помощью двух операций SEMIJOIN.
Алгоритм обработки запроса в SDD-1 состоит в следующем:
1. Построить конверт для программы на процедурном языке.
2. Выбрать для данного конверта редюсер и узел для
окончательной обработки данных.
3. Выполнить редюсер на узлах, данные которых
используются в запросе.
4. Переместить результаты выполнения редюсера на узел .
5. Выполнить окончательную обработку программы на
процедурном языке на узле .
В общем виде алгоритм выбора редюсера для заданного
конверта представлен на Рис. 1.2. Здесь под локальными
операциями понимаются операции, которые могут быть
выполнены без пересылок данных (проекции, выборки,
22
соединения в рамках одного узла), а NS(E) — множество
нелокальных операций SEMIJOIN, допустимых E.
Недостатком методов построения классических РСУБД
является недостаточная масштабируемость системы при большом
числе узлов [20] и невозможность автономной работы каждого узла
при недоступности остальных узлов. В [20] описываются
организация и методы обработки запросов в РСУБД Mariposa, в
которой для преодоления этих недостатков использовалась
микроэкономическая парадигма.
Входные данные: конверт E и набор статистик D
Выходные данные: редюсер P и набор команд для перемещения
результатов его работы на узел
P:= набор всех локальных операций, допустимых E
Оценить стоимость и выгоду всех операций из NS(E)
Пока для некоторой нелокальной операции из NS(E) ее выгода >
стоимости
Пусть
Оценить эффект sj и обновить оценки стоимости и выгоды
Конец цикла
Для каждого узла S оценить size(S) — совокупный размер всех
отношений узла, к которым идет обращение в E
Выбрать в качестве узел с максимальным size(S)
Добавить в P команды переноса данных на узел .
sj
— самая выгодная операция из NS(E)
Рис. 1.2. Алгоритм выбора редюсера для заданного конверта
Считается, что все клиенты и серверы в системе Mariposa
имеют счета в банке. Пользователь определяет бюджет на
выполнение запроса. Цель системы обработки запросов — ответить
на запрос в рамках бюджета, обращаясь к различным узлам
системы Mariposa для выполнения подзапросов. Каждый запрос
управляется брокером, который собирает предлагаемые цены за
выполнение частей запроса от различных узлов (сайтов). Узлы
23
распространяют информацию о сервисах (какие данные они имеют
и какие запросы обслуживают), которые они предоставляют.
Каждый узел может продать свои данные и выйти из системы, и
наоборот, новый узел может предложить свои данные или купить
данные у другого узла и войти в систему. За политику
обрабатываемых запросов отвечает специальный компонент —
поставщик, за управление данными — менеджер хранения.
Система Mariposa предлагает специальный язык Rush для
описания логики поведения данных компонентов.
Выполнение запросов в системе Mariposa происходит согласно
следующему алгоритму.
1) Клиентское приложение посылает SQL-запрос и график оплаты
(график имеет две оси — цена и время — и отображает
допустимый клиентом размер оплаты за обработку запроса в
зависимости от времени его обработки).
2) Запрос передается на обработку промежуточному ПО,
состоящему из парсера SQL, оптимизатора, фрагментатора
запроса, брокера и координирующего модуля.
3) Парсер разбирает запрос. Вначале он запрашивает метаданные
для каждой используемой в запросе таблицы от специального
сервера имен. Метаданные содержат информацию о структуре
таблицы и местонахождении частей этой таблицы, а также
индикатор, показывающий насколько устарела данная
информация. Метаданные также имеют свою цену (различные
серверы имен могут предоставлять метаданные разного
качества по разным ценам).
4) Парсер передает запрос, представленный в виде дерева
грамматического разбора оптимизатору, который производит
оптимизацию запроса без учета распределения данных между
различными узлами системы.
24
5) Фрагментатор разбивает план запроса, полученный от
оптимизатора, на части согласно фрагментации таблиц,
используя информацию о расположении данных, полученную
от сервера имен на шаге 2.
6) Брокер принимает множество фрагментированных планов
запроса, предоставляемых фрагментатором, и запрашивает
предлагаемые цены выполнения фрагмента запроса у
различных сайтов. После обработки множества предложений,
брокер решает, какие сайты использовать.
7) Брокер передает управление исполнением запроса
координатору. Координатор собирает полученную от разных
узлов информацию и передает клиентскому приложению.
На каждом сайте системы Mariposa находится локальный
модуль исполнения, включающий модули поставщика, менеджера
хранения и модуля выполнения локальных запросов. Поставщик
отвечает на запросы о ценах и формулирует свои цены и
предлагаемое время исполнения для подзапроса, основываясь на
доступных локальных ресурсах. Менеджер хранения следит за
доходами, которые приносят хранимые фрагменты данных.
Основываясь на соображениях доступного дискового пространства
и доходности, он может продавать или покупать фрагменты
данных.
Брокер, обрабатывающий запрос Q, получает план запроса,
содержащий подзапросы и (бюджет, выделенный на
обработку запроса). Каждый подзапрос — это запрос фрагмента
таблицы или соединение двух фрагментов двух таблиц. При
обработке запроса брокер анализирует различные предложения
узлов по обработке частей запроса. Предложения представлены
тройками . Тройка означает возможность сайта выполнить
подзапрос Qi за цену в течении промежутка времени ,
предложение действует до времени
25
.
Брокер должен выбрать предложение для каждого
подзапроса с общей стоимостью C и общей задержкой D таким
образом, чтобы .
Для сравнения наборов предложения определяется функция
разности для предложения: . Для выбора
предложения в [20] используется эвристический алгоритм. Он
рассматривает решение с минимальной возможной задержкой, а
потом пытается для каждого шага найти замену, которая
максимально уменьшит стоимость решения. Определяется
стоимостный градиент как уменьшение стоимости, достигаемое в
результате замены набора выполняемого шага на текущий
рассматриваемый набор, деленное на увеличение времени, которое
достигается в результате данной подстановки.
В системе Mariposa брокер также учитывает пропускную
способность сети, которая ему потребуется для получения
результатов подзапросов. Брокер посылает сайту назначения
запрос на пропускную способность формы
(Идентификатор_Транзакции, Идентификатор_Запроса,
Размер_Данных, Узел_Источник, Узел_Получатель). В ответ он
получает предложения формы (Идентификатор_Транзакции,
Идентификатор_Запроса, Цена, Время). Для того чтобы
определить цену и время, модуль сетевого поставщика на сайте
назначения производит необходимый взаимный опрос
соответствующих параметров для взаимодействия всех
промежуточных узлов с узлом источником запроса.
Огромное пространство возможностей при поиске решений и
постоянно меняющаяся гетерогенная среда значительно
повышают сложность планирования в большой распределенной
системе. В связи с этим ранние методы построения РСУБД
практически непригодны для построения систем в распределенной
сети. Представленный в [20] микроэкономический подход к
26
описанию распределенной системы позволяет создать фактически
масштабируемую распределенную СУБД. Подобная модель может
быть использована и при проектировании P2P СИД.
1.3.3. Методы борьбы с устаревшей статистикой в
СИД
В распределенных СУБД оптимизатор, как правило, имеет
доступ к статистике, поддерживаемой каждым узлом системы
локально. Однако, при работе с автономными ИД СИД такого
доступа не имеет. Поэтому при обработке запросов оптимизатор
должен поддерживать необходимые ему статистики
самостоятельно.
Существует два основных подхода, используемых для
поддержания статистики в СИД:
1) sampling — периодическое выполнение в подсоединенных
ИД запросов, необходимых для сбора статистики,
2) получение статистики на базе получаемых от ИД ответов в
ходе обработки запросов прикладных программ.
В любом случае, оптимизатору приходится сталкиваться с
отсутствующей и недостоверной (устаревшей) статистикой.
В работе [36] предлагается использовать специальные
элементарные операторы CHECK, которые в ходе выполнения
запроса в федеративной СУБД (т.е. центральной СУБД,
выполняющей функции СИД) сопоставляют ожидаемые
характеристики данных с наблюдаемыми характеристиками
(предлагается сравнивать кардинальность получаемых
промежуточных результатов). При значительном расхождении
выполняется перестроение плана выполнения запроса, причем
ранее полученные результаты рассматриваются оптимизатором
как материализованные представления, и сохраняются
используются до конца обработки запроса, даже если в следующем
27
рассматриваемом плане выполнения они не используются и на их
основе еще не было получено других промежуточных результатов.
Это позволяет использовать данные результаты, если в процессе
дальнейшего перестроения плана запроса они все-таки
понадобятся и в то же время очищать пространство, используемое
СУБД для их временного хранения. При этом в начале
исполнения запроса выполняется полная материализация
независимых результатов операций извлечения данных из
подсоединенных ИД, что позволяет оптимизатору сразу получить
актуальную статистику об используемых в запросе отношениях.
Еще один способ борьбы с устаревшей статистикой
заключается в поддержании нечеткой (fuzzy) статистики [37]. Для
оценок, которые могут быть представлены в виде одного числа
(например, кардинальность отношения) в данной работе
предлагается поддерживать так называемое нечеткие числа.
Нечеткое число на числовой прямой R определяется как нечеткое
множество, характеризующееся функцией принадлежности
. В [37] оценки задаются как симметричные треугольные
нечеткие числа, которые определяются функцией , такой что
при и 0 в противном случае. При
этом w называется шириной нечеткого числа, а m — центром.
При получении нового ожидаемого значения c для какойлибо оценки, необходимо провести обновление соответствующего
ей нечеткого числа. Новый центр m' может полагаться равным c
или получаться как функция, учитывающая старый центр m и с.
Для получения значений новой ширины предлагается
использовать функцию , которая зависит от расстояния d
между новым и старым центром и старой ширины, такую что
ширина новой оценки растет с увеличением расстояния между
центрами, а при совпадении нового и старого центра ширина
28
уменьшается. Примером такой функции может служить
, где .
1.3.4. Методы обработки запросов в Oracle
Heterogeneous Services
Рассмотрим методы обработки запросов, используемых в
средствах интеграции данных, встраиваемых в современные
СУБД, на примере программного продукта Oracle Heterogeneous
Services, доступного в составе СУБД Oracle. Отметим, что все
основные производители коммерческих СУБД предоставляют
подобные средства для своих систем.
СУБД Oracle 11g R2 предоставляет средства Heterogeneous
Connectivity, предназначенные для взаимодействия с
разнотипными ИД. С помощью этих средств к СУБД можно
подключить как реляционные ИД, так и нереляционные ИД
(например, IBM IMS, IBM VSAM, Adabas). При использовании
нереляционных ИД их данные напрямую отображаются на набор
реляционных таблиц (используется упрощенный вариант GAVподхода к созданию отображений между схемами). При
использовании средств Heterogeneous Connectivity СУБД Oracle
может рассматриваться как СИД с выделенным центральным
узлом.
СУБД Oracle взаимодействует с ИД посредством
специальных шлюзов и агентов, которые могут быть установлены
на стороне СУБД, на стороне ИД или на отдельном сервере. При
этом алгоритм взаимодействия с системой выглядит следующим
образом [38]:
1. клиентское приложение посылает запрос СУБД Oracle,
используя протокол Oracle Net;
2. СУБД посылает запрос шлюзу по протоколу Oracle Net;
3. шлюз посылает запрос агенту (Oracle Connect);
29
4. если это первая транзакция в сессии, Oracle Connect
регистрируется в подсоединенном ИД;
5. Oracle Connect преобразует SQL запрос в диалект ЯЗ
подсоединенного ИД (для Adabas, IMS, VSAM — это
специальные операции доступа к данным, для реляционных
СУБД — диалект SQL, используемый этими СУБД);
6. Oracle Connect извлекает данные;
7. Oracle Connect преобразует данные в формат, понятный СУБД
Oracle;
8. Oracle Connect передает данные шлюзу;
9. шлюз возвращает данные СУБД Oracle, используя протокол
Oracle Net;
10. СУБД Oracle передает данные клиентскому приложению,
используя протокол Oracle Net; Database Link при этом
остается открытым до окончания сессии.
В случае обращения к ИД посредством механизмов ODBC
[39] и OLEDB [40] данный алгоритм упрощается [], так как СУБД
выступает также и в роли шлюза запросов:
1. клиентское приложение посылает запрос СУБД Oracle,
используя протокол Oracle Net;
2. компонент СУБД Heterogeneous Services подсоединяется по
протоколу Oracle Net к агенту ODBC или OLE DB;
3. агент взаимодействует с менеджером ODBC драйверов
(специальной библиотекой ОС) и получает доступ к
подсоединенному ИД по ODBC.
Основным методом оптимизации, используемым подобными
средствами, является проталкивание условий и соединений в ИД.
Как правило, подобные решения нацелены на создание
фиксированных конфигураций в пределах локальной сети,
поэтому не предлагают методов обработки недоступности ИД.
30
Соседние файлы в предмете [НЕСОРТИРОВАННОЕ]