Производительность DB2 9 при работе с XML

Опции документа Опции документа, требующие включения JavaScript, не отображаются Обсудить Выскажите мнение об этой странице Помогите нам улучшить содержание

Уровень сложности: средний

Ирина Коган, специалист по производительности DB2/XML, IBM Toronto Lab
Маттиас Никола, технический специалист, IBM
Берни Шифер, ведущий инженер DB2, IBM Toronto Lab

12.11.2007

В статье представлены характеристики производительности и масштабируемости имитационной среды для моделирования брокерских транзакций с ценными бумагами, построенной на базе DB2 9 XML, IBM POWER5+, AIX 5.3 и TotalStorage DS8100. В сценарии используется стандартная для финансовой индустрии схема FIXML. Для получения результатов, обсуждаемых в данной статье, использовался тест производительности БД Transaction Processing over XML (TPoX).

Введение

Сегодня, после выхода версии DB2 9, настала пора протестировать одну из ее новейших возможностей - pureXML®. Для тестирования мы использовали имитационную среду обработки брокерских транзакций. Такая среда характеризуется следующими особенностями:

• Большой объём параллельных транзакций
• Малые размеры отдельных транзакций
• Много маленьких документов XML
• Меняющаяся структура документов XML – в тесты включены данные, совместимые с FIXML, реализованным на базе XML стандартом финансовой отрасли Financial Information eXchange (FIX).

Вы помните, что приложения, работающие с XML, в целом можно подразделить на две группы:

• Ориентированные на данные (большой объём и малый размер транзакций – то, что рассматривается в данной статье)
• Ориентированные на документы (переменный объём, больший размер транзакций)

Кроме того, приложения баз данных для работы с XML очень разнообразны и включают следующие разновидности:

• Публикация реляционных данных в качестве XML
• Управление контентом и документами с помощью полнотекстового поиска в XML
• Консолидация различных источников данных
• Обработка форм
• Вычислительная поддержка Web-сервисов и сервис-ориентированной архитектуры (SOA)
• Основанная на сообщениях обработка транзакций, и основанная на XML оперативная обработка транзакций по сети (OLTP) в финансовой индустрии

В этой статье рассматриваются показатели производительности построенного на XML сценария обработки транзакций, моделирующего ориентированное на данные финансовое приложение. Для моделирования сценария и получения оценок используется тест TPoX. Тестовая конфигурация включала новейший сервер POWER5 (p5 560Q) с AIX 5.3 и дисковую систему TotalStorage DS8100.

DB2 9 и XML

В качестве новых функций поддержки XML в DB2 9 реализованы поддержка хранения чистого XML (pureXML), индексы XML, XQuery, SQL/XML и мощные средства работы со схемами XML. "Pure" означает, что документы XML хранятся в виде типизированных аннотированных деревьев, чего не было ни в одной из прежних коммерческих реляционных БД. В частности, pureXML сильно отличается от хранения данных в качестве больших объектов (BLOBS или CLOBs) и от разделения XML на набор реляционных таблиц. Дополнительную информацию можно найти в предыдущих статьях "Новинки в DB2 Viper" (developerWorks, февраль 2006 г.) и "Встроенная поддержка XML в DB2 Universal Database."

В начало

Тестовый сценарий: онлайновая брокерская система

В нашем тестовом сценарии мы моделируем онлайновую брокерскую систему. Наш опыт поддержки финансовых компаний во внедрении XML помог нам понять их потребности в хранению и обработке данных. Сценарий целенаправленно упрощён, однако соответствует действительности в том, что касается документов, транзакций и схем XML.

Основными логическими сущностями нашего сценария являются (см. рисунок 1):

• Пользователь: у каждого пользователя может быть несколько учётных записей.
• Учётная запись: каждая учётная запись содержит один и более вкладов.
• Вклад: некоторое количество ценных бумаг.
• Ценная бумага: идентификатор вклада (например, наименование акции).
• Заказ: каждый заказ покупает или продаёт одну конкретную ценную бумагу для конкретной учётной записи.

Обработка и размер документа зависят от его типа:

