Научная статья на тему 'Математическая модель времени выполнения запроса в параллельном колоночном хранилище данных и пример ее использования'

Математическая модель времени выполнения запроса в параллельном колоночном хранилище данных и пример ее использования Текст научной статьи по специальности «Компьютерные и информационные науки»

CC BY
203
28
i Надоели баннеры? Вы всегда можете отключить рекламу.
Ключевые слова
ПАРАЛЛЕЛЬНЫЕ КОЛОНОЧНЫЕ ХРАНИЛИЩА ДАННЫХ / ПРЕОБРАЗОВАНИЕ ЛАПЛАСА-СТИЛТЬЕСА / СКРЫТОЕ СОЕДИНЕНИЕ

Аннотация научной статьи по компьютерным и информационным наукам, автор научной работы — Ермаков Евгений Юрьевич

В статье проанализированы существующие методы выполнения запросов в параллельном колоночном хранилище данных, в том числе специфичный для колоночных хранилищ план запроса со «скрытым соединением» В ыполнено сравнение среднего времени выполнения запроса со скрытым соединением и соединением вложенными циклами (NLJ).

i Надоели баннеры? Вы всегда можете отключить рекламу.
iНе можете найти то, что вам нужно? Попробуйте сервис подбора литературы.
i Надоели баннеры? Вы всегда можете отключить рекламу.

Текст научной работы на тему «Математическая модель времени выполнения запроса в параллельном колоночном хранилище данных и пример ее использования»

Ермаков Е.Ю.

МГТУ им Н.Э.Баумана, аспирант, JK.Ermakov@gmail.com

Математическая модель времени выполнения запроса в параллельном колоночном хранилище данных и пример

ее использования

КЛЮЧЕВЫЕ СЛОВА:

Параллельные колоночные хранилища данных, преобразование Лапласа-Стилтьеса, скрытое соединение.

АННОТАЦИЯ:

В статье проанализированы существующие методы выполнения запросов в параллельном колоночном хранилище данных, в том числе специфичный для колоночных хранилищ план запроса со «скрытым соединением» В ыполнено сравнение среднего времени выполнения запроса со скрытым соединением и соединением вложенными циклами (NLJ).

Введение

Являясь одними из наиболее значимых элементов ИТ-инфраструктуры предприятия, базы данных консолидируют информацию, необходимую для создания достоверных аналитических и управленческих отчетов. Они являются одними из крупнейших источников информации для современных аналитиков и, по оценке Gartner [1], в ближайшей перспективе останутся ключевым компонентом ИТ-инфраструктуры предприятий.

При оценке характеристик производительности на этапе проектирования базы данных необходимо учитывать особенности предметной области. Результаты исследований [2] показывают, что при расчете времени реакции информационной системы необходимо учитывать параметры приложений: алгоритмы, запросы к базе данных и т.д. Время обработки этих запросов достаточно велико и его доля в общем времени выполнения прикладных программ превышает 90%.

Методы анализа временных характеристик для параллельных строчных баз данных (Oracle, MS SQL Server и т.д.), учитывающих специфику запросов к базе данных уже разработаны и представлены в работах [2-6]. Но в настоящее время внедряются новые системы управления базами данных с иной организацией хранения данных, которые получили название параллельных колоночных баз данных [7-9]. Их первые внедрения при разработке больших баз данных, используемых при поддержке принятия решения, в частности в аналитических расчетах, свидетельствуют о почти 200-кратном сокращении объема ввода вывода по сравнению с

аналогичными строчными базами данных и значительном снижении времени выполнения запросов [8]. Это достигается за счёт того, что из базы данных читаются только те атрибуты (столбцы), которые участвуют в запросе, а также применяются эффективные методы сжатия столбцов [10].

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

В исследовательской работе, проводимой в МГТУ им. Н.Э. Баумана, указанная задача решается путем разработки моделей оценки времени выполнения запроса к параллельному колоночному хранилищу данных, учитывающих особенности колоночного хранения данных, состав и параметры выполнения запросов, структуру и наполнение хранилища, механизм распределения таблиц по процессорам системы, параллелизм выполнения запросов в узлах, режимы работы системы, структуру сложного многопроцессорного аппаратно-программного комплекса.

В статье рассмотрено специфическое для параллельных колоночных хранилищ данных «скрытое соединение» и получена оценка времени выполнения запроса к хранилищу на основе математические методов, предложенных авторами в статьях [11-14,18] с учетом особенностей выполнения запросов к колоночным базам данных.

