Добавил:
ivanov666
Опубликованный материал нарушает ваши авторские права? Сообщите нам.
Вуз:
Предмет:
Файл:Методы и средства интеграции независимых баз данных в распределенных телекоммуникационных сетях. Монография
.pdf
модуля подготовки плана выполнения, трансляторов для различных
диалектов SQL, модуля взаимодействия с СУБД, модуля выполнения
операций, модуля оценки времени выполнения.
Основная задача данной подсистемы — обработка запросов
прикладных программ. Запросы принимает Web-сервис QS и
обрабатывает их посредством процессора запросов. В СИД DISGO
реализовано два процессора запросов: интерпретатор, который
использует метод непосредственного исполнения запросов, и
компилятор запросов, использующий оптимизированный метод
выполнения запросов. Оба типа процессора запросов используют
модуль перевода запроса для преобразования запроса пользователя
во внутренне представление. Это представление включает набор
программ РИ и выражения РА.
Модуль перевода запросов осуществляет требуемое
преобразование в несколько этапов. Для построения синтаксического
дерева запроса (СДЗ) используется синтаксический анализатор.
Затем по СДЗ с помощью специального модуля строится граф MCIG.
На основе построенного графа MCIG модуль перевода запроса строит
выражение РА и программы РИ, которые необходимо выполнить для
получения ответа на запрос. Полученное выражение передается
оптимизатору запросов, результат работы которого передается
процессору запросов.
Действия процессора запросов зависят от его типа. При этом
основное отличие интерпретатора запросов от компилятора [54] во
взаимодействии этих процессоров с остальными модулями состоит в
следующем. Интерпретатор в процессе своей работы непосредственно
обращается к вспомогательным модулям более низкого уровня.
Компилятор же использует модуль подготовки плана выполнения
запроса (ПВЗ) для генерации ПВЗ (при этом модуль подготовки ПВЗ
обращается к вспомогательным модулям более низкого уровня), а
затем вызывает модуль выполнения элементарных операций для
исполнения данного плана.
121
Модуль подготовки ПВЗ использует специальный модуль для
оценки времени выполнения запроса и на его основе корректирует
план выполнения. Модуль оценки времени выполнения выполняет
оценку времени выполнения на основе статистических данных,
хранимых в центральной БД и операций, выполняемых в запросе.
Модуль выполнения операций использует набор
специализированных трансляторов для перевода запроса в
различные диалекты SQL, а затем посредством модуля
взаимодействия с СУБД получает требуемую информацию из ИД или
выполняет запрос непосредственно в центральной СУБД.
Основная задача подсистемы сбора статистики —
периодический сбор сведений о подсоединенных к СИД ИД. Данная
подсистема состоит из модуля получения статистики и
специализированных модулей сбора статистики. Модуль получения
статистики периодически запускается средствами операционной
системы и опрашивает ИД посредством модулей сбора статистики, а
затем сохраняет полученные в процессе опроса сведения в
центральной БД посредством обращения к подсистеме доступа к
метаданным. Для каждого типа ИД, поддерживаемого системой,
существует свой модуль сбора статистики, построенный на основе
базового модуля сбора статистики. Базовый модуль сбора статистики
определяет основные методы, которые допускают общую реализацию
для всех модулей сбора статистики и предоставляет для
специализированных модулей средства, с помощью которых они
могут влиять на его поведение.
Подсистема управления состоит из утилит управления, модуля
управления и Web-сервиса подсистемы управления MS (Management
Server). Утилиты управления позволяют администраторам СИД и
администраторам ИД просматривать и изменять метаданные,
используемые СИД (например, список подсоединенных ИД,
отображения предикатов глобальной схемы на запросы в
122
подсоединенных ИД и т.д.). Утилиты управления взаимодействуют с
метаданными посредством модуля управления.
Подсистема доступа к метаданным состоит из модуля доступа к
метаданным и модуля изменения метаданных. Основная задача
данной подсистемы — обеспечение другим подсистемам средств для
доступа к метаданным (в том числе и глобальной схеме) СИД.
Часть из описанных модулей, для которых целесообразно
наличие нескольких альтернативных реализаций, состав которых
может расширяться в процессе эксплуатации системы (например, для
предоставления доступа к новым типам ИД), подгружаются системой
во время работы. Это обеспечивает расширяемость СИД. К подобным
модулям относятся процессор запросов, модули доступа к
метаданным, модули изменения метаданных, трансляторы для
разных диалектов SQL и модули сбора статистики.
С точки зрения администратора СИД DISGO состоит из
следующих компонент: основной программный комплекс,
представленный в виде web-сервисов, работающих под управлением
сервера приложений, утилиты командной строки, осуществляющие
управление системой (утилиты управления), и программа сбора
статистики, запускаемая по расписанию системным планировщиком
заданий.
4.1.2. Схема взаимодействия прикладных программ с
СИД DISGO
Программный интерфейс взаимодействия с СИД DISGO
выполнен в виде Web-сервиса, что позволяет автоматически
генерировать код, реализующий взаимодействие с СИД, практически
на любом языке программирования (Java, C, C++, Perl и др.). Схема
взаимодействия с этим Web-сервисом показана на рис. 4.2. При
работе с СИД программа вначале обращается к функции
executeQuery(), во время выполнения которой СИД DISGO формирует
в центральной СУБД ответ на запрос пользователя. Затем, при
123
успешной обработке запроса, программа может использовать
функции fetchNext() и fetchNextBatch() для извлечения результата по
одной записи или блоками по несколько записей. Каждая запись
представляет собой массив объектов VarBinding. Объекты VarBinding
используются для хранения привязок переменной. Они содержат имя
переменной, информацию о ее типе и значение. Функция
executeQuery() возвращает код, который позволяет определить,
произошла ли ошибка при выполнении запроса и опросила ли
система все доступные ИД при формировании ответа на запрос.
Функция cleanUp() опционально может использоваться прикладной
программой для освобождения временных ресурсов, используемых
при обработке запроса.
Рис. 4.2. Схема взаимодействия прикладного ПО с СИД DISGO
Стоит отметить, что предполагаемая область использования
СИД DISGO подразумевает сравнительно небольшой размер ответов
СИД (порядка нескольких тысяч наборов значений переменных),
поэтому накладными расходами на генерацию и передачу XML по
сети (по сравнению с бинарными данными) в типичных сценариях
взаимодействия с СИД можно пренебречь. В случаях передачи по
сети ответов большого объема возможно использование стандартных
механизмов сжатия ответов сервера приложений.
124
4.2. Экспериментальный анализ производительности
работы СИД DISGO, реализующей предложенные алгоритмы
и методы
В настоящем параграфе проводится экспериментальный
анализ средств, реализующих разработанные алгоритмы и методы.
Проводится сравнение эффективности работы этих средств с
техническим решением, основанным на применении широко
известного коммерческого ПО – СУБД Oracle.
4.2.1. Анализ производительности СИД DISGO в
локальной сети
Для проведения оценки различных параметров
производительности разработанной прототипной версии СИД DISGO
нами было произведено развертывание тестовой конфигурации этой
системы. Основной целью тестирования являлось сравнение
производительности тестируемой конфигурации с аналогичной
конфигурацией, построенной средствами СУБД Oracle 11g R2. В
данной серии экспериментов развертывание обоих систем
проводилась в рамках локальной сети. Тестирование проводилось
при доступности всех ИД, так как недоступность ИД в локальной
сети - достаточно нетипичная ситуация.
При развертывании системы для тестирования параметров ее
производительности использовался следующий «модельный»
сценарий. Необходимо было объединить сведения о публикациях
сотрудников различных подразделений университета. Информация
об этих публикациях доступна из трех БД с данными о сотрудниках
различных подразделений университета, работающих под
управлением СУБД PostgreSQL 8.3, 8.4, и Oracle 10g R2 на узлах
MATH, IPOC и HQ соответственно и из БД издательства, работающей
под управлением СУБД Oracle XE на узле LP. Описания схем
указанных ИД приведены в Приложении.
125
Заполнение тестовых БД данными выполнялось случайным
образом с учетом следующих соотношений. Полагалось, что в
университете содержится от 7 до 20 подразделений. Каждое
подразделение верхнего уровня имеет от 10 до 20 подразделений
нижнего уровня, в которых числится от 4 до 30 сотрудников. Каждый
четвертый сотрудник мехмата имеет степень: является кандидатом
наук или с вероятностью 1/7 - доктором наук. Доктора наук занимают
должности профессоров и главных научных сотрудников, каждый
четвертый кандидат наук имеет должность ведущего научного
сотрудника, остальные кандидаты наук занимают должности
доцента, старшего преподавателя, старшего научного сотрудника,
прочие сотрудники занимают должности младших научных
сотрудников. Предполагается, что кандидат наук имеет от 10 до 20
публикаций, доктор — от 20 до 40. Каждая третья статья в
университетских БД имеет лишь одного автора. В каждом журнале
насчитывается от 20 до 30 статей. Длина статьи составляет от 5 до 20
страниц. Каждая статья в журнале имеет от одного до 4 авторов.
Всего имеется от 1 до 20 журналов по каждому направлению. Число
направлений равно числу подразделений университета верхнего
уровня. В БД издательства содержится информация о некотором
количестве журналов от 5 до 20.
После генерации БД узла MATH содержала сведения о 10
кафедрах, 182 сотрудниках, 1575 статьях; БД узла IPOC содержала
сведения о 18 подразделениях, 287 сотрудниках и 2664 статьях, БД
узла HQ содержала сведения о университете, 9 подразделениях
верхнего уровня и 105 подразделениях нижнего уровня, 22439
авторах статей, 16794 статьях. БД узла LP содержала сведения о 7
журналах, 369 авторах, 144 статьях.
В соответствии с выбранным сценарием тестирования
производительности СИД глобальная схема должна содержать
данные о подразделениях, публикациях, авторах и журналах. В
СУБД Oracle для создания глобальной схемы использовались
126
объекты БД database link и представления. Для облегчения создания
глобальной схемы в нее также включались сведения об авторах без
указания их должности, а при создании схемы в СИД DISGO —
также сведения о званиях авторов публикаций.
Глобальная схема в СИД DISGO определялась следующим
образом. Описывалось четыре ИД и в пространстве имен publication
предикаты subdepts с аргументами lower, upper, предикат
publications с аргументами title,area,year,journal,publisher,
first_page,last_page, предикат journals с аргументами journal,site,
предикат authors_wo_title с аргументами pub_title,first_name,
last_name, department_name, предикат titles с аргумнтами
name,surname,title, предикат authors с аргументами pub_title,
first_name, last_name, department_name, academic_title. Данные,
соответствующие каждому предикату, получаются как объединение
(UNION) ответов нескольких ИД на запросы к ИД. Кроме того в
глобальную схему включено неявное определение предиката authors
с аргументами pub_title,first_name, last_name, department_name,
academic_title (подробности см. в Приложении). Определение
глобальной схемы в СУБД Oracle осуществлялось путем создания
аналогичных представлений (view).
В ходе проведения тестирования выполнялось два набора
тестов. Первый набор запросов включал в себя в основном запросы на
соединение различных таблиц и рекурсивные запросы. На рис. 4.3-
4.6 показаны шаблоны запросов на DISGO QL, использовавшихся в
данном тестовом наборе. Первый запрос выбирает авторов всех
публикаций подразделения DEPT за год YEAR. Значение для
параметров DEPT и YEAR выбираются случайным образом.
Значение параметра DEPT выбирается из существующих
подразделений, год выбирается в промежутке от 1990 до 2010. Второй
запрос выбирает авторов всех публикаций подразделения DEPT за
год YEAR с учетом всех подразделений нижнего уровня. Третий
запрос выбирает название и сайты журналов, в которых
127
публиковались статьи подразделения DEPT в году YEAR. Последний
запрос выбирает авторов и название статей, опубликованных
университетом с FROM по YEAR годы. На рис. 4.7 показаны
шаблоны аналогичных запросов на языке SQL, использовавшихся
при тестировании СУБД Oracle.
Preamble {
publications="http://www.sfedu.ru/~alp/ontologies/publications#";
must ?f,?l;
} publications:authors{pub_title,first_name,last_name,department_name,
academic_title}
(?p,?f,?l,:DEPT,?title),publications:publications(?p,?a,:YEAR,?j,?pub,?f_p,?l_p)
Рис. 4.3 Запрос, выбирающий авторов публикаций подразделения за
определенный год
Preamble { publications="http://www.sfedu.ru/~alp/ontologies/publications#";
must ?f,?l;
runtime:my_subdept(?x):-publications:subdepts(?x,:DEPT);
runtime:my_subdept(?y):-publications:subdepts(?x,?y),?y=:DEPT;
runtime:my_subdept(?x):-publications:subdepts(?x,?z),runtime:my_subdept(?z);
} publications:authors{pub_title,first_name,last_name,department_name,
academic_title}
(?p,?f,?l,?s,?title),publications:publications(?p,?a,:YEAR,?j,?pub,?f_p,?l_p),
runtime:my_subdept(?s)
Рис. 4.4 Запрос, выбирающий авторов всех публикаций
подразделения за определенный год с учетом подразделений
нижнего уровня
Preamble {
publications="http://www.sfedu.ru/~alp/ontologies/publications#";
must ?j,?site;
runtime:my_subdept(?x):-publications:subdepts(?x,:DEPT);
runtime:my_subdept(?y):-publications:subdepts(?x,?y),?y=:DEPT;
runtime:my_subdept(?x):-publications:subdepts(?x,?z),runtime:my_subdept(?z);
128
} publications:authors{pub_title,first_name, last_name, department_name,
academic_title}
(?p,?f,?l,?s,?title),
publications:publications(?p,?a,:YEAR,?j,?pub,?f_p,?l_p),
runtime:my_subdept(?s), publications:journals(?j,?site)
Рис. 4.5. Запрос, выбирающий названия и сайты журналов, в
которых публиковались статьи подразделения за определенный год
Preamble {
publications="http://www.sfedu.ru/~alp/ontologies/publications#";
must ?p,?f,?l;
}publications:authors{pub_title,first_name, last_name,department_name,
academic_title}(?p,?f,?l,?dept,?title),publications:publications(?p,?a,?y,?j,?pub,?f_p,
?l_p),?y>=:FROM,?y<=:TO
Рис. 4.6 Запрос, выбирающий авторов и название статей,
опубликованных университетом за определенный промежуток
времени
select distinct a.first_name,a.last_name from authors a, publications p
where a.pub_title=p.title and p.year=:YEAR and a.department_name=:DEPT;
select distinct a.first_name,a.last_name from authors a, publications p
where a.pub_title=p.title and p.year=:YEAR and a.department_name in ((
select lower from subdepts start with upper=:DEPT
connect by prior upper=lower
union
select :DEPT from dual))
select distinct j.journal,j.site from journals j, publications p,authors a
where p.journal=j.journal and a.pub_title=p.title and p.year=:YEAR and
a.department_name in ((
select lower from subdepts start with upper=:DEPT
connect by prior upper=lower
union select :DEPT from dual))
129
select distinct p.title,a.first_name,a.last_name from authors a, publications p
where a.pub_title=p.title and p.year between :FROM and :TO
Рис. 4.7 Шаблоны запросов на языке SQL, используемые при
тестировании СУБД Oracle
Отметим, что данные запросы содержат рекурсивные
подзапросы к представлениям, построенным над запросами к
подсоединенными ИД. В ходе тестирования выяснилось, что СУБД
Oracle не поддерживает обработку рекурсивных запросов
непосредственно к ИД, подсоединенным к системе посредством
ODBC.
Во время проведения тестирования не использовались
переменные связывания, подстановка переменных в шаблоны
запросов происходила на стороне клиентского приложения. Это
обусловлено тем, что СИД DISGO не поддерживает кэширование
построенных планов выполнения запросов и переменные
связывания. В случае СУБД Oracle использование переменных
связываний в наших тестах, если и увеличивало производительность,
то незначительно, в пределах 5%.
Тестирование производилось при помощи специально
разработанных тестирующих программам, схемы работы которых
являлись идентичными как в случае взаимодействия с СУБД Oracle,
так и в случае взаимодействия с СИД DISGO.
Тестирование проводилось в несколько этапов. Вначале
выполнялось несколько запросов к подсоединенным ИД посредством
СУБД Oracle, чтобы «разогреть» СУБД. Данная процедура позволяла
СУБД подгрузить необходимую информацию словарей в
оперативную память. Затем выполнялось тестирование СУБД Oracle.
После этого выполнялось выполнение нескольких запросов к СИД
DISGO, затем осуществлялось тестирование СИД. Это позволяло
серверу приложений, под управлением которого работала СИД,
загрузить необходимые классы объектно-ориентированной
130
Соседние файлы в предмете [НЕСОРТИРОВАННОЕ]