• Для каждого пользователя создаётся документ CustAcc, содержащий всю информацию о пользователе, об учётных записях и вкладах. Размер документа CustAcc – от 4КБ до 20КБ.
• Заказы представляются в FIXML 4.4. FIXML – отраслевой стандарт схемы XML, предназначенный для торгово-ориентированных сообщений, таких как заказы на покупку или продажу (www.fixprotocol.org). Размер документа с заказом – от 1 КБ до 2 КБ. Документы с заказами характеризуются большим количеством атрибутов и большим отношением числа узлов к объему данных.
• Документы ценных бумаг (фиксированное число - 20833) представляют основную часть оборачивающихся в США акций и фондов и используют реальные символы и наименования. Их размер колеблется от 3 КБ до 10 КБ.

Для создания экземпляров документов для всех трёх схем используется генератор данных Toxgene. Информация о Toxgene есть в статье ToXgene – генератор данных ToX XML .

В начало

Тест производительности TPoX

Тест TPoX недавно перешел на принципы Open Source: http://www.tpox.net. Этот тест моделирует описанный выше финансовый сценарий. Основное внимание в нем уделяется аспектам XQuery, SQL/XML, XML-вставок, обновлений, удалений, индексов XML и параллельности. Драйвер рабочей нагрузки, написанный на Java, создаёт нагрузку и собирает оценки производительности. Полный дистрибутив теста можно скачать с его официального сайта. В нём содержится скрипт runall.ksh, позволяющий сгенерировать данные XML и повторить все эксперименты из статьи. Скрипт setenv.ksh также позволяет настроить тест под конкретную машину.

В начало

Оборудование и настройки для теста

Тесты запускались на следующем оборудовании:

• Процессор: 8-процессорный логический раздел (LPAR) системы среднего класса IBM System p5 560Q. Восемь ядер работают на частоте 1.5 ГГц.
• Память: 32 ГБ
• ОС: AIX 5L v5.3 TL04 (тип системы: 9116-561, два четырехпроцессорных модуля)
• Одновременная многопоточность с 16 исполняемыми потоками (логическими процессорами).
• Был установлен драйвер одновременного многоканального доступа (SDD). Это улучшает возможности доступа к серверу хранения данных за счет повышенной готовности и динамического распределения нагрузки ввода/вывода между адаптерами Fibre Channel сервера хранения данных.
• Система хранения данных: IBM TotalStorage DS8100, соединённый с логическим разделом через четыре адаптера Fibre Channel.

Настройки AIX

При установке DB2 автоматически производятся все необходимые настройки системных параметров. Для оптимального контроля использования памяти для кэширования файловой системы были установлены следующие параметры управления виртуальной памятью:

vmo -o minperm%=5
vmo -o maxclient%=15
vmo -o maxperm%=15

Перед установкой этих параметров рекомендуется как следует ознакомиться с менеджером виртуальной памяти AIX. Необходимо учитывать другие параметры, в особенности lru_file_repage. Приведенные настройки OLTP XML-среды нельзя рассматривать как оптимальные для любых сред DB2.

Во избежание попыток кэширования входящих файлов при загрузке данных содержащая исходные файлы XML файловая система была смонтирована с опцией параллельного ввода/вывода JFS2, что было реализовано с помощью опции -o cio команды mount.

Настройка системы хранения

Для TotalStorage DS8100 использовались стандартные настройки по умолчанию. Система DS8100 внутри по сути представляет собой сервер POWER5 eServer p5 570. В отличие от предшествующей системы ESS, в которой использовались кольца SSA, в DS8100 взаимосвязь между дисками для скорейшего доступа к данным осуществляется с помощью Switched Fiber Channel Arbitrated Loop (FC-AL). В DS8100 было установлено 128 дисков, разбитых на 16 разделов. Из них 8 разделов (64 диска) были назначены для данного LPAR. Четыре тома размером в 388 ГБ каждый имели конфигурацию 6+четность+резерв. Оставшиеся четыре тома размерами в 452 ГБ каждый имели конфигурацию 7+четность. Все 8 томов были включены в одну группу томов (VG). На этой группе томов размещались все хранящиеся в DB2 компоненты, включая табличные пространства, журналы и резервные копии. В таблице 1 подытожены все настройки.

Конфигурация DB2

Версия DB2 9 имеет ряд новых функциональных возможностей, включая новые средства автономной самооптимизации. В данном тесте используются некоторые из автономных возможностей, в частности:

• Автоматическое управление ресурсами хранения
• Управление памятью с автоматической оптимизацией