Организация работы колоночной системы баз данных Под строчным хранением данных обычно понимается физическое хранение кортежа любого отношения в виде одной записи, в котором значения атрибута идут последовательно одно за другим, а за последним атрибутом кортежа в общем случае следует новый кортеж отношения. Таким образом, на физическом носителе отношение R представлено в следующем виде: [яц. а

21' ' Пп1-1 1 [а1т, а

где ¿ц -значение атрибута *ч в ]-м кортеже отношения Я,

1/ .....- ]-й кортеж отношения Я,

п - количество атрибутов отношения R, ш= ^(Я) - количество кортежей отношения Я.

В колоночных хранилищах значения одного атрибута хранятся последовательно друг за другом [1], т.е. на физическом носителе отношение R примет следующий вид.

(¿п.аи. .....«22' .....■■■ ^-т- ¿па- «*а.....¿тпК

где - -значение атрибута - в )-м кортеже отношения R, (н^.н^н^.....ат)1 - 1-й столбец (атрибут) отношения Я.

Каждая колонка, хранимая на диске, разделена на блоки определенного размера. Блок состоит из заголовка, размер которого пренебрежительно мал по сравнению с размером блока и непосредственно данных. При одном запросе к диску происходит чтение нескольких блоков, количество которых определяется параметром. Каждой записи в столбце сопоставляется ее позиция (номер строки). В большинстве современных колоночных БД [14] значения столбца упорядочиваются по позициям.

На логическом уровне колоночные и строчные СУБД идентичны, т.е. способны обрабатывать одни и те же SQL-запросы. Но отличия в физической организации хранения данных существенно влияют на реализацию процессов, протекающих при формировании плана выполнения запроса и его реализации.

В строчных СУБД план запроса представляет собой дерево, у каждого узла которого имеется один родитель и один (или два в случае пересечения) дочерних узла [15]. Реализация исполнителя планов базируется на следующих трех базовых парадигмах [15]: синхронный конвейер, итераторная модель, скобочный шаблон.

Более подробно изменения, вносимые в каждый из перечисленных элементов плана, рассмотрены в работах [11,15].

Организация параллельной обработки данных

Рис. 1. Генерация параллельного плана запроса

Основной формой параллельной обработки запросов в строчных и колоночных СУБД является фрагментный параллелизм. Подробно данный процесс рассмотрен в работах [2-4,16]. В соответствие с этой схемой запрос на языке SQL преобразуется в некоторый последовательный план. Данный последовательный план преобразуется в параллельный план, представляющий собой совокупность n идентичных параллельных агентов, которые реализуют те же операции, что и последовательный план (рис.1). Здесь n обозначает количество процессорных узлов. Это достигается путем вставки оператора обмена exchange в соответствующие места дерева плана запроса. На завершающем этапе агенты рассылаются на соответствующие процессорные узлы, где интерпретируются исполнителем запросов. Результаты выполнения агентов объединяются корневым оператором exchange на нулевом процессорном модуле.

Рассмотрим процесс параллельной обработки запроса, где выполняется соединение таблиц R и S базы данных (рис. 2). Q = R wv S - это логическая операция соединения (join) двух отношений (таблиц) R и S по некоторому общему атрибуту Y. В данном примере таблица R фрагментирована произвольным образом, а таблица S - по атрибуту соединения Y. На рис. 2 показано, что логический план выполнения соединения двух отношений тиражируется на 'n' процессоров в параллельной системе баз данных (на рисунке показаны 2 процессора). Далее происходит параллельная обработка на каждом процессоре соответствующих фрагментов таблиц R и S. Вследствие того, что таблица R не фрагментирована по атрибуту соединения, при последовательном чтении записей этой таблицы происходит их обработка в операторе exchange, осуществляющем разбор записи и её межпроцессорный обмен. Таблица S фрагментирована по атрибуту соединения и записи читаемые из фрагментов этой таблицы обрабатываются на каждом процессоре локально.

Наиболее распространенной системой классификации параллельных систем баз данных является система, предложенная Майклом Стоунбрейкером (Michael Stonebraker) [16]:

9.SE (Shared-Everything) - архитектура с разделяемыми памятью и дисками. 10.SD (Shared-Disks) - архитектура с разделяемыми дисками. 11.SN (Shared-Nothing) - архитектура без совместного использования ресурсов.

Обработка запроса к хранилищу данных в ПКБД

Процесс выполнения запроса к хранилищу данных, в частности, к хранилищу со звездообразной схемой часто включает следующие шаги: 1) выделить множество кортежей в таблице фактов, используя предикаты ограничений над одной или несколькими таблицами измерений; 2) выполнить некоторое агрегирование значений фактов, часто с

