Анализ выполнения запросов в СУБД H2

В условиях длительной эксплуатации информационных систем на основе реляционных СУБД, сопровождающейся накоплением пользовательских данных, актуальна проблема доступа и обработки хранимой информации. Разработке методик уменьшения времени доступа к данным, в частности оптимизации запросов, уделено особое место в публикациях последних десятилетий [2], [6], [7]. Нами проведено исследование работы модулей выполнения запросов реляционных СУБД в зависимости от их параметров. Объектом исследования была выбрана реляционная СУБД H2 Database, созданная и поддерживаемая сообществом разработчиков. СУБД выпускается под модифицированной лицензией MPL 1.1 (Mozilla Public License).

МЕТОДИКА ЭКСПЕРИМЕНТА

Для того чтобы обеспечить возможность варьировать параметры аппаратной платформы, был использован свободно распространяемый

проприетарный вариант реализации технологии виртуализации компании Oracle. H2 Database реализована посредством технологии Java. В качестве ОС для гостевой системы и системы хоста использовался релиз FreeBSD 8.2. В экспериментальной БД было создано множество таблиц с одинаковой структурой с идентификаторами вида BOOKS_NNN, где NNN – число записей в таблице [3]. Структура таблиц имеет следующее описание согласно стандарту ANSI SQL [1]:

CREATE TABLE BOOKS_NNN (BOOKS_ ID INTEGER DEFAULT NOT NULL, TITLE VARCHAR(500) DEFAULT NULL, AUTHOR VARCHAR(300) DEFAULT NULL, PRODUCERS VARCHAR(300) DEFAULT NULL, YEAR INTEGER DEFAULT NULL, ISBN BIGINT DEFAULT NULL, NUM_PAGES INTEGER DEFAULT NULL, PRICE DOUBLE DEFAULT NULL, PUBL_ID INTEGER DEFAULT NULL, SHOP_ID INTEGER DEFAULT NULL, PRIMARY KEY (BOOKS_ID));

В первой серии экспериментов использовались запросы типа SELECT по шаблону:

SELECT * FROM tablename

WHERE field_name = value , где tablename – идентификатор таблиц вида BOOKS_NNN, field_name – идентификатор поля, value – варьируемое значение поля согласно его типу.

В качестве типов полей использовались: первичный ключ, целочисленный тип INT; целочисленный, тип INT; вещественные числа, тип DOUBLE; символьный, тип VARCHAR. Кроме того, использовались запросы с предикатом типа LIKE для символьного типа.

В таблицах BOOKS_NNN были созданы специальные записи c полями всех означенных типов со значениями первичного ключа из множества {0,05L; 0,1L…0,95L; L}, где L – число записей в таблице.

Всего в ходе эксперимента были проведены измерения для 10 значений системной памяти, 20 значений первичного ключа таблицы, 5 типов предикатов, по 10 измерений на каждую комбинацию параметров – всего 10 000 значений для каждой из таблиц. В эксперименте использовался персональный компьютер с архитектурой процессора х86 (AMD Sempron 2200+, 1500 MHz) и системной памятью в 512 Mб.

ПРОИЗВОДИТЕЛЬНОСТЬ

В ходе основного эксперимента произведено измерение времени выполнения запросов в зависимости от относительного номера записи в таблицах и значений системной памяти. Диапазон значений системной памяти виртуальной машины подбирался в ходе предварительных измерений и варьировался в диапазоне 112–240 Мб. В ходе основного эксперимента не изменялись параметры СУБД, выставленные по умолчанию разработчиками. В результате наблюдений был установлен ряд фактов.

Экспериментальная зависимость времени выполнения запросов типа SELECT с предикатом по полю первичного ключа от номера запроса имеет выраженный постоянный характер, хорошо описываемый средним значением.

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

В начале списка располагались запросы с предикатом по полю типа VARCHAR. По всем таблицам было отмечено существенное снижение времени выполнения после обработки первого запроса (начало графика на рис. 1). Результатом выполнений этих запросов является запись с минимальным номером кортежа.

Порядковый номер записи, усл. ед.

Объяснением этих наблюдений может служить следующее. H2, как и большинство современных СУБД [4], хранит часто используемые данные в системной памяти, обращение к которым занимает существенно меньшее время.

Также было отмечено скачкообразное снижение времени выполнения запросов при увеличении размера системной памяти в случае первого обращения к таблице данных (рис. 2), когда влияние механизма кэширования исключается.

Рис. 2. Время выполнения запросов при первом обращении к таблице

Для аппроксимации экспериментальных данных была выбрана форма кривой (рис. 1–2) в виде обратной функции т (s) = Y + 7з, s - Y 2

где T(s) – время выполнения запроса, γ₁ – коэффициент пропорциональности, γ₂ , γ₃ – вертикальная и горизонтальная оси гиперболы соответственно.

ИСПОЛЬЗОВАНИЕ КЭША

Для выяснения влияния объема кэша на производительность СУБД проведены дополнительные измерения. При фиксированном значении системной памяти и запросов к определенной таблице варьировался размер кэша, задаваемого в настройках подключения к СУБД. На рис. 3 представлены графики экспериментальных зависимостей. Производился скачкообразный рост кэша от нулевого размера до дальнейших значений с шагом 512 Кб. Из списка пакета запросов первый запрос выполнялся медленнее последующих. Качественный скачок – уменьшение времени запроса до 25 раз – отмечался при значении кэша в 28 160 Кб (рис. 4).

В. Б. Ефлов, Е. А. Питухин, Ф. В. Стафеев

Рис. 3. Зависимость времени выполнения запросов при различных значениях размера кэшируемых данных

Рис. 4. Изменение зависимости времени выполнения запросов при увеличении размера кэшируемых данных

Среднее время выполнения запросов, следовавших в списке скрипта после первичного обращения к таблице, составляет, по оценке, всего около 1,5 % от среднего времени выполнения первичного запроса. Зависимость установивше- гося времени выполнения запросов от объема кэшируемых данных представлена на рис. 5.

Кэш, Мб

Рис. 5. Выполнение запросов при изменении размера кэша

Очевидно, СУБД не использовало вторичную память в этом случае. Все необходимые данные кэшировались в системной памяти. Необходимо отметить, что размер экспортированных в формат CSV файла данных запрашиваемой таблицы составил 5054 Кб.

ВЫВОДЫ

Учитывая ярко выраженную зависимость производительности H2 Database от технологии кэширования, увеличение объема данных, размещаемых в системной памяти, способно качественно уменьшить время выполнения запросов. Неслучайно в этой связи на протяжении последних двух десятилетий [5] активно происходит развитие направления в разработке СУБД – Inmemory database, реляционная база данных, оптимизированная для работы с оперативной памятью и целиком размещаемая в ней.

* Работа выполнена при поддержке Программы стратегического развития ПетрГУ в рамках реализации комплекса мероприятий по развитию научно-исследовательской деятельности на 2012–2016 гг.

REVIEW OF QUERY EXECUTION IN DBMS H2