Поскольку менеджер самонастройки памяти (STMM) DB2 был включён, он постоянно оптимизировал установки DB2. Примеры некоторых ключевых параметров DB2, управляемых и модифицированных STMM во время тестовых запусков, показаны в таблице 2. Важно понимать, что STMM автоматически менял эти параметры в зависимости от типа нагрузки, например, только вставка, только запросы, смешанная нагрузка.

После этого администратору БД остается выполнить лишь несколько операций по настройке БД, представленных в таблице 3.

В начало

Нагрузки

Были разработаны, проверены и измерены три рабочие нагрузки XML:

• Вставка (только запись)
• Запрос (только чтение)
• Смешанная (чтение и запись)

Все они характеризуются высоким уровнем параллельности. Рабочая нагрузка осуществляется драйвером на Java, создающим от одного до n параллельных потоков. Каждый поток имитирует пользователя, подключающегося к БД и производящего поток транзакций без перерывов на обдумывание. Каждый поток представляет собой средневзвешенную случайную последовательность транзакций, выбираемых из списка в шаблоне. Для каждой транзакции задается её вес, определяющий процент данной транзакции в общей нагрузке. В процессе работы значения параметров в транзакциях заменяются конкретными значениями, взятыми из настраиваемых случайных распределений и списков ввода.

Нагрузка вставками: только запись

При нагрузке вставками БД заполняется приблизительно 100 гигабайтами данных XML:

• 6 млн. документов CustAcc
• 30 млн. заказов
• 20833 ценные бумаги

Вначале 83 параллельных пользователя водят все ценные бумаги. Потом последовательно порциями вносятся документы CustAcc и Order – дабы убедиться, что производительность при вставках масштабируема. На каждом из указанных в таблице 4 этапов одновременно действуют 100 пользователей.

Нагрузка запросами: только чтение

После заполнения БД при помощи вставок выполнялась нагрузка чтением. Эта нагрузка, состоящая из семи разных запросов XML, осуществлялась с разными уровнями параллельности, с 25, 50, 75, 100, 125 и 150 одновременно запрашивающими пользователями. Тест при каждом из шести запусков запускался на один час.

Семь запросов характеризуются следующими общими чертами:

• Они записаны в совместимой по стандартами нотации SQL/XML, такой как SQL со встроенным XQuery, и в них используются маркеры параметров. Более подробную информацию см. в статье Усовершенствования в SQL/XML.
• Для выбора документов XML по одному или нескольким заданным в XQuery условиям используется SQL/XML-предикат XMLEXISTS.
• Для полного или частичного извлечения документов XML, а также для создания новых отсутствующих в базе документов в них используется SQL/XML-функция XMLQUERY.
• В них используются пространства имен, соответствующие пространствам имен в данных XML.
• Для полного исключения сканирования таблиц в них используются один или несколько индексов XML.
• Все семь запросов представлены в рабочей нагрузке в равных долях.

В таблице 5 показаны отличительные характеристики этих запросов и таблицы, с которыми они работают.

Смешанная нагрузка: чтение/запись

Так же как и при нагрузке чтением, смешанная нагрузка выполнялась на базе с 6 млн. документов CustAcc и 30 млн. документов order, с разными степенями параллельности – с 25, 50, 75, 100, 125, и 150 одновременно работающими пользователями. Каждый раз тест запускался по часу.

Смешанная нагрузка включает в себя:

• 70% операций - чтение: запросы
• 30% операций - запись: 6% обновления, 12% удаления документов, и 12% вставки документов.

Запросы организовывались по тому же принципу, что и перед этим при нагрузке чтением, транзакции же обновлений, вставок и удалений создавались следующим образом:

• Учётные записи пользователей обновляются с целью отражения результатов торгов (выполнение заказов), однако не обязательно немедленно после каждого заказа (3% обновлений CustAcc)
• Документы с заказами в нашем сценарии не обновляются (транзакций с обновлениями заказов нет)
• Цены ценных бумаг регулярно обновляются в течение бизнес-дня (3% обновлений ЦБ)
• Оборот пользователей невысок (по 2% вставок и удалений из CustAcc)
• Постоянно поступают новые и с такой же скоростью удаляются старые заказы (по 10% вставок и удалений заказов)
• Количество ЦБ фиксировано (нет транзакций вставки и удаления)

