Добавил:
ivanov666
Опубликованный материал нарушает ваши авторские права? Сообщите нам.
Вуз:
Предмет:
Файл:Методы и средства интеграции независимых баз данных в распределенных телекоммуникационных сетях. Монография
.pdf
оценки, является оценка размеров отношения при выборке
определенных атрибутов и некотором условии cond. Считается, что
при проекции атрибутов отношения R размер результата
составит . Обычно условие cond будет
представляться в виде конъюнкции условий на атрибуты отношения
R. Условия на различные атрибуты отношения считаются
независимыми. Наиболее типично сравнение атрибутов отношения с
константами (например, a<c, где a - атрибут, c - константа), при этом
считается, что значения атрибута распределены независимо, в этом
случае можно легко оценить часть отношения, которая удовлетворяет
условию (в нашем случае, при условии, что c принадлежит отрезку
[min(a),max(a)], это будет (с-min(a))/(max(a)-min(a))). Точная оценка
размера выбираемой части отношения при наличии условий на
несколько атрибутов обычно невозможна без более детальных
статистик.
Стоит отметить, что при оценках объема извлекаемой
информации используются достаточно сильные предположение
независимости и равномерного распределения атрибутов отношения.
В обычных СУБД для учета распределения атрибутов могут
использоваться гистограммы, а для учета зависимостей —
многомерные гистограммы [34]. Однако, на практике поддержание
многомерных гистограмм для каждой пары атрибутов требует много
дискового пространства. При этом в интегрированных системах
встают вопросы сопровождения гистограмм. Использование нечеткой
(fuzzy) статистики [37] хотя и облегчает сопровождение статистик, не
обеспечивает учета корреляции различных атрибутов отношения,
при этом усложняется выполнение оценок. После проведенного
анализа было принято решение, что затраты на поддержание более
подробной статистики для отношений не адекватны выгоде от
использования более точной статистики при задаче интеграции
большого количества небольших ИД.
111
Считается, что статистика собирается по расписанию.
Большинство показателей статистики целесообразно собирать ночью,
в момент наименьшей загрузки систем. Сбор статистики обычно
производит значительную нагрузку на ИД при большом объеме
данных, предоставляемых СИД этим ИД. Участие в СИД для
большинства ИД является дополнительной нагрузкой, и они обычно
имеют постоянную основную нагрузку (непосредственная работа
основных пользовательских приложений с СУБД). Следовательно,
чтобы минимально влиять на работу систем, подсоединенных к СИД,
необходимо собирать достаточно постоянные сведения об ИД в
момент его минимальной загрузки. Например, количество строк в
таблицах, их размер, распределение значений атрибутов для
большинства ИД будет достаточно постоянным. С другой стороны,
динамически меняющиеся показатели желательно обновлять
достаточно часто. Например, пропускную способность каналов можно
оценивать раз в час. Так как сбор всей статистики производит
большую нагрузку на ИД, для облегчения процесса сбора
предлагается ввести настройки степени подробности статистики для
каждого ИД. Данные настройки определяют, будет ли собираться
статистика об отношениях ИД и их атрибутах.
Задержка доступа к ИД измеряется как время, необходимое для
подключения к этому ИД. Если к ИД не удалось подключиться, он
помечается как недоступный.
При измерении пропускной способности канала и размеров
отношения необходимо учитывать, что СУБД (выступающие в роли
ИД) не могут дать достоверной информации о реальных размерах
данных. Это связано с тем, что СУБД не известно, каким образом
будут передаваться по сети данные, которые она отдает клиентскому
приложению. СУБД Oracle предоставляет доступ к представлению
V$MYSTAT, которое клиентское приложение может использовать для
оценки объемов данных, которые СУБД передала сетевой
библиотеке. Однако, данная информация не учитывает накладных
112
расходов при передаче информации. В СУБД PostgreSQL подобные
средства вовсе отсутствуют. Следует также учитывать, что
практически невозможно более или менее точно оценить размер
информации, хранящейся в таблице БД, без проведения тестовой
выборки. При этом выборка должна быть достаточно случайной,
чтобы на ее основе можно было приблизительно оценивать реальные
объемы данных. С другой стороны, проведение полностью случайной
выборки из большой таблицы достаточно затратная операция,
вследствие чего для сбора статистики предпочтительно использовать
выборку из случайной части таблицы. Однако, при использовании
секционированных таблиц подобный подход может привести к
заметным ошибкам.
В прототипе СИД DISGO в связи с отсутствием в СУБД
PostgreSQL средств учета трафика клиентского приложения данные
средства были реализованы на стороне клиента путем модификации
существующего JDBC драйвера PostgreSQL. Подсчет трафика в
JDBC драйвере позволяет подсчитывать объем данных,
непосредственно переданных через TCP-сокет, чем значительно
повышается точность измерения объемов переданной информации.
Стоит отметить, что ошибка измерения, связанная с тем, что в ходе
измерения происходит выборка лишь небольшой части таблицы, все
равно остается.
Для исправления ошибок, возникающих при сборе статистики в
ходе тестовых выборок, предлагается ввести корректирующий
коэффициент NetOverhead (который определяет накладные расходы
по передаче данных по сети). Коэффициенты для различных ИД
подбираются исходя из размера выборки, размеров результатов
тестовых запросов и характеристик канала доступа к ИД. В ходе
данной работы были проведены тестовые замеры для определения
типичных значений данного коэффициента. В целом значение
коэффициента NetOverhead варьируется от 0.07 до 0.20 (реальный
размер переданных по сети данных в NetOverhead+1 раз больше
113
наблюдаемого на стороне СУБД). Для определения реального
Версия
Количество
Характеристики
Реальный
Часть
извлекаемых
Погрешность
Oracle
50000
loopback, MTU
3135326
1 0,08
Oracle
100000
loopback, MTU
6314269
1 0,08
Oracle
150000
loopback, MTU
9510487
1 0,07
Oracle
50000
wi-fi 802.11g, MTU
3055168
1
0,12
Oracle
50000
wi-fi 802.11g , MTU
3055168
0,01
0,19
размера переданных по сети данных использовался анализатор
трафика WireShark [52]. В качестве тестовых данных использовалась
таблица с характеристиками, близкими к характеристикам реальных
данных. Данная таблица генерируется на основе словарей СУБД и
часто используется при тестрировании СУБД Oracle [53]. Часть
результатов замера коэффициента NetOverhead для СУБД Oracle
приведена в табл. 3.2. Как видно из таблицы, для большинства ИД
значение коэффициента NetOverhead можно брать от 0,12 до 0,17.
Для ИД, представленных СУБД PostgreSQL, значение данного
коэффициента ниже, но тоже достигает 0,1.
Результаты измерений коэффициента NetOverhead
СУБД
11gR1
11gR1
строк
таблицы
сети
16436
размер
переданных
данных,
байт
16436
Таблица 3.2.
данных
11gR1
11gR2
11gR2
16436
1500
1500
114
Oracle
11gR2
50000
wi-fi 802.11g , MTU
3055168
0,1 0,14
Oracle
100000
wi-fi 802.11g , MTU
6133988
1 0,12
Oracle
100000
wi-fi 802.11g , MTU
6133988
0,01
0,19
Oracle
100000
wi-fi 802.11g , MTU
6133988
0,1 0,14
Oracle
100000
wi-fi 802.11g , MTU
6133988
0,05
0,17
Oracle
150000
wi-fi 802.11g , MTU
9263394
1
0,12
Oracle
150000
wi-fi 802.11g , MTU
9263394
0,01
0,2
Oracle
150000
wi-fi 802.11g , MTU
9263394
0,01
0,15
Oracle
150000
wi-fi 802.11g , MTU
9263394
0,05
0,15
1500
11gR2
11gR2
11gR2
11gR2
11gR2
1500
1500
1500
1500
1500
11gR2
11gR2
11gR2
1500
1500
1500
Для получения статистических данных был разработан и
реализован программно алгоритм сбора статистики для СУБД
PostgreSQL и Oracle. Процедура сбора статистики использует
индивидуальный модуль сборки статистики для каждого типа ИД
(Oracle или PostgreSQL). Для каждого ИД указывается необходимый
уровень статистики. В зависимости от него собирается только общая
статистика ИД, общая статистика ИД и статистика отношения
(size(R), count(R)), или еще дополнительно расширенная статистика
115
по аргументам отношения (max(a),min(a),numdist(a)). Процедуры
сохранения собранной статистики используют коэффициент
устаревания статистики StatCoef. Данный коэффициент
выставляется администратором СИД индивидуально для каждого
ИД и по умолчанию равен нулю, но может быть установлен в
отличное от нуля значение, чтобы система сохраняла информацию о
старых значениях статистик (тогда новые статистики L(DS), V(DS),
count(R), size(R), numdist(a) выставляются равными
StatCoef*OldValue+(1-StatCoef)*NewValue). Использование данного
коэффициента позволяет сглаживать пики статистики,
нехарактерные для ИД.
3.5. Корректность предложенных алгоритмов
Ответ на запрос, сформулированный на расширении языка
Datalog DISGO QL, полученный согласно предложенным алгоритмам
в условиях недоступности части ИД, всегда является уверенным и
максимально приближен к каноническому ответу.
Доказательство. Рассмотрим вначале случай доступности всех
ИД. Рассмотренные алгоритмы для выполнения запроса строят
выражения РА и РИ, которые соответствуют последовательному
обходу графа CIG, и следовательно, аналогичны последовательному
исполнению запроса, то есть исполнение данных программ приводит
к получению канонического ответа на запрос.
Рассмотрим случай недоступности отдельных ИД.
Используемая версия Datalog не поддерживает явного отрицания, а
все запросы отображаются на следующие операции РА: проекция
(PROJECT), выборка (WHERE), добавление (ADD), переименование
атрибутов (RENAME), соединение (JOIN), объединение (UNION).
Недоступность какого-либо ИД может привести:
1) к уменьшению размера отношения, соответствующего
какому-либо предикату;
116
2) к прекращению выполнения группы операций, содержащей
обращение к этому ИД;
3) к прекращению выполнения зависимых ГО.
В любом случае размер ответа по сравнению с каноническим
ответом уменьшается. То есть получаемый ответ — уверенный. То,
что это наиболее полный ответ следует из того, что при прекращении
выполнения ГО в качестве используемых в дальнейшем отношений,
создаваемых в центральной БД, выступают пустые таблицы. Данные
отношения по любому получились бы пустыми, так как сбой
выполнения ГО означает недоступность ни одного пути определения
какого-либо предиката, то есть фактическое отсутствие доступа к
необходимым данным (что не зависит от стратегии выполнения
запроса).
3.6. Резюме по разработанным методам выполнения
запросов к СИД
Таким образом, в настоящей главе получены следующие
результаты, обладающие новизной по сравнению с известными
методами выполнения запросов к СИД.
Предложенные алгоритмы компиляции программ на Datalogподобном языке запросов в выражения реляционной алгебры и
программы реляционного исчисления обеспечивают расширение
класса компилируемых запросов по сравнению с известными
аналогами за счет применения модифицированной процедуры
унификации предикатов, генерирующей дополнительное множество
условий на равенство аргументов унифицируемых предикатов.
Предложенные алгоритмы непосредственного выполнения
программ, представленных на Datalog-подобном языке запросов,
отличаются от существующих использованием специальной
хранимой процедуры СУБД и позволяют обрабатывать рекурсивные
запросы.
Для дополнительного сокращения времени выполнения
запроса, выраженного на языке реляционной алгебры, к
117
совокупности реляционных источников данных разработан
специальный алгоритм. Он основан на применении правил,
позволяющих выполнять анализ условий, существующих в запросе, и
передавать эти условия в запросы к источникам данных. Алгоритм
отличается от существующих аналогов процедурой обхода дерева
операций, используемого для представления запроса.
Для сбора необходимых для оптимизации плана выполнения
запросов статистических сведений о подсоединенных к системе
интеграции данных ИД предлагаются модифицированные
алгоритмы сбора статистики. Основным их отличием от
существующих является использование корректирующих
коэффициентов для учета ошибок, вносимых при сборе.
И, наконец, предложены метод и реализующий его алгоритм
обработки запроса, обеспечивающий получение в условиях
недоступности части источников данных уверенного и максимально
приближенного к каноническому ответу ответа на запрос,
сформулированный на расширении языка Datalog DISGO QL.
118
4. РЕАЛИЗАЦИЯ МЕТОДОВ И СРЕДСТВ ИНТЕГРАЦИИ
ДАННЫХ В РАСПРЕДЕЛЕННОЙ СЕТИ
В настоящей главе рассматривается реализация предложенных
методов и алгоритмов в разработанной авторами прототипной версии
системы интеграции данных DISGO. По результатам реализации
проводится сопоставление эффективности работы СИД DISGO в
локальной и распределенной сети с широко известным
существующим коммерческим решением — средствами интеграции
данных, предоставляемыми СУБД Oracle.
4.1. Общее описание СИД DISGO
4.1.1. Архитектура СИД DISGO
При разработке прототипной версии СИД DISGO использованы
использован вполне определенный набор средств программирования,
возможно наложивший тот или иной отпечаток на принятые
технические решения. Поэтому представляется целесообразным
перед рассмотрением этих решений перечислить основные из
используемых при разработке СИД DISGO средств. В качестве языка
реализации этой СИД выбран языке программирования Java. В
прототипной реализации СИД DISGO в качестве центральной СУБД
допускается использование СУБД Oracle, в качестве ИД – СУБД
PostgreSQL и Oracle.
С точки зрения внутренней структурной организации
(архитектуры) СИД DISGO состоит из четырех подсистем:
подсистемы обработки запросов пользователя, подсистемы сбора
статистики, подсистемы управления и подсистемы доступа к
метаданным, в свою очередь имеющих внутреннюю модульную
структуру. При этом, для модулей, допускающих различную
реализацию, используется слабое связывание модулей, и подобные
модули могут динамически подгружаться во время работы СИД.
119
Общая структура системы приведена на рис. 4.1.
Взаимодействие между модулями системы отмечено на рисунке
тонкими стрелками, взаимодействие с пользователями — толстыми
закрашенными стрелками, обращение к данным — толстыми не
закрашенными стрелками. Модули подсистемы обработки запросов
выделены двойной рамкой, подсистемы сбора статистики — темносерым цветом, модули подсистемы управления — белым, модули
подсистемы доступа к метаданным — светло-серым цветом. ИД и
центральная БД представлены овалами.
Рис. 4.1. Подсистемы и взаимодействие модулей СИД DISGO
Подсистема обработки запросов состоит из следующих модулей:
Web-сервиса обработки запросов QS (Query Server), процессора
запросов, синтаксического анализатора, конструктора графа MCIG,
модуля перевода запросов в выражения РА, оптимизатора запросов,
120
Соседние файлы в предмете [НЕСОРТИРОВАННОЕ]