Анализ производительности
В этом разделе представлены результаты тестирования производительности системы BizQuery. Насколько известно авторам, в открытом доступе сегодня не существует средств тестирования производительности систем, подобных BizQuery. Поэтому пришлось воспользоваться средством для тестирования XML СУБД - пакетом XMark [18] и адаптировать его для BizQuery.
Документ, соответствующий DTD XMark auctions, был разбит на части, которые были распределены по трем источникам - одному XML-источнику и двум реляционным. В качестве XML-источника выступала программа QuiP [19] компании Software AG, представляющая собой XQuery-процессор над файловой системой. В качестве реляционного источника использовалась СУБД Oracle 8i. Следует заметить, что QuiP не является полноценной СУБД, а также является прототипом. Поэтому производительность этого программного средства была невысокой, что повлияло на распределение данных. Кроме того, чтобы представить определенные части исходного документа в виде реляционных таблиц, пришлось упростить эти части (например, путем избавления от вложенности элементов).
В результате первый реляционный источник содержал 5 таблиц, суммарное количество картежей которых превышало 1,8 миллиона. Второй реляционный источник содержал 3 таблицы с более чем 4,2 миллионами кортежей. Суммарный объем XML-файлов, по которым строились реляционные таблицы, превышает 700Mb. XML-источник содержал 4 файла, общим объемом 5,8Mb.
В табл. 2 показаны запросы, для которых приводятся результаты измерения.
| Q1 | for $x in document("real:sql1/item")/ table/tuplewhere $x/QUANTITY="5" and $x/location="Germany"return $x |
| Q2 | for $y in document("real:sql2/interest") /table/tuplefor $z in document("real:sql2/people") /table/tuple[business="yes" and city="Moscow"] for $x in document("real:sql1/categories") /table/tuple [name="all"]where $y/ref_category=$x/ id_category and $y/ref_person= $z/id_personreturn ($x, $z) |
| Q3 | document("virtual:closed_auction.xml") |
| Q4 | for $v in document("virtual:item.xml") /item[location= "United States"]for $z in document("real:sql1/mailbox") /table/tuple[mail_date="12/11/99"] where $v/id=$z/ref_itemreturn element {name($v)} {$v/*[not empty(./text())]} |
Табл. 2. XQuery-запросы, использованные при тестировании
Для измерения производительности использовалась следующая конфигурация. BizQuery Integration Server работал на Pentium-IV 1500Mhz c 512Mb RAM. Для XML-источника данных (QuiP) использовалась такая же машина. Оба сервера реляционных СУБД (Oracle) работали на машинах одинаковой конфигурации - Pentium-III 733Mhz с 256Mb RAM. Все машины работали под управлением Windows 2000.
Запрос Q1 адресуется реальному документу item (таблице реляционного источника 1) и просто налагает условие на данные. Запрос Q2 содержит два соединения, одно из которых выполняется между документами одного источника, а второе соединение - кроссдоменное - между разными реляционными источниками. Запрос Q3 показывает возможность построения виртуального документа closed_auctions.xml целиком. И, наконец, запрос Q4 выполняет соединение между виртуальным документом item.xml и реальным документом mailbox из второго реляционного источника. Результаты выполнения представлены в табл. 3.
| Номер запроса | Размер результата (в Kb) | Общее время работы источников | Время работы BizQuery | Общее время выполнения запроса |
| Q1 | 23 | 5,984 | 0,078 | 6,062 |
| Q2 | 12 | 82,485 | 1,796 | 84,281 |
| Q3 | 3673 | 67,907 | 3,093 | 71,000 |
| Q4 | 27 | 52,766 | 0,938 | 53,704 |
Во всех четырех запросах, вне зависимости от общего времени выполнения, чистое время работы BizQuery (включающее оптимизацию и, если необходимо, выполнение кроссдоменных операций) относительно невелико. Это обеспе-чивается посредством перезаписи запросов (особенно в случае запроса Q4, где производится соединение виртуального документа с реальным) и декомпозиции запросов, которая приводит к выделению наиболее дорого-стоящей части запроса и передачи ее для выполнения источнику. Заметим, что общее время выполнения запроса можно было бы снизить, введя дополни-тельные индексы в источниках, однако рассмотрение данного вопроса выходит за рамки статьи. Ограниченный объем статьи не позволяет также привести примеры работы логического оптимизатора по существенному упрощению запросов, содержащих сложные трансформации (особенно те запросы, которые генерируются автоматически). Эти примеры чрезвычайно объемны.