На основании всех этих условий была создана показанная в таблице 6 смесь транзакций.

Обновляющие транзакции сначала читают некоторый документ в соответствии с предикатами XQuery, после на его основании обновляют первоначальный экземпляр документа в БД. В реальности документ между чтением и обновлением может измениться, однако для поставленных в нашей статье целей это не имеет значения, и мы для простоты это игнорируем.

Вставки проводятся без проверки схемы XML.

Документы для обновления и удаления выбираются в БД случайным образом. Каждый новый вставленный заказ или документ CustAcc сразу становится доступен как для обновления, так и для удаления.

В начало

Результаты

Установка БД и запуск всех нагрузок были выполнены последовательно и непрерывно. В результате получился 23-часовой непрерывный тест системы, результаты которого отражены в таблице 7.

Результаты нагрузки вставками

Вставка 36020833 документов заняла приблизительно 160 минут, со средней скоростью 3770 вставок в секунду. Скорость зависела от размеров:

• Документы с заказами (1K - 2K) вставлялись на скорости 5320 вставок/сек.
• Учётные записи (3K - 10K) вставлялись на скорости 1550 вставок/сек.

Всего в БД вносилось около 30 ГБ в час. На рисунке 2 видно, что скорость вставок почти постоянна вплоть до общего количества заказов в 30 млн.

Результаты нагрузки запросами

При росте количества пользователей процессоры начинали использоваться лучше, и производительность увеличивалась. Как и следует ожидать, при достижении нагрузки на процессоры в 100% скорость потока выравнивается. Как показано на рисунке 3, оптимальный поток был достигнут при 150 пользователях на скорости 5480 запросов/сек с 96-процентной загруженностью процессоров.

Увеличение количества пользователей до 175 не повышает существенно скорость потока, поскольку машина уже полностью загружена.

Результаты смешанной нагрузки

Как показано на рисунке 4, оптимальная нагрузка была достигнута тоже при 150 одновременно работающих пользователях. Скорость потока составила 1980 транзакций/сек. Как и ожидалось, при смешанной нагрузке поток ниже, чем при только чтении или только вставках.

В начало

Резюме

Целью данного опыта была демонстрация производительности нового серверного оборудования и систем хранения IBM, ОС AIX и СУБД DB2 9 при работе с XML. Для этого использовался тест TPoX. Во всех тестах использовались новый модуль STMM и функции автоматического управления системой хранения СУБД DB2.

Мы считаем, что данный сценарий является репрезентативным для значительной части использующих XML приложений с основанными на сообщениях транзакциями, а также для Web-сервисов, работающих с множеством маленьких документов XML. Мы выбрали финансовую отрасль по причине наличия опыта работы с ней, а также потому, что в ней принята зрелая и стандартизированная схема XML - FIXML.

Итоги:

• Тест длился 23 часа, включая создание БД
• В тесте использовались 6 млн. документов CustAcc, 30 млн. документов Order и 20833 документов Security.
• Тесты проводились с 25, 50, 75, 100, 125 и 150 одновременно работающими пользователями.
• Поток вставок (транзакций в секунду, tps) менялся при изменении размеров документов, однако достаточно линейно. Скорость потока была равномерна и равнялась 30 ГБ в час вне зависимости от размеров документов:
• 1550 tps (документы CustAcc, от 4K до 20K)
• 5320 tps (документы order, от 1K до 2K)
• Поток запросов зависел от количества пользователей:
• 2000 tps при 25 пользователях
• 5500 tps при 150 пользователях (максимальная загрузка ЦП, время ожидания стремится к 0)
• Поток при смешанной нагрузке также зависел от количества пользователей и достигал скорости 2000 tps:
• 1000 tps при 25 пользователях
• 2000 tps при 150 пользователях (загрузка ЦП ~42%, время ожидания ~50%).

В начало

Благодарности

Авторы благодарят Сунил Камата (Sunil Kamath) и Пунит Шаха (Punit Shah) за помощь в этом проекте и написании данной статьи.

Ресурсы