группировкой по атрибутам таблицы измерений. Таким образом, требуется выполнять соединения таблицы фактов и таблиц измерений для каждого предиката и каждой агрегатной группировки [17]. В качестве специфичного для колоночных баз данных плана запроса авторы работ [10,15] предлагают метод, названный ими методом скрытых соединений, который можно использовать в системах баз данных с хранением данных по столбцам для соединений таблиц баз данных со звездообразной схемой по атрибутам внешний-ключ/первичный-ключ. Это соединение с отложенной материализацией, но в нем минимизируется число значений, которые требуется извлекать не в порядке следования позиций.

При использовании метода скрытых соединений соединения выполняются в три этапа. Сначала каждый предикат применяется к соответствующей таблице измерений для извлечения списка ключей записей, удовлетворяющих данному предикату. Эти ключи используются для построения хэш-таблицы, которую можно использовать для проверки того, удовлетворяет ли предикату некоторое значение ключа. Пример выполнения первого этапа показан на рис. 3.

Хеш-таблица Customer

Применить Region= 'Asia' к таблице Customer

custkey region nation

1 Asia China

2 Europe France

3 Asia India

Применить Region= 'Asia' к таблице Supplier

suppkey reg io n nation

1 Asia Russia

2 Europe Spain

Хеш-таблица Supplier

Хеш-таблица Date

Рис. 3. Первый этап скрытого соединения

На следующем этапе хэш-таблицы используются для извлечения позиций тех записей из таблицы фактов, которые удовлетворяют соответствующему предикату. Для каждого значения столбца внешнего ключа таблицы фактов выполняется поиск в соответствующей хэш-таблице. Далее создаётся список всех позиций в этом столбце, значения которых удовлетворяют предикату. Затем списки позиций всех столбцов пересекаются. И создаётся список позиций таблицы фактов, которые соответствуют записям, удовлетворяющим исходному условию поиска. Пример выполнения второго этапа показан на рис. 4.

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

Применить year= '2013' к таблице Date

dateid year month

01012013 2013 01

02012013 2013 01

могут быть извлечены напрямую с использованием этого списка значений внешнего ключа.

Таблица фактов

orderkey custkey suppkey orderdate

1 3 1 01012013

2 3 4 01012013

3 2 1 01012013

4 1 1 02012013

5 2 2 02012013

6 1 3 02012013

Хеш-таблица ▼ Хеш-таблица Хеш-таблица

Customer Supplier Date

4

4

4

1 1 1 0 1 1 1 0

0 1 ЮГ Ç 1 1 ЮГ Ç 1 1 0 1 1Г

IT 1Г

Рис. 4. Второй этап скрытого соединения

Ç i =

custkey region

1 Asia

2 Europe

3 Asia

uppkey

Ç Ï =

suppkey region

1 Asia

2 Europe

orderdate

01012013

01012013 02012013

02012013 02012013

Ç ï =

01012013

02012013 X

dateid I year

01012013 2013

02012013 2013

Рис. 5. Третий этап скрытого соединения

Пример выполнения этого третьего этапа показан на рис. 5. Для таблицы Date столбец ключа не является отсортированным непрерывным списком, начинающимся с единицы, так что для него требуется выполнять полное соединение. Поскольку это соединение вида внешний-ключ/первичный-ключ, и все предикаты уже применены, гарантируется, что в каждой таблице измерений для каждой позиции окончательного списка позиций таблицы фактов будет обнаружен один и только один результат. Это означает, что на этом третьем этапе при соединении с каждой таблицей измерений получается одно и то же число результатов, так что каждое соединение может выполняться по отдельности, и результаты могут материализоваться в более поздней точке плана выполнения запроса.

Преобразования Лапласа-Стилтьеса времени выполнения запроса к таблице в строчной и колоночной системе баз данных

В [18] приведено преобразование Лапласа-Стилтьеса (ПЛС) времени выполнения запроса к хранилищу данных методом «скрытого соединения», получены формулы для #D (s), #M (s) ,#N (s) (т.е. для ПЛС времени обработки кортежей в ресурсах) для различных режимов функционирования системы баз данных и различных архитектурных решений. При выводе учитывались следующие особенности выполнения запроса в колоночной СУБД [11]:

• каждая колонка хранится на диске в своих блоках, где отдельная колонка представляет собой таблицу с кортежем (значение атрибута, позиция);

• последовательная и параллельная обработка запросов с поздней материализацией кортежей;

iНе можете найти то, что вам нужно? Попробуйте сервис подбора литературы.

• наличие компрессии данных (метод RLE);

