УДК 004.657
Анализ времени выполнения запроса в параллельном колоночном хранилище данных
© Ю. А. Григорьев, Е.Ю. Ермаков МГТУ им. Н.Э. Баумана, Москва, 105005, Россия
Проанализирован специфичный для параллельных колоночных хранилищ данных план запроса со скрытым соединением. Приведено преобразование Лапласа — Стилтьеса времени обработки запроса с подобным планом в параллельном колоночном хранилище данных. Выполнено сравнение среднего времени выполнения запроса со скрытым соединением и пересечением NLJ.
Ключевые слова: колоночное хранилище данных, колоночные базы данных, параллельные базы данных, преобразование Лапласа — Стилтьеса, скрытое соединение.
Введение. Являясь одними из наиболее значимых элементов ИТ-инфраструктуры предприятия, базы данных (БД) консолидируют информацию, необходимую для создания достоверных аналитических и управленческих отчетов. Они являются одними из крупнейших источников информации для современных аналитиков и, по оценке Gartner [1], в ближайшей перспективе останутся ключевым компонентом ИТ-инфраструктуры предприятий.
При оценке характеристик производительности на этапе проектирования БД необходимо учитывать особенности предметной области. Результаты исследований [2] показывают, что при расчете времени реакции информационной системы надо учитывать параметры приложений: алгоритмы, запросы к БД и т.д. Время обработки этих запросов достаточно велико, его доля в общем времени выполнения прикладных программ превышает 90 %.
Методы анализа временньк характеристик для параллельных строчных БД (Oracle, MS SQL Server и т. д.), учитывающих специфику запросов к базе данных, уже разработаны и представлены в работах [26]. Но в настоящее время внедряются новые системы управления БД с иной организацией хранения данных, получившие название параллельных колоночных БД (ПКБД) [7-9]. Они впервые были внедрены при разработке больших БД, используемых при поддержке принятия решения, в частности, в аналитических расчетах, и сразу же дали хорошие результаты: почти 200-кратное сокращение объема ввода-вывода по сравнению с аналогичными строчными БД и значительное уменьшение времени выполнения запросов [8]. Это достигается за счет того, что из БД читаются только атрибуты (столбцы), участвующие в запросе, а также применяются эффективные методы сжатия столбцов [10].
Однако проектирование систем на основе колоночных систем управления БД ведется на интуитивном уровне, а кроме того, не существует математических методов, позволяющих учитывать специфику сложных запросов к хранилищу данных, которые используются в процессе принятия решений. Поэтому разработка теоретических методов, дающих возможность на этапе проектирования прогнозировать время работы параллельного колоночного хранилища данных (ПКХД) с учетом специфики предметной области, является в настоящее время актуальной.
В исследовательской работе, проводимой в МГТУ им. Н.Э. Баумана, указанная задача решается путем разработки моделей оценки времени выполнения запроса к ПКХД, учитывающих особенности колоночного хранения данных, состав и параметры выполнения запросов, структуру и наполнение хранилища, механизм распределения таблиц по процессорам системы, параллелизм выполнения запросов в узлах, режимы работы системы, структуру сложного многопроцессорного аппаратно-программного комплекса.
В статье рассмотрено специфическое для параллельных колоночных хранилищ данных скрытое соединение и получена оценка времени выполнения запроса к хранилищу на основе математических методов, предложенных авторами в статьях [11-14] с учетом особенностей выполнения запросов к колоночным БД.
Организация работы колоночной системы БД. Под строчным хранением данных обычно понимают физическое хранение кортежа любого отношения в виде одной записи, в котором значения атрибута идут последовательно одно за другим, а за последним атрибутом кортежа в общем случае следует новый кортеж отношения.
Таким образом, на физическом носителе отношение Я представлено в следующем виде:
[а11, а21, • • •, ап1 ]1 [а12, а22, • • •, ап2 ]2 [а13, а23, • • •, ап3 ]3 "
•••[^т,^2т,•,йпт]и, где ¿1г] — значение атрибута аг. ву-м кортеже отношения Я; \^а1 у,а2у,•..,апу^ у — у-й кортеж отношения Я; п — количество атрибутов отношения Я; т = Т (Я) — количество кортежей отношения Я.
В колоночных системах управления БД (СУБД) значения одного атрибута хранятся последовательно друг за другом [10], т.е. на физическом носителе отношение Я примет следующий вид:
(а11, а12, а13, • • •, а1т \ (а21, а22, а23, •■■, а2т) 2 • • • ( ап 1, ап 2, ап 3, • • •, апт )п ,
где ауу — значение атрибута а/ в у-м кортеже отношения Я; (ап,а^2,а{3, •..,а— /-й столбец (атрибут) отношения Я.
Каждая колонка, хранимая на диске, разделена на блоки определенного размера Sb. Блок состоит из заголовка, размер которого пренебрежительно мал по сравнению с размером блока и непосредственно данных. При одном запросе к диску осуществляется чтение нескольких блоков, количество которых определяется параметром.
Каждой записи в столбце относится ее позиция (номер строки). В большинстве современных колоночных БД [14] значения столбца упорядочиваются по их позициям.
На логическом уровне колоночные и строчные СУБД идентичны, т. е. способны обрабатывать одни и те же SQL-запросы. Но отличия в физической организации хранения данных существенно влияют на реализацию процессов, связанных с формированием плана выполнения запроса и его реализацией.
В строчных СУБД план запроса представляет собой дерево, у каждого узла которого имеется один родитель и один (или два в случае пересечения) дочерних узла. Реализация исполнителя планов базируется на следующих трех базовых парадигмах [15]: синхронный конвейер, итераторная модель, скобочный шаблон.
Более подробно изменения, вносимые в каждый из перечисленных элементов плана, рассмотрены в работах [11, 15].
Организация параллельной обработки данных. Основная форма параллельной обработки запросов в строчных и колоночных СУБД — фрагментный параллелизм. Подробно данный процесс рассмотрен в работах [2-4, 16]. В соответствие с этой схемой запрос на языке SQL преобразуется в некоторый последовательный план, который, в свою очередь, преобразуется в параллельный план, представляющий собой совокупность n идентичных параллельных агентов, которые реализуют те же операции, что и последовательный план (рис.1).
0
X .0
0) ГО ГО
а го с к
S J
го а си
1
си
Ро } т
Н Pi I т
^ !1! - р2 ж
- Рз [■ щ
^ii - Рп т
Рис. 1. Генерация параллельного плана запроса
Здесь n обозначает количество процессорных узлов. Это достигается путем вставки в соответствующие места дерева плана запроса составного оператора exchange, состоящего из четырех операторов: split, gather, merge и scatter. На завершающем этапе агенты рассылаются на определенные процессорные узлы, где интерпретируются исполнителем запросов. Результаты выполнения агентов объединяются корневым оператором exchange на нулевом процессорном модуле.
Рассмотрим процесс параллельной обработки запроса, где выполняется соединение таблиц R и S базы данных (рис. 2). Q = R 1X1 S — это логическая операция соединения (join) двух отношений (таблиц) R и S по некоторому общему атрибуту Y. В данном примере таблица R фраг-ментирована произвольным образом, а таблица S — по атрибуту соединения Y. На рис. 2 показано, что логический план выполнения соединения двух отношений тиражируется на n процессоров в параллельной системе баз данных (ПСБД) (на рисунке показаны два процессора). Далее происходит параллельная обработка на каждом процессоре соответствующих фрагментов таблиц R и S. Вследствие того, что таблица R не фрагментирована по атрибуту соединения, при последовательном чтении записей этой таблицы происходит их обработка в операторе exchange, осуществляющем разбор записи и ее межпроцессорный обмен. Таблица S фрагментирована по атрибуту соединения, и записи, читаемые из фрагментов этой таблицы, обрабатываются на каждом процессоре локально.
Рис. 2. Обработка запроса Q = Я в параллельной системе баз данных
Наиболее распространенной системой классификации параллельных систем БД является система, предложенная Майклом Сто-унбрейкером (Michael Stonebraker) [16]:
• SE (Shared-Everything) архитектура с разделяемыми памятью и дисками;
• SD (Shared-Disks) архитектура с разделяемыми дисками;
• SN (Shared-Nothing) архитектура без совместного использования ресурсов.
Обработка запроса к хранилищу данных в ПКБД. Процесс выполнения запроса к хранилищу данных, в частности к хранилищу со звездообразной схемой, может включать следующие шаги:
1) выделение множества кортежей в таблице фактов с использованием предикатов ограничений над одной или несколькими таблицами измерений;
2) выполнение некоторого агрегирования значений фактов, часто с группировкой по атрибутам таблицы измерений.
Таким образом, требуется выполнять соединения таблицы фактов и таблиц измерений для каждого предиката и каждой агрегатной группировки [17]. В качестве специфичного для колоночных БД плана запроса авторы работ [10, 15] предлагают метод, названный ими методом скрытых соединений, который можно использовать в системах БД с хранением данных по столбцам для соединений таблиц БД со звездообразной схемой по атрибутам внешний-ключ/первичный-ключ. Это соединение с отложенной материализацией, но в нем минимизируется число значений, которые требуется извлекать не в порядке следования позиций.
При использовании названного метода соединения выполняются в три этапа. Сначала каждый предикат применяется к соответствующей таблице измерений для извлечения списка ключей записей, удовлетворяющих данному предикату.
Хеш-таблица Date
Рис. 3. Первый этап скрытого соединения
Эти ключи используются для построения хэш-таблицы, которую можно использовать для проверки того, удовлетворяет ли предикату некоторое значение ключа. Пример выполнения первого этапа показан на рис. 3.
На втором этапе хэш-таблицы используются для извлечения позиций тех записей из таблицы фактов, которые удовлетворяют соответствующему предикату. Для каждого значения столбца внешнего ключа таблицы фактов выполняется поиск в соответствующей хэш-таблице. Далее создается список всех позиций в этом столбце, значения которых удовлетворяют предикату. Затем списки позиций всех столбцов пересекаются и создается список позиций таблицы фактов, которые соответствуют записям, удовлетворяющим исходному условию поиска. Пример выполнения второго этапа показан на рис. 4.
Рис. 4. Второй этап скрытого соединения
На третьем этапе с помощью списка позиций таблицы фактов осуществляется поиск в соответствующей таблице измерений. Если ключи таблицы измерений образуют отсортированный непрерывный список идентификаторов, начинающийся с единицы, значение внешнего ключа в действительности задает позицию нужного кортежа в таблице измерений. Это означает, что требуемые столбцы таблицы измерений могут быть извлечены напрямую с использованием этого списка значений внешнего ключа.
Пример выполнения третьего этапа показан на рис. 5. Для таблицы Date столбец ключа не является отсортированным непрерывным списком, начинающимся с единицы, поэтому для него требуется вы-
полнять полное соединение. Поскольку это соединение вида внеш-ний-ключ/первичный-ключ и все предикаты уже применены, гарантируется, что в каждой таблице измерений для каждой позиции окончательного списка позиций таблицы фактов будет обнаружен один и только один результат. Это означает, что на этом третьем этапе при соединении с каждой таблицей измерений получается одно и то же число результатов, так что каждое соединение может выполняться по отдельности, и результаты могут материализоваться в более поздней точке плана выполнения запроса.
п
1
"о"
0
Т
0
0
Asia Asia
n
1
~0~
0
~сГ
0
0
02012013
02012013
n
1
"о"
0
~0~
0
0
Рис. 5. Третий этап скрытого соединения
Преобразование Лапласа — Стилтьеса времени обработки запроса к хранилищу данных. Ниже поэтапно выводится преобразование Лапласа-Стилтьеса (ПЛС) времени выполнения запроса к хранилищу данных, которое справедливо для каждого узла параллельной колоночной системы баз данных. Здесь используется математический аппарат, изложенный в работах [2-6].
Все время обработки можно представить в виде суммы времени каждого из описанных ранее этапов.
Чтение ключевых атрибутов измерений. Введем следующие выражения для описания ПЛС времени К чтения таблиц измерений
K
FRk<
(Rk, k = 1, K) с условиями FRk = fo n р| f и пересылки ключевых
i=1
атрибутов остальным узлам распределенной системы:
О (Р, г) = 1 - Р (1 - z); (1)
О (¿)=2Ук/п (2)
— производящая функция (ПФ) числа позиций (записей) таблицы (отношения) к-го измерения, обрабатываемых на одном процессоре, где Ук — общее число записей в таблице к-го измерения; п — число процессоров в кластере (или в машине);
X , (^ г, т) = ф А (фМц' (э) Фр ((3) — ПЛС времени обработки в ресурсах, где (э) — ПЛС времени чтения кортежа 1-го столбца с диска для к-го измерения; фМц' (5) —ПЛС времени сохранения атрибута в оперативной памяти (ОП) и его чтения в кэш процессора; ц - размер атрибута; тц — число операций чтения/записи в оперативную память, необходимых для проверки условия по соответствующему атрибуту *; ФР(- ПЛС времени обработки кортежа столбца в процессоре; г — число логических операций, необходимых для проверки условия по соответствующему атрибуту.
Функция у ) учитывает, что для к-й таблицы измерений читаются кортежи колонок по позициям, удовлетворяющим условиям поиска по предыдущим атрибутам (процесс поздней материализации, см. [12, 18]). Эта функция рекуррентно определяется следующим образом:
Т (э, I) = О (1, х1(э, г1, т1) Т1(э, I));
Т (э, I) = О (1, х 2 (э, Г2, т2) Т 2 (э, I));, (4)
Тi (^ I) = ° (р/г, х'+1 (э, Г+1, тг+1)Т0+1) (^ I));
Ть (э, I) = О (Р^, фир (э) I)), где Ь = \Kp-pk — мощность подмножества атрибутов отношения, по которым происходит фильтрация кортежей по условию ^ для к-го
1=1
измерения;
*
Будем считать, что кэш процессора — это чершя дыра в которой ^р^я-ются данные процессора, необходимые для вычислений. Из кэша в ОП перемещаются только результирующие материализованные записи, передаваемые по шине (см. далее Фа^)) процессору, где выполняется сборка.
Фр (5) учитывает, что для проверки условия /0 для материализованных записей к-го измерения потребуется и логических операций процессора; р/ — вероятность, что кортеж /-го атрибута удовлетворяет условию //.
Используя (1-4), получим ПЛС времени обработки к-го измерения на /-м узле:
Я(з,2,2) = а 0 (р, Хп (3 1, т)Г"1 • 7))), (5)
где Хл(з, 1, т) — ПЛС времени чтения кортежа ключевого атрибута с диска в кэш процессора и обработки в нем (см. (3)); 1 означает, что в процессоре проверяется только значение битовой маски в позиции, указанной в кортеже г — учитывает обработку в узле;2 учитывает передачу данных в остальные п - 1 узел; РТ — вероятность, что сформированный кортеж удовлетворяет условию /0.
Тогда ПЛС времени К чтения таблиц измерений (Як, к = 1, К) с
условиями РКк = /0 п ^ // и пересылки ключевых атрибутов
/=1
остальным узлам распределенной системы примет следующий вид:
Щ (5) = п
к=1
Кк, ( Ф# ^ (Фм"к Фр^ );
X п Rkj (0,1, ф 1к4 (5) • фра*к (5))
/=1, j
(6)
где К — общее количество таблиц измерений, участвующих в запросе; Яь(я), Я/5) — ПЛС времени обработки к-го измерения на /-м (/-м) узле; фNУк (з), фММкУк (з) — учитывает перемещение ключевых атрибутов к-го измерения, удовлетворяющих условию поиска Р; V — размер сформированного кортежа; wkvk — количество операций чтения/записи, необходимое для перемещения сформированных записей
ключевых атрибутов измерений; фр^ (з) учитывает процессорное
время на создание хеш-таблиц.
Извлечение битовой маски таблицы фактов. Введем следующие выражения для описания ПЛС времени чтения данных таблицы фактов, получения битовой маски и передачи ее всем узлам распределенной сети:
О/ (2)=2Ш (7)
— ПФ числа позиций (записей) таблицы фактов, обрабатываемых на одном процессоре, где V — общее число записей в таблице фактов.
Функция ¥ z) учитывает, что на основе полученных ключевых атрибутов таблиц измерений и условий фильтрации происходит чтение атрибутов таблицы фактов, и определяется по формуле
¥ (5, z) = (5, ¥ ^ (5, z)), (8)
где функции уR и ^ рекуррентно определяются следующим образом: ¥ R (5, г) = О (Р, Х1( 5, Г!, т1)¥1( 5, z));
¥х(5, z) = О(Р2, X2(5, Г2, Ш2)¥2(5, Z)), (9)
¥ К (5 z) = О (РК, X К (5, ГК, тк ) z).
Здесь К — количество таблиц-измерений, участвующих в запросе; Рк — вероятность, что кортеж атрибута удовлетворяет условию к-го из-
ь
мерения в таблице фактов ( ^ Р^Рт ).
¿=1
В формуле (10) и далее Ра — вероятность, что кортеж считываемой колонки таблицы фактов удовлетворяет соответствующему предикату:
¥ ^ (5, z) = О (Рг 1, XI (5, Г1, т1)¥1 (5, z));
¥1(5, z) = О (Рг 2, X 2 (5, Г2, т2)¥ 2( 5, z)); (10)
¥ г (5, z) = О Р, X г+1(5, Г+1, т+1) ¥ {1+1)(5, z));
¥ в (5, z) = О (Ра, фР (5) z)),
где а — количество атрибутов таблицы фактов, по которым происходит фильтрация кортежей (ограничение на факты); фР (5) учитывает, что для проверки условия/0 для материализованных записей таблицы фактов потребуется и логических операций процессора;Р/а — вероятность, что сформированный кортеж удовлетворяет условию /0.
Используя (7-10), получим ПЛС времени обработки таблицы фактов на ¿-м узле:
3 (5, z, г) = Ог (¥ (5, О (Рт, X* (5,1, т) Г"1 г))), (11)
где z — учитывает передачу полученной маски в остальные n-1 узел для чтения необходимых атрибутов таблиц измерений (шаг 3 скрытого соединения).
Тогда ПЛС времени чтения данных таблицы фактов, получения битовой маски и передачи ее всем узлам распределенной сети примет следующий вид:
Мг (s) = J (s, ф^Vf (s), фMvF (s)) x П Jk (0,1, фМvf (s)), (12)
j =1, j *i
где (s), фм(s) учитывает перемещение ключевых атрибутов, удовлетворяющих условию поиска; v — размер передаваемой битовой маски.
Чтение значений атрибутов измерений. Для получения ПЛС времени чтения дополнительных атрибутов измерений, если такие присутствуют в запросе, введем следующие выражения:
G(z)=zVk/n; (13)
Ak
H (s, z, z) = G(Q(P, Пх j (s, 1, m)) z n"1 z), (14)
j=1
где P — вероятность, что итоговый кортеж удовлетворяет условиям
Г к Л
поиска ПPkPfact ;Ak — количество атрибутов k-й таблицы измере-
V k=1 у
ний, необходимых для предоставления результата выполнения запроса (то, что указывается в SELECT).
Тогда ПЛС времени чтения дополнительных атрибутов измерений, если такие присутствуют в запросе, примет следующий вид:
и (s)=П
k=1
Hki (s, Ф^ (s), фМР (s)) x
, (15)
x П Hj (0,1, Фmat (s) фМ (s) ф7 (s))
j =1, j *i
Где Ф™а (5) учитывает время, необходимое на воссоздание кортежа
МУ / \ МУ / \
результата; фм (5), фм (я)
учитывает перемещение результатов запроса.
ПЛС времени обработки кортежей в ресурсах. Формулы для ф(5)(/ — номер колонки, т. е. атрибута), фм(я), ф^(я) , фр(я) в за-
висимости от архитектуры параллельных колоночных систем баз данных (ПКСБД) и режима работы представлены в таблице [14].
Таблица
При выводе учитывались следующие особенности выполнения запроса в колоночной СУБД [11]:
• каждая колонка хранится на диске в своих блоках, где отдельная колонка представляет собой таблицу с кортежем (значение атрибута, позиция);
• последовательная и параллельная обработка запросов с поздней материализацией кортежей;
• наличие компрессии данных (метод RLE [19] );
• получение времени работы обслуживающих устройств на основе измеримых с помощью синтетических тестов показателей.
При этом рассматривались два режима работы [14]:
1. Пакетный режим (offline, система рассматривается как
замкнутая).
При данном режиме работы в колоночной системе баз данных обрабатываются пакеты запросов. В каждом пакете SQL-запросы выполняются последовательно (предполагается, что они связаны по данным: выходные данные одного запроса являются входными данными другого). Но запросы разных пакетов (по одному из каждого пакета) могут обрабатываться параллельно. Предполагается, что «узкое место» в данном режиме — дисковая подсистема.
2. Режим «запрос-ответ» (online, система рассматривается как разомкнутая). При данном режиме работы предполагается, что i-я рабочая станция обращается к j-му запросу c некоторой интенсивностью. При условии, что эти входные потоки заявок являются пуассо-новскими, время обслуживания в ресурсах распределено по экспоненциальному закону, а переход от ресурса к ресурсу выполняется по вероятности, модель обработки запросов можно представить в виде сети массового обслуживания. В такой сети обработку в узлах ресурсов можно представить в виде совокупности независимых систем массового обслуживания М/М/1 (это доказывается в теории массового обслуживания в виде теоремы разложения Джексона).
Итоговое ПЛС времени обработки запроса к ПКХД. Итоговое ПЛС времени обработки запроса к ПКХД в i-м узле приведено ниже:
Ф, (5) = Dt (s)Mi (s)Ut ( 5)фг (*)фаТ (s), (16)
где D (s), M (s), U (s) — ПЛС времени обработки соответственно первого, второго и третьего этапов скрытого соединения (см. (6), (12), (15));
фРг (s) фМ (s) — учитывают время на агрегацию данных, если это
указано в запросе.
Дифференцируя выражение (16) как сложную функцию по s в нуле, можно получить моменты случайного времени обработки запроса к ПКХД:
М§ = -ф'(0), М?2 = ф''(0), а2 = М?2 -М2.
Для получения значений моментов можно использовать методы численного дифференцирования, описанные в [20]:
(Ф 1/2 -1 Ф2)
ф (*о)--г—; (18)
h
„ (ф2о - 72 Ф^
Ф(Хо) --^-, (19)
h2
где фГ =2 (~1уст Фi+m/2—j (20)
j=0
— разность m-го порядка (при четном m i — целое, при нечетном — полуцелое);
Ф, =Ф( ^) = Ф( *0 +ih) (21)
— соответствующие значения функции; h — шаг таблицы разностей.
Сравнение производительности соединения методом NLJ и скрытого соединения в ПКХД. Ниже приведено сравнение времени выполнения запроса к хранилищу данных для скрытого соединения и соединения методом NLJ [14]. Характеристики ресурсов (интенсивности обработки) были получены с помощью программы синтетических тестов AIDA64 [21]. Расчеты были выполнены при следующих значениях характеристик ресурсов.
1. Процессор Intel Core i7-920 2.79GHz. Для выбранного процессора измеренное значение числа процессорных циклов, выполняемых в секунду, цр = 2,79-109(1/с).
2. Внешняя память ND=250, диск 3,5'' Seagate Cheetah 15K.6 ST3146356FC; размер блока чередования (stripe size) (БЧ) QE4 = 64 Кб; среднее время поиска и чтения блока чередования с диска tE4 = подвода + tвращения/2 + ^вч^чтения = 4 + 4/2 + 64/200 = 6.3 мс. Поэтому интенсивность чтения блоков с диска ^DB= 1000/6,3= 160 (1/с), pd=0,9.
3. Оперативная память DDR3-1600 PC3 — 12 800. Интенсивность чтения одного байта информации из ОП цм= 9586-1024-1024 (1/с).
В качестве примера был выбран аналитический запрос Q3 теста TPC-H [22]. Схема базы данных тестовой среды приведена на рис. 6. Коэффициент sf теста определяет объем обрабатываемых данных: select l_orderkey,
sum(l_extendedprice*(1-l_discount)) as revenue,
o_orderdate,
o_shippriority
from customer,
orders,
lineitem
where c_mktsegment = '[SEGMENT]' and c_custkey = o_custkey and l_orderkey = o_orderkey and o_orderdate < date '[DATE]' andl_shipdate > date '[DATE]'
group by l_orderkey, o_orderdate, o_shippriority order by revenue desc, o orderdate
PART (P_)
SF*200,000
PARTKEY
NAME
MFGR
BRAND
TYPE
SIZE
CONTAINER
RETAILPRICE
COMMENT
SUPPKEY
NAME
ADDRESS
SUPPLIER (S_)
SF*10,000
NATIONKEY
PHONE
ACCTBAL
COMMENT
PARTSUPP (PS_) SF*800,000
PARTKEY
SUPPKEY
AVAILQTY
SUPPLYCOST
COMMENT
CUSTOMER (C_) SF*150,000
CUSTKEY
NAME
ADDRESS
г*- NATIONKEY
PHONE
ACCTBAL
MKTSEGMENT
COMMENT
NATION (N_) 25
NATIONKEY
NAME
REGIONKEY
COMMENT
LINEITEM (L_)
SF*6,000,000
ORDERKEY
PARTKEY
SUPPKEY
LINENUMBER
QUANTITY
EXTENDEDPRICE
DISCOUNT
TAX
RETURNFLAG
LINESTATUS
SHIPDATE
COMMITDATE
RECEIPTDATE
SHIPINSTRUCT
SHIPMODE
COMMENT
REGION (R_
5
REGIONKEY
NAME
COMMENT
ORDERS (O_)
SF*1,500,000
ORDERKEY
CUSTKEY
ORDERSTATUS
TOTALPRICE
ORDERDATE
ORDER-PRIORITY
CLERK
SHIP-PRIORITY
COMMENT
Рис. 6. Схема базы данных теста ТРС-Н
График зависимости времени выполнения запроса от количества узлов для скрытого соединения и соединения методом для архитектуры ББ представлен на рис. 7. Из графика видно, что метод скрытого соединения превосходит по скорости метод КЫ, причем соотношение времени выполнения сохраняется при изменении количества узлов.
Рис 7. Зависимость времени выполнения запроса для различных методов соединения при архитектуре 8Е (/ = 0,01)
На рис. 8 приведена зависимость времени выполнения запроса для различных методов соединения и архитектур от коэффициента / теста ТРС-Н (/). При увеличении объема обрабатываемых данных время обработки при использовании метода увеличивается
быстрее, чем при методе скрытого соединения.
Рис 8. Зависимость времени выполнения запроса для различных методов и архитектур от коэффициента sf теста TPC-H («=20)
Таким образом, авторами
• проанализирован способ выполнения запросов в параллельном колоночном хранилище данных, рассмотрен специфичный для колоночных систем процесс «скрытого соединения» (invisible join);
• получено преобразование Лапласа — Стилтьеса времени выполнения запроса со скрытой материализацией, рассмотрены
варианты этого преобразования для различных архитектур параллельных систем баз данных;
• проведено сравнение времени выполнения запроса к хранилищу данных для скрытого соединения и соединения методом NLJ, показано превосходство метода скрытого соединения.
Из изложенного выше можно сделать вывод, что
• полученное соотношение увеличения скорости выполнения запроса (в 2.75 раза) соответствует экспериментально полученному в работе [15] значению;
• авторы предполагают продолжить исследования и получить модель адаптации полученной ПЛС к конкретной реализации ПКХД.
ЛИТЕРАТУРА
[1] Арсентьев А. Хранилища данных становятся инфраструктурным компонентом
№ 1. CNews аналитика, 2010.
URL: http://retail.cnews.ru/reviews/free/BI2010/articles/articles6.shtml (дата обращения 27.06.2011).
[2] Григорьев Ю.А., Плутенко А. Д. Теоретические основы анализа процессов до-
ступа к распределенным базам данных. Новосибирск, Наука, 2002, 222 с.
[3] Григорьев Ю.А., Плужников В.Л. Оценка времени выполнения запросов и выбор архитектуры параллельной системы баз данных. Москва, МГТУ им. Н.Э. Баумана, 2009.
[4] Григорьев Ю.А., Плужников В.Л. Модель обработки запросов в параллель-
ной системе баз данных. Вестник МГТУ им. Н.Э. Баумана, 2010, № 4, с. 78-90.
[5] Григорьев Ю.А., Плужников В.Л. Оценка времени соединения таблиц в параллельной системе баз данных. Информатика и системы управления, 2011, № 1, с. 3-16.
[6] Григорьев Ю.А., Плужников В.Л. Анализ времени обработки запросов к хранилищу данных в параллельной системе баз данных. Информатика и системы управления, 2011, № 2, с. 94-106.
[7] Stonebraker M., Çetintemel U. One Size Fits All: URL: http://citforum.ru/database/articles/one_size_fits_all/. 27.06.2011.
[8] Stonebraker M., Bear C., Çetintemel U., Cherniack M., Ge T., Hachem N., Harizopoulos S., Lifter J., Rogers J., Zdonik S. One Size Fits All? Part 2: Benchmarking Results. 3rd Biennial Conference on Innovative Data Systems Research (CIDR), January 7-10, 2007, Asilomar, California, USA. URL: http://citforum.ru/database/articles/one_size_fits_all_2/ (дата обращения 27.06.2011).
[9] Stonebraker M. My Top 10 Assertions About Data Warehouses. URL: http://citforum.ru/gazeta/166/]. 27.06.2011.
[10] Stonebraker M., Abadi D.J., Batkin A., Chen X., Cherniack M., Ferreira M., Lau E., Lin A., Madden S.R., O'Neil E.J., O'Neil P.E., Rasin A., Tran N., S.B. Zdonik: C-Store: A Column-Oriented DBMS URL: http://www.cs.yale.edu/homes/dna/pubs/displaypubs.cgi/ (дата обращения 22.10.2011)
[11] Григорьев Ю.А., Ермаков Е.Ю. Модель обработки запросов в параллельной колоночной системе баз данных. Информатика и системы управления, 2012, № 1, с. 3-15.
[12] Григорьев Ю.А., Ермаков Е.Ю. Модель обработки запроса к одной таблице в параллельной колоночной системе баз данных и анализ ее адекватности. Информатика и системы управления, 2012, № 2. с. 170-179.
[13] Григорьев Ю.А., Ермаков Е.Ю. Сравнение процессов обработки запроса к одной таблице в параллельной строчной и колоночной системе баз данных. ВестникМГТУ им. Н.Э. Баумана. Спец. выпуск; № 5, 2012, с. 31-45.
[14] Григорьев Ю.А., Ермаков Е.Ю. Оценка времени соединения двух таблиц в параллельной колоночной системе баз данных // Вестник МГТУ им. Н.Э. Баумана — 2012 - № 4. — С. 80-100.
[15] Daniel J. Abadi Query Execution in Column-Oriented Database Systems. [Электронный ресурс]. http://www.cs.yale.edu/homes/dna/papers/abadiphd.pdf (дата обращения 25.12.2011).
[16] Соколинский Л. E., Цымблер М. Л. Лекции по курсу «Параллельные системы баз данных»: [Электронный ресурс]. http://pdbs.susu.ru/ CourseManual.html (дата обращения 22.10.2011).
[17] Кузнецов С. СУБД с хранением данных по столбцами и по строкам: насколько они отличаются в действительности? [Электронный ресурс]. http://citforum.ru/database/articles/column_vs_row_store/ (Дата обращения 24.04.2012).
[18] Daniel J. Abadi, Daniel S. Myers, David J. DeWitt, and Samuel R. Madden. Materialization Strategies in a Column-Oriented DBMS In Proceedings of ICDE, 2007. [Электронный ресурс]. http://db.lcs.mit.edu/projects/cstore/abadiicde2007.pdf (дата обращения 25.12.2011).
[19] Daniel J. Abadi, Samuel R. Madden and Miguel C. Ferreira Integrating Compression and Execution in Column-Oriented Database Systems In Proceedings of ICDE, 2006. [Электронный ресурс]. http://db.lcs.mit.edu/projects/cstore/ abadisigmod06.pdf (дата обращения 25.12.2011).
[20] Бахвалов Н.С. Численные методы (анализ, алгебра, обыкновенные дифференциальные уравнения). - М.: Наука, 1973, 631 с.
[21] AIDA64 Extreme Edition. [Электронный ресурс] http://www.aida64.com/ product/aida64-extreme-edition/overview (дата обращения 08.04.2012).
[22] Спецификация теста TPC-H. [Электронный ресурс] http://www.tpc.org/tpch/ (дата обращения 24.04.2013).
Статья поступила в редакцию 24.06.2013
Ссылку на эту статью просим оформлять следующим образом:
Григорьев Ю.А., Ермаков Е.Ю. Анализ времени выполнения запроса в параллельном колоночном хранилище данных. Инженерный журнал: наука и инновации, 2013, вып. 11. URL: http://engjoumal.ru/catalog/it/hidden/1069.html
Григорьев Юрий Александрович — д-р техн. наук, проф. кафедры «Системы обработки информации и управления» МГТУ им. Н.Э. Баумана. e-mail: grigorev@bmstu.ru
Ермаков Евгений Юрьевич — аспирант кафедры «Системы обработки информации и управления» МГТУ им. Н.Э. Баумана. e-mail: JK.Ermakov@gmail.com