• Оригинал статьи DB2 9 XML performance characteristics (EN).
  
  
• Transaction Processing over XML (TPoX) benchmark: изучите TPoX – тест, основанный на сценарии сетевой брокерской системы и использующий различные новые возможности работы XML в базах данных. (EN)
  
  
• DB2 9 - pureXML и компрессия данных: узнайте, как органичная интеграция pureXML с реляционными данными ускоряет процесс разработки. (EN)
  
  
• "Встроенная поддержка XML в DB2 Universal Database" (Результаты 31-й конференции VLDB Conference, 2005 г.): сводка расширений языка программирования.(EN)
  
  
• "Что нового в DB2 Viper: XML в самом ядре" (developerWorks, февраль 2006 г.): ознакомьтесь с новыми технологиями XML в DB2, находящимися на стадии бета-тестирования.
  
  
• Toxgene Data Generator: ознакомьтесь с ToXgene – генератором, позволяющим получать на основе шаблонов большие наборы согласованных документов XML.(EN)
  
  
• Усовершенствования в SQL/XML. (Sigmod Record, 33(3), 2004): узнайте о новых возможностях, добавленных во втором издании SQL/XML.(EN)
  
  
• IBM System p5 560Q: сервер среднего класса IBM System p5 560Q отличается великолепным соотношением цены и производительности, высокой надёжностью и готовностью и возможностью расширения до 16 ядер.(EN)
  
  
• IBM Totalstorage DS8100: серия IBM TotalStorage DS8000 включает системы хранения высокой емкости с производительностью, масштабируемостью, устойчивостью и экономической эффективностью нового поколения.(EN)
  
  
• Посетите раздел Information Management на developerWorks, где вы сможете усовершенствовать свои навыки в области продуктов IBM Information Management.
  
  
• Следите за техническими мероприятиями и Web-трансляциями на сайте developerWorks.(EN)
  
  

• Используйте в вашей следующей разработке ознакомительное ПО от IBM , которое можно загрузить прямо с developerWorks.(EN)
  
  

• Примите участие в обсуждении материала на форуме.
  
  
• Участвуйте в блогах developerWorks и вступайте в сообщество developerWorks.(EN)

Об авторах

		Ирина Коган (Irina Kogan) работает в лаборатории IBM в Торонто программистом, занимается производительностью XML в DB2 и контактирует как с разработчиками, так и с пользователями. Она интересуется новыми методами хранения и обновлениями структуры XML, XQuery, OLTP и разработкой тестов производительности. Ирина – бакалавр и магистр компьютерных наук Йоркского университета. Тема её магистерской диссертации – семантическая интеграция и принципы хорошего дизайна в разработке БД. До перехода в IBM в 2004 она работала в области разработки на XML и Java в корпорации Siemens в Германии.

		Доктор Никола (Nicola) является ведущим техническим специалистом по производительности DB2/XML в Лаборатории IBM в Силиконовой Долине (Silicon Valley Lab). Он работает над всеми аспектами производительности XML в DB2, включая XQuery, SQL/XML и все возможности, присущие XML в DB2. Доктор Никола тесно сотрудничает с коллективами разработчиков DB2 XML, также как и с заказчиками и деловыми партнерами, использующими XML, помогая им в проектировании, реализации и оптимизации решений на XML. До начала работы в IBM Доктор Никола работал над производительностью информационных хранилищ в Informix Software. Он также участвовал в течение четырех лет в исследовательских и промышленных проектах по распределенным и реплицированным базам данных. Он получил докторскую степень по вычислительной технике в 1999 в Политехническом Университете Аахена, Германия.

		Берни Шифер (Berni Schiefer) – ведущий инженер в области DB2. Он отвечает за тестирование производительности DB2 и разработку программных решений, включая BCU. Он с 1985 года работает в лаборатории IBM в Торонто; до DB2 он работал над SQL/DS и экспериментальной реляционной БД Starburst в исследовательской лаборатории IBM в Альмадене. В настоящее время он занимается внедрением в DB2 передовых технологий, с акцентом на процессоры, производительность, XML, Linux, виртуализацию и автономность.

Выскажите мнение об этой странице

Пожалуйста, найдите минутку и заполните форму, чтобы повысить уровень сервиса. Помогла ли данная информация достичь Вашей цели? Да Нет Не знаю   Пожалуйста, напишите комментарий, чтобы мы могли улучшить данную страницу:   Насколько полезна эта информация? (1 = Бесполезна, 5 = Очень полезна) 1 2 3 4 5

В начало