• получение времени работы обслуживающих устройств на основе измеримых с помощью синтетических тестов показателей.

При этом рассматривались два режима работы [12]:

1. Пакетный режим (offline, система рассматривается как замкнутая).При данном режиме работы в колоночной системе баз данных обрабатываются пакеты запросов, В каждом пакете SQL-запросы выполняются последовательно (предполагается, что они связаны по данным: выходные данные одного запроса являются входными данными другого). Но запросы разных пакетов (по одному из каждого пакета) могут обрабатываться параллельно. Предполагается, что «узкое место» в данном режиме-дисковая система.

2. Режим «запрос-ответ» (online, система рассматривается как разомкнутая).При данном режиме работы предполагается, что i-ая рабочая станция обращается к j-ому запросу c некоторой интенсивностью. При условии, что эти входные потоки заявок являются пуассоновскими, время обслуживания в ресурсах распределено по экспоненциальному закону, а переход от ресурса к ресурсу выполняется по вероятности, модель обработки запросов можно представить в виде сети массового обслуживания. В этой сети обработку в узлах ресурсов можно представить в виде совокупности независимых СМО М/М/1 (это доказывается в теории массового обслуживания в виде теоремы разложения Джексона).

Сравнение среднего времени обработки запроса методом скрытого соединения и соединения вложенными циклами

Ниже приведено сравнение времени выполнения запроса к хранилищу данных для скрытого соединения и соединения методом NLJ[14]. Характеристики ресурсов (интенсивности обработки) были получены с помощью программы синтетических тестов AIDA64 [19]. Расчёты были выполнены при следующих значениях характеристик ресурсов.

1. Процессор - Intel Core i7-920 2.79GHz. Для выбранного процессора

измеренное значение числа процессорных циклов, выполняемых в секунду - |1р=2.79*109(1/с).

2. Внешняя память - Nd=250, диск 3.5'' Seagate Cheetah 15K.6 ST3146356FC; размер блока чередования (stripe size) - 0бч=64 Кб; среднее время поиска и чтения блока чередования с диска - tБч = подвода + tвращения/2 + QБч/Vчтения = 4 + 4/2 + 64/200 = 6.3 мс. Поэтому интенсивность чтения блоков с диска равна |1db= 1000/6.3= 160 (1/с), Pd=0.9.

3. Оперативная память - DDR3-1600 PC3- 12800. Интенсивность чтения одного байта информации из ОП равна |1м= 9586*1024*1024 (1/с).

В качестве примера был выбран аналитический запрос Q3 теста TPC-H [20]. Коэффициент sf теста определяет объем обрабатываемых данных.

График зависимости времени выполнения запроса от количества узлов для скрытого соединения и соединения методом NLJ для архитектуры SE представлен на рис.7. Из графика видно, что метод скрытого соединения превосходит по скорости метод NLJ, причем соотношение времени выполнения сохраняется при изменении количества узлов.

■ Скрытое

соединение

■ Метод NLJ

JJJjJjjjjj^,,,,...........

1 2 3 4 5 б 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30

Рис 7. Зависимость времени выполнения запроса для различных методов соединения при

архитектуре SE 0.01).

На рис.8 приведена зависимость времени выполнения запроса для различных методов соединения и архитектур в зависимости от коэффициента sf теста ТРС-Н. При увеличении объема обрабатываемых данных время обработки при использовании метода N^1 увеличивается

быстрее, чем при методе скрытого соединения.

0,01 0,02 0,03 0,04 0,05 0,06 0,07 0,08 0,09 0,10

Рис 8.. Зависимость времени выполнения запроса для различных методов и архитектур в зависимости от коэффициента sf теста TPC-H (п=20)

Заключение

1. Проанализирован способ выполнения запросов в параллельном колоночном хранилище данных. Рассмотрен специфичных для колоночных систем процесс «скрытого соединения» (invisible join).

2. Получено преобразование Лапласа-Стилтьеса (ПЛС) времени выполнения запроса со скрытой материализацией. Рассмотрены варианты этого преобразования для различных архитектур параллельных систем баз данных.

3. Проведено сравнение времени выполнения запроса к хранилищу данных для скрытого соединения и соединения методом NLJ, показано превосходство метода скрытого соединения.

4. Полученное соотношение увеличения скорости выполнения запроса (в 2.75 раза) соответствует экспериментально полученному в работе [15] значению.

5. Предполагается продолжить исследования и получить модель адаптации полученной ПЛС к конкретной реализации ПКХД.

Литература

