Добавил:
ivanov666
Опубликованный материал нарушает ваши авторские права? Сообщите нам.
Вуз:
Предмет:
Файл:Методы и средства интеграции независимых баз данных в распределенных телекоммуникационных сетях. Монография
.pdf
реализации СИД в память до начала тестирования. После
изменения настроек сервера приложений производился его
перезапуск, после чего и опять проводилось выполнение нескольких
запросов для «разогрева» сервера приложений.
Основная процедура тестирования организована следующим
образом. Вначале клиентское однопоточное приложение
осуществляет подключение к серверу (СИД или СУБД). После этого
записывается начальное значение времени. Затем случайным
образом выбирается шаблон одного из четырех запросов и случайным
образом генерируются параметры запроса, выбор параметров
осуществляется равномерно из заданного набора значений. В случае
выбора параметров для четвертого шаблона в случае если параметр
TO оказывался больше параметра FROM, значения данных
параметров менялись местами.
В качестве центрального сервера использовалась машина с
процессором Intel Xeon E5345 2.33GHz. Тестовому серверу для работы
было выделено одно процессорное ядро, 1024 MB оперативной
памяти. Центральный сервер работал под управлением 32-битной
ОС CentOS 5.5. Тестировалась СУБД Oracle версии 11g R2, также эта
СУБД использовалась в качестве центральной СУБД СИД DISGO.
ПО СИД DISGO было откомпилировано с помощью OpenJDK 1.6
build 18, работало под управлением сервера приложений Apache
Tomcat 5.0 на том же виртуальном сервере, что и центральная СУБД.
В ходе тестирования СИД DISGO менялись некоторые
настройки СИД и клиента. Каждый тест проводился в двух
вариантах - при включенном и выключенном сжатии передаваемой
информации. Сжатие осуществлялось средствами сервера
приложений с использование алгоритмов, используемых утилитой
gzip [55]. При этом оценивалось влияние следующих настроек СИД
на скорость обработки запросов: размер буфера вставки;
используемый метод выполнения запросов; ограничение на
131
количество потоков выполнения операций2, а также количество
наборов запрашиваемых значений переменных, выбираемых из БД
клиентом за один раз. Стоит отметить, что целью тестирования
являлась корректировка настроек системы с целью повышения ее
пропускной способности (количество запросов в секунду,
обрабатываемых системой) и сравнения данного показателя с
показателями работы функционально идентичного решения,
построенного на базе коммерческих приложений. Вследствие этого
выявлялись наиболее эффективные комбинации параметров, а не
исследовались все возможные их сочетания. Тестирование
проводилось путем выполнения серии запросов длительностью
приблизительно в 5 минут. Выполнение серии завершалось при
превышении пятиминутного интервала выполнения, проверка
превышения интервала выполнялась после извлечения всех
результатов очередного запроса, расчет количества запросов в
секунду осуществлялся исходя из общего времени выполнения
серии запросов. Результаты тестирования приведены в таблице 4.1.
Отметим, что в рассмотренных случаях использование
оптимизированного метода выполнения запросов оказалось
выгодным по сравнению с использованием метода непосредственного
выполнения, хотя оптимизация плана доступа к данным и не
осуществлялась. Вероятно, это связано с контролируемой
многопоточностью, возможностью распараллеливания операций
разных типов.
Использование наивного метода выполнения запросов не дает
такой гибкости: при его использовании вначале обрабатываются
операции материализации (и операции извлечения информации, от
которых они зависят), а затем — остальные операции. Так как
используемый в тестировании компьютер работал на одном ядре
2
только при использовании оптимизированного метода, поскольку при использовании
метода наивного выполнения запросов ограничение на количество потоков выполнения
операций установить невозможно
132
процессора, высокая степень распараллеливания в данной серии тестов
оказалась не выгодна, однако выполнение операций извлечения и
обработки данных в два потока (когда это было возможным) оказалось
оправданным. При высокой степени распараллеливания на работу
системы оказывала значительное влияние конкуренция потоков за
ресурсы. Из приведенных результатов видно, что сжатие передаваемой
информации увеличивало скорость выполнения запросов.
Таблица 4.1
Результаты тестирования СИД DISGO. Производительность системы
при обработке запросов из первого тестового набора.
Тести-
руемая
систе-
ма
DISGO непоср.
DISGO непоср.
DISGO непоср.
Метод
выпол-
нения
запросов
вып-е
вып-е
вып-е
Сжа-
тие
нет 1000 255 0.040 0.040 0.046 0.042
да 1000 255 0.059 0.078 0.069 0.068
да 5000 255 0.077 0.070 0.106 0.084
Размер
извлека-
емого
блока
записей
Размер
буфера
вставки
(кол-во
записей)
Коли-
чество
потоков
выпол-
нения
операций
Резуль-
тат 1,
запро-
сов в
сек.
Резуль-
тат 2,
запро-
сов в
сек.
Резуль-
тат 3,
запро-
сов в
сек.
Сред-
нее
значе-
ние,
запро-
сов в
сек.
DISGO оптимиз. нет 1000 1 1 поток 0.029 0.023 0.027 0.026
DISGO оптимиз. нет 1000 255 4 потока 0.055 0.067 0.055 0.059
DISGO оптимиз. нет 1000 255 1 поток 0.069 0.072 0.066 0.069
DISGO оптимиз. да 1000 255 1 поток 0.089 0.098 0.083 0.090
DISGO оптимиз. да 1000 255 2 потока 0.112 0.108 0.075 0.098
DISGO оптимиз. да 1000 255 4 потока 0.070 0.062 0.068 0.067
DISGO оптимиз. да 5000 255 1 поток 0.078 0.073 0.071 0.074
DISGO оптимиз. да 5000 255 2 потока 0.085 0.096 0.086 0.089
Oracle
0.067 0.081 0.077 0.075
133
Увеличение объема выбираемой клиентом порции ответа не
всегда оказывало положительное влияние на производительность
системы. Но в отдельных случаях увеличение этого объема с 1000 до
5000 результатов в пакете, увеличивало производительность на 23%.
В результате проведенных наблюдений удалось выявить основное
узкое место СИД - передача данных клиенту, которая в отдельных
случаях занимает до 75% времени обработки запроса.
Отметим, что в основном СИД не хватает ресурсов CPU сервера.
Это объясняется тем, что на стадии генерации ответа происходит
преобразование большого количества объектов программы (порядка
нескольких тысяч), представляющих значения выбираемых
пользователем переменных, из бинарного формата в формат XML
(для формирования корректного SOAP сообщения), что является
достаточно дорогой операцией.
Для выяснения влияния объема передаваемой информации на
скорость выполнения запроса был проведен следующий
эксперимент. Запрос с шаблоном, приведенным на рис. 4.8,
выполнялся при следующих условиях. Использовался
оптимизированный методы выполнения запросов, применялось
сжатие, размер извлекаемого блока записей был установлен в 5000,
размер буфера вставки — в 255 записей, количество потоков
исполнения полагалось равным 2, значение параметра TO
изменялось от 1990 до 2000. Каждый запрос выполнялся три раза,
фиксировалось среднее время исполнения и количество выбранных
записей. Для сравнения приводится поведение СУБД Oracle на
аналогичных запросах, их шаблон приведен на рис. 4.9.
134
Preamble { publications="http://www.sfedu.ru/~alp/ontologies/publications#";
must ?f1,?l1,?f2,?l2;
} publications:authors{pub_title,first_name,last_name,
department_name,academic_title}
(?p,?f1,?l1,?d1,?t1), publications:authors{pub_title,first_name,
last_name,department_name, academic_title}(?p,?f2,?l2,?d2,?t2),
publications:publications(?p,?a,?y,?j,?pub,?f_p,?l_p),?l1<>?l2,y<:TO
Рис. 4.8. Шаблон запроса для оценки времени извлечения записей
select distinct A.first_name,A.last_name,B.first_name,B.last_name
from authors A, authors B, publications P
where A.pub_title=P.title and B.pub_title=P.title
and A.last_name<>B.last_name and P.year<:TO
Рис. 4.9. Шаблон запроса для оценки времени извлечения записей
в СУБД Oracle
Зависимость времени выполнения запроса от количества
извлекаемых записей для СИД DISGO и СУБД Oracle показана на
рис. 4.10. Очевидно, что отставание СИД DISGO от СУБД Oracle в
наших тестах определяется более медленной скоростью передачи
больших объемов информации клиенту, что прежде всего связано с
затратами на преобразование объектов, соответствующих значениям
запрашиваемых переменных, в XML представление.
Стоит отметить, что в случае, когда запрос возвращает
относительно небольшой результат (до 5000 записей или примерно
250 КБ данных), СИД DISGO выполняет его быстрее СУБД Oracle за
счет оптимизации плана доступа к данным. В случаях, в которых
доступ к части ИД осуществляются по медленным каналам и в
которых оптимизатор выполняет отсечение некоторых из таких ИД,
преимущества СИД DISGO становятся еще более значительными.
При большом размере ответов использование бинарного протокола
для передачи данных клиенту оказывается более эффективным,
135
поэтому производительность СУБД Oracle остается практически на
том же уровне, а производительность СИД DISGO падает.
Рис. 4.10 Зависимость времени исполнения запроса от количества
извлекаемых записей
В заключительном наборе тестов исследовалась
масштабируемость производительности системы при одновременной
обработке множества запросов. В этом случае конфигурация СИД
DISGO и набор запросов остались такими же, как и в прошлом
примере. Запросы осуществлялись одновременно. Учитывалось
среднее количество выполняемых запросов в секунду для каждого
потока. Результаты тестирования СИД DISGO и СУБД Oracle
приведены на рис. 4.11. Эти результаты показывают, что
масштабируемость СИД DISGO несколько выше, чем у решения на
базе Oracle при достаточно небольшом числе параллельно
выполняемых запросов, но производительность обоих решений
падает с ростом количества таких запросов.
136
0,09
0,08
0,07
0,06
0,05
0,04
0,03
0,02
0,01
0
DISGO Oracle
1 поток
2 потока
3 потока
4 потока
5 потоков
Рис. 4.11. Результаты тестирования СИД DISGO.
Производительность системы при нагрузке в несколько потоков
4.2.2. Анализ производительности СИД DISGO в
распределенной сети
Условия работы СИД в распределенной сети отличаются от
работы в локальной сети за счет следующих факторов. Прежде всего,
увеличиваются задержки в сети (как за счет меньшей совокупной
доступной пропускной способности, так и за счет возможной
перегрузки каналов). Скорости передачи данных могут
варьироваться в достаточно широком диапазоне в зависимости от
удаленности ИД от магистральных каналов. Недостуность некоторого
количества ИД является крайне вероятным событием (например, в
связи с проблемами на каналах передачи данных). Еще одним
фактором, который стоит учитывать, является то, что в
распределенной сети каждый ИД, как правило, предоставляет СИД
меньший объем данных, чем в локальной сети. В данном пункте
оценивается производительность работы СИД DISGO в
распределенной сети.
Прежде всего, стоит отметить, что практически нет в том или
ином виде доступных средств интеграции данных, разрабатываемых
в рамках исследовательских проектов и предназначенных для
137
объединения информации множества ИД в распределенной сети.
Единственной доступной СИД, из числа рассмотренных в настоящей
работе, является СИД TSIMMIS [41]. Однако, после детального
рассмотрения данной СИД оказалось, что она прежде всего
предназначена для объединения данных интерактивных справочных
систем и не поддерживает работу с реляционными СУБД. К тому же,
после ознакомления с исходными кодами данной системы [56]
выяснилось, что в случае появления сбоев обращения к ИД она не
возвращает пользователю неполные ответы на запросы, не имеет
средств параллельного выполнения запросов или каких-либо других
существенных средств оптимизации запросов. Все это однозначно
подтверждает существенно более низкую по сравнению с DISGO
производительность СИД TSIMMIS. В связи с этим
производительность нашего решения сопоставлялась с
производительностью средств интеграции данных системы Oracle –
лидера рынка реляционных СУБД.
Для того чтобы адекватно отразить сценарий интеграции
данных в распределенной сети (в частности, небольшой объем
данных, предоставляемых каждым ИД), была произведена
повторная генерация тестовых данных. Использовалось четыре ИД
— две БД в локальной сети, работающих под управлением СУБД
Oracle 10 R2 (ИД1), Oracle 10 XE (ИД2) и две БД, расположенные на
удаленных серверах в Интернете, работающих под управлением
СУБД PostgreSQL 9.1 (ИД3 и ИД4 соответственно). Задержки при
обращении к ИД3 и ИД4 были порядка 75 мс, доступная пропускная
способность - в районе 8 Мбит/c. Достаточно хорошие показатели
доступной пропускной способности объясняются тем, что
используемые ИД размещались на популярной хостинговой
площадке. При заполнении БД используемые соотношения были
подкорректированы, чтобы каждый ИД предоставлял относительно
небольшое количество информации. Полагалось, что в университете
есть 4 подразделения. Каждое подразделение верхнего уровня имеет
138
от 2 до 7 подразделений нижнего уровня, в которых числится от 4 до
10 сотрудников. Каждый четвертый сотрудник имеет степень:
является кандидатом наук или с вероятностью 1/7 - доктором наук.
Доктора наук занимают должности профессоров и главных научных
сотрудников, каждый четвертый кандидат наук имеет должность
ведущего научного сотрудника, остальные кандидаты наук занимают
должности доцента, старшего преподавателя, старшего научного
сотрудника, прочие сотрудники занимают должности младших
научных сотрудников. Полагается, что кандидат наук имеет от 10 до
20 публикаций, доктор — от 20 до 40. Каждая статья в журнале
имеет до 4 авторов, каждая третья статья - лишь одного автора. В
каждом журнале насчитывается от 15 до 25 статей. Длина статьи
составляет от 5 до 20 страниц. Всего имеется 1 журнал по каждому
направлению. Число направлений равно числу подразделений
университета верхнего уровня. В БД ИД2 содержится информация о
4 журналах.
После генерации БД узла ИД1 содержала сведения о
университете, 4 подразделениях верхнего уровня и 7 подразделениях
нижнего уровня, 806 авторах статей, 589 статьях и имела объем 6 МБ
(3 МБ пользовательских данных без учета индексов); БД узла ИД2
содержала сведения о 4 журналах, 247 авторах, 94 статьях и имела
объем 1.1 МБ (768 КБ пользовательских данных без учета индексов);
БД узла ИД3 содержала сведения о 5 кафедрах, 29 сотрудниках, 278
статьях и имела объем 6 МБ (320 КБ пользовательских данных без
учета индексов); БД узла ИД4 содержала сведения о 3
подразделениях, 18 сотрудниках и 201 статье и имела объем 6 МБ
(112 КБ пользовательских данных без учета индексов).
Представление глобальной схемы и используемые шаблоны запросов
не изменились.
Первая серия тестов выполнялась при доступности всех ИД.
Тестирование проводилось путем выполнения серии запросов
длительностью приблизительно в 5 минут. Шаблоны запросов
139
выбирались случайным образом из данного набора запросов.
Тести
-
Метод
Сжа
Размер
аемого
Размер
вставки
Количес
-
Резуль
-
Резу
-
Резу
-
Сред
-
DISGO
непоср.
да 5000
512
0.19
0.19
0.19
0.19
DISGO
оптимиз.
да
5000
512 2 потока
0.12
0.11
0.11
0.11
DISGO
оптимиз.
да
5000
512 4 потока
0.21
0.19
0.21
0.20
DISGO,
оптимиз.
да
5000
512 4 потока
0.19
0.21
0.20
0.20
DISGO
оптимиз.
да
5000
512 6 потоков
0.25
0.24
0.25
0.25
DISGO,
оптимиз.
да
5000
512 6 потоков
0.24
0.25
0.25
0.25
Oracle
0.30
0.29
0.27
0.29
Значение параметра FROM изменялось от 1990 до 2000, генерация
параметра TO проводилась таким образом, чтобы TO-FROM было не
больше 3. Это позволило уменьшить влияние времени передачи
результата запроса клиенту и сделать результаты экспериментов
более однородными. Результаты сравнения приведены в таблице 4.2.
Для оценки возможного влияния генерации REDO-журналов Oracle
при сборе промежуточных результатов отдельно было проведено
тестирование при хранении промежуточных результатов в
нежурналируемом табличном пространстве.
Таблица 4.2
Результаты тестирования СИД DISGO. Производительность системы
при обработке запросов в распределенной сети при доступности
руемая
система
только
формиро
-вание
ответа
выпол-
нения
запросов
вып-е
тие
извлек
блока
запи-
сей
всех ИД.
буфера
(колич-
во запи-
сей)
выполне-
операций
тво
потоков
ния
тат 1,
запро-
сов в
сек.
льтат
2,
запро-
сов в
сек.
льтат
3,
запро-
сов в
сек.
нее
значе-
ние,
запро-
сов в
сек.
unlogged
tablespace
140
Соседние файлы в предмете [НЕСОРТИРОВАННОЕ]