1. Андрей Арсентьев. Хранилища данных становятся инфраструктурным компонентом №1. CNews аналитика. 2010. [Электронный ресурс]. [http://retail.cnews.ru/reviews/free/BI2010/articles/articles6.shtml]. Проверено 27.06.2011.

2. Григорьев Ю.А., Плутенко А.Д. Теоретические основы анализа процессов доступа к распределенным базам данных. Новосибирск: Наука, 2002. - 222 с.

3. Ю.А. Григорьев, В.Л. Плужников. Оценка времени выполнения запросов и выбор архитектуры параллельной системы баз данных. MГТУ2009.

4. Григорьев Ю.А., Плужников В.Л. Mодель обработки запросов в параллельной системе баз данных // Вестник MHY им. Н.Э. Баумана. - 2010. - № 4. - С. 78-90.

5. Григорьев Ю.А., Плужников В.Л. Оценка времени соединения таблиц в параллельной системе баз данных// Информатика и системы управления. - 2011. - № 1. - С. 3-16.

6. Григорьев Ю.А., Плужников В.Л. Анализ времени обработки запросов к хранилищу данных в параллельной системе баз данных // Информатика и системы управления. - 2011. - № 2. - С. 94-106.

7. Michael Stonebraker, Ugur Çetintemel. «One Size Fits All»: An Idea Whose Time Has Come and Gone. / Перевод Сергея Кузнецова, 2007 г.: [Электронный ресурс]. [http://citforum.ru/database/articles/one_size_fits_all/]. Проверено 27.06.2011.

8. Michael Stonebraker, Chuck Bear, Ugur Çetintemel, Mitch Cherniack, Tingjian Ge, Nabil Hachem, Stavros Harizopoulos, John Lifter, Jennie Rogers, and Stan Zdonik One Size Fits All? - Part 2: Benchmarking Results. 3rd Biennial Conference on Innovative Data Systems Research (CIDR), January 7-10, 2007, Asilomar, California, USA. / Перевод Сергея Кузнецова, 2007 г.: [Электронный ресурс]. [http://citforum.ru/database/articles/one_size_fits_all_2/]. Проверено 27.06.2011.

9. Michael Stonebraker. My Top 10 Assertions About Data Warehouses. / Перевод Сергея Кузнецова, 2010 г.: [Электронный ресурс]. [http://citforum.ru/gazeta/166/]. Проверено 27.06.2011.

10. Michael Stonebraker, Daniel J. Abadi, Adam Batkin, Xuedong Chen, Mitch Cherniack, Miguel Ferreira, Edmond Lau, Amerson Lin, Samuel R. Madden, Elizabeth J. O'Neil, Patrick E. O'Neil, Alexander Rasin, Nga Tran, and Stan B. Zdonik: C-Store: A Column-Oriented DBMS [Электронный ресурс]. [http://www.cs.yale.edu/homes/dna/pubs/displaypubs.cgi/]. Проверено 22.10.2011.

11. Григорьев Ю.А., Ермаков Е.Ю. Mодель обработки запросов в параллельной колоночной системе баз данных // Информатика и системы управления. - 2012. - № 1. - С. 3-15.

12. Григорьев Ю.А., Ермаков Е.Ю. Mодель обработки запроса к одной таблице в параллельной колоночной системе баз данных и анализ ее адекватности // Информатика и системы

управления. - 2012. - № 2. - С. 170-179.

13. Григорьев Ю.А., Ермаков Е.Ю. Сравнение процессов обработки запроса к одной таблице в параллельной строчной и колоночной системе баз данных // Вестник МГТУ им. Н.Э. Баумана. - 2012. - Специальный выпуск № 5. - С. 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. Соколинский Л. Б., Цымблер М. Л. Лекц ии по курсу "Параллельные системы баз данных": [Электронный ресурс]. [http://pdbs.susu.ru/CourseManual.html]. Проверено 22.10.2011.

17. Кузнецов С. СУБД с хранением данных по столбцами и по строкам: насколько они отличаются в действительности? [Электронный ресурс]. [http://citforum.ru/database/articles/column_vs_row_store/]. Проверено 24.04.2012.

18. Григорьев Ю.А., Ермаков Е.Ю. Анализ времени выполнения запроса в параллельном колоночном хранилище данных // Вестник МГТУ им. Н.Э. Баумана - 2013

19. AIDA64 Extreme Edition. [Электронный ресурс] [http://www.aida64.com/product/aida64-extreme-edition/overview] Проверено 08.04.2012.

20. Спецификация теста TPC-H. [Электронный ресурс] [http://www.tpc.org/tpch/] Проверено 24.04.2013.

i Надоели баннеры? Вы всегда можете отключить рекламу.