The efficiency of a large conservative type DBMS on a cluster platform

Raikhlin Vadim Abramovich Doctor of Physics and Mathematics Professor, Department of Computer Systems, Tupolev Kazan National Research Technical University 1420111, Russia, respublika Tatarstan, g. Kazan', ul. K. Marksa, 10 no-form@evm.kstu-kai.ru Minyazev Rinat Shavkatovich PhD in Technical Science Associate Professor, Department of Computer Systems, Tupolev Kazan National Research Technical University 1420111, Russia, respublika Tatarstan, g. Kazan', ul. K. Marksa, 10 txf13@mail.ru

Klassen Roman Konstantinovich Postgraduate Student, Department of Computer Systems, Tupolev Kazan National Research Technical University 420111, Russia, respublika Tatarstan, g. Kazan', ul. K.marksa, 10 klassen.rk@gmail.com

– Clusterix, Clusterix-M, Clusterix-G– названия затрагиваемых в статье проектов консервативных СУБД на кластерной платформе, принятые разработчиками этих проектов.

– MySQL – применяемая в этих проектах инструментальная СУБД.

– PerformSys («ядро на запрос», «узел на множество запросов») – перспективная технология консервативных СУБД.

– GPU(Graphics Processing Unit) – сопроцессор, широко применяемый как ускоритель трехмерной графики. Используется и при выполнении обычных вычислений – подход GPGPU (General-Purpose GPU).

– CPU – центральный процессор.

– TPC(Transaction Processing Performance Council) – Совет по производительности обработки транзакций.

– TPC-H – один из тестов производительности систем принятия решений.

Проблема масштабируемости по числу узлов кластера и повышения производительности всегда была и остается одной из серьезнейших проблем параллельных СУБД ^[1-4]. В настоящее время имеется немалое число разработок таких СУБД на платформе вычислительных кластеров. Большинство из них осущест­вляет под­держку работы internet-сер­висов, выполняющих сра­в­­нительно простые операций типа selectи insertнад динамически изменяемыми базами данных. Причина в том, что повыше­ние скорости обработки сложных запросов до сих пор проблематично ^[5]. Наше рассмотрение ориентировано на по­строение парал­лельных СУБД кон­сер­ва­тив­ного типа (с эпизо­ди­че­с­ким об­но­вле­нием дан­ных в специаль­но вы­деляемое вре­мя) больших объе­мов (до единиц TB). Его актуальность определяется тенденция­ми интел­лектуальной обработки ин­фор­ма­ци­он­ных мас­­­­­­­си­­­­­­вов. При­­­­ме­ром тому является проект специа­лизи­ро­ванной системы SciDB для обра­бот­ки на­уч­­ных дан­ных (резуль­татов испы­та­ний, наблюде­ний за со­стоя­нием среды и др.) ^[6-8]. Для них характерен вы­­сокий удель­ный вес имен­но сложных запросов типа select – project – join, опери­рую­щих множеством таб­лиц с большим числом опера­ций соединения join. Такие базы данных приходится хешировать по узлам кластера.

Поэтому единственно приемлемым планом обработки запросов оказывается регулярный ^[9] (рис.1) по схеме

СЕЛЕКЦИЯ (σ) – ПРОЕКЦИЯ (π) – СОЕДИНЕНИЕ (σ_θ(R x S)) .

Здесь < x > – декартово произведение, селектирование в операции соеди­нения ведется по θ‑соответствию корте­жей отношений R и S. По условиюсо­еди­не­ние всегда естественное и проводится по полям первичного ключа. При использовании стратегии «множество узлов кластера – на один запрос» база данных оказыва­ет­ся распределенной по узлам. Получение любо­­го промежуточного R_i' и любого временного R_B(i-2) отно­ше­ний происходит параллельно. При этом теоретически возможно совме­ще­ние обоих процес­сов, если за время съема с дисков и пред­вари­тель­ной обра­ботки (селекции с проекцией) исходного отношения R_iуспева­ет сформироваться временное отношение R_B(i-2). Для целей исследования была разработан­а натурная модель – СУБД Clusterix^[10].

Функциональная характеристика. Обработка запросов – 2-уровневая. На ниж­нем уровене выполня­ются опера­ции селекции (σ) и проекции (π) над исходными отношениями R_iбазы данных. Результатом обработки этого уровня является промежуточное отношение R_i'. На верх­нем уровне реализу­ется операция соедине­ния R_Bi–1 = R_i' ►◄ R_Bi–2 = π (σ_θ(R_i'xR_Bi–2)), где R_Bi–1 и R_Bi–2 – временные отношения как результаты соеди­нений в i- и в (i-1)-шагах соответственно. Фильтрация на нижнем уровне значительно снижает объемы данных, передаваемых на верхний уро­вень.

Отношения БД распределены по дискам на процессорах нижнего уровня (IO_r) с примене­ни­ем хеш-функции к первичному ключу для каждого кортежа отношения. Требованию равно­мер­ного распределения кортежей хорошо удовлетворяет выбор в качестве нее функции деления по модулю ^[11]. Основание деления – число процессоров нижнего уровня (n_IO). Оста­ток от деления r однозначно определяет номер страницы (процессора IO_r), куда будет распределен кортеж. Процес­соры верхнего уровня обработки запроса называются процессорами JOIN. Хеш-функция, использованная в Clusterix, имеет следующий вид:

hash=((key_field1 mod M) + (key_field2 mod M) + … + (key_fieldP mod M)) mod M,

где P – количество полей в первичном ключе; M = n_IO– основание деления по модулю; mod – операция деления по модулю. Как показали эксперименты на примере теста TPC-H (M=2,3,4,6,8,12,16,18,24), данный подход обеспечивает достаточно равномерное распределение данных по страницам. Хеширован­ные страницы хранятся на узлах IO_r в виде отношений базы данных tpchK, где K = r.

Кроме исполнительных процессоров (IO_r и JOIN_j), есть еще два процес­со­ра. Процессор УПР реализует функции мониторинга и управления осталь­ными процессорами системы. Для реализации функций объединения результатов обработки с уровня JOIN введен процессор SORT. Он дополнительно выпол­няет функции агрегации (SUM(), AVG(), MAX(), MIN() и др.) и сортиров­ки ре­зультата предшествующей операции соединения. В Clusterix реализован вариант сов­местной работы процессоров УПР и SORT на Host ЭВМ. Работа на уровне файловой системы, системных буферов, алгоритмов доступа к данным, работы с индексами и т.п. реализу­ется с помощью стандартной СУБД MySQL.

Система реализует потоково-конвейерный механизм обработки запросов. Конвейерность достигается за счет совмещения работ на нижнем, верхнем уровнях обработки и на уровне SORT (рис.2). Так реализуется вертикальный параллелизм. Его особен­ностью является совмещение последней операции на уровне JOIN для одного запроса и первой операции на уровне IO для следующего.

В Clusterix реализуется и горизон­тальный параллелизм, который до­сти­га­ется параллельной работой нескольких процессоров одного уровня над разными частями данных одного и того же запроса. Применение динамической сегментации промежуточных и временных отношений позволя­ет реализовать па­раллель­ное выполнение операции соединения на множестве процес­соров JOIN_j. Для обеспечения надежной работы системы на всех уровнях применена барьерная синхронизация.

Программная система. Параллельная СУБД Clusterixпредставляет композицию четырех програм­­­м­ных модулей: mlisten, msort, irun, jrun. Модуль mlistenреализует функцию логического процессора УПР, модуль msort– SORT, модуль irun– IO, модуль jrun– JOIN. Модули mlisten и msortфункционируют на Host. Назначение модуля mlisten: получение входного запроса от пользователя и передача результатов обработ­ки обратно; пересылка команд управления модулям irun, jrun, msort; мониторинг работы модулей системы; сбор статистической ин­форма­ции. Модуль msortпредназначен для выпол­нения операции объединения результатов обработки JOIN с последующим выполнением операций агрега­ции и сортировки результата. Назначение модуля irun – выполнение операций селекции и про­ек­ции над исходными отно­шениями базы данных. На каждом узле уровня IO располагается своя страница исходной БД. Номер этой страницы определя­ется текущей конфигурацией и присваивается ей при запуске системы. Поэтому каждая стра­ница (и соответствующий ей модуль irun) имеет уникальный номер. То же – и с модулем jrun, который выполняет операции соединения. Количество модулей irunи jrunдля любой конфигурации одинаково. Число физи­ческих процессоров, на которых функционируют программные модули irunи jrun, может быть различно.

Моделирование процессов, протекаю­щих в Cluste­rix, выполнялось при разном числе узлов кластера (физических процессоров) и разном распределении в них программ­ных модулей (логических процессоров). Здесь и далее понятия «логи­че­ский процессор» и «програм­мный модуль» (irunили jrun) использу­ются как синонимы. На каждом физическом процессоре могут выпол­няться неско­лько логических. Общее количество физических процессо­ров в кластере (включая Host) N=2n+1, где n=1,2,… Величина 2n = p+q, p и q – числа физических процессоров IO и JOIN. В дальнейшем фигурирует их отношение k = q/p.

Рассматривались три типа конфигураций Clusterix: «линейка», «сим­­метрия» и «асимметрия». В конфигурации «линейка» (с условным зна­че­нием k=0) на каждом физическом процессоре кластера выпол­ня­ют­ся оба логических процессора: irunи jrun. Модули функционируют в режиме разделения времени при усло­вии барьерной синхронизации. Сихронизация выполня­­­­ется передачей коротких сетевых сообщений и осуществляется модулем mlisten. Каждый узел кластера имеет устройство внешней памяти. Для конфигурации «симметрия» характерна реализация каждого логического процессора на отдель­ном физическом процессоре. Любому узлу, на котором выпол­няется модуль irun, соответствует узел с моду­лем jrun. Числа узлов JOIN и IO одинаковы: p=q=n, k=1. Конфигурации «асимметрия» предназна­чена для моделирования таких нагрузок, при которых основная часть работ приходится на узлы IO. Поэтому количест­во физических процессоров IO больше по сравнению с числом физических процессоров JOIN. На каждом физиче­ском процессоре JOIN выполняется несколько логических процессоров jrun. Исследова­ния показа­ли, что коли­чество совместно работающих логических процессоров jrunна одном узле не должно превышать трех. Поэтому здесь k=1/2, 1/3.

Запросы, на которых проводится те­сти­рова­ние, размещаются в специ­альном интерфейсном отношении queryсистемной базы данных в оттранслированном виде для каждого из трех программных модулей: irun, jrun и msort. Программа-кли­ента посылает номер SQL-запроса. Модуль mlistenзапускает для обра­ботки запроса функцию-поток Процесс h, где h – порядковый номер запроса в системе. Процесс h считывает па­кет команд запроса из от­ношения queryи передает его соот­вет­ствующим мо­дулям для исполнения.

Анализ экспериментальных данных. В качестве представительского теста (ПТ) использовался ограничен­ный тест TPC-H из 14 запросов, не содержащих операций записи. Далее приводятся результаты модельного эксперимента на натурной модели – СУБД Clustre­rix, полученные для двух кластерных платформ ^[12,13]:

– Платформа 1. Host – cервер Intel Core 4 Xeon 5320 (2,4 GHz, RAM 4GB). Исполнительные узлы – 13 ПК Intel Core 2 Duo 6320 (1,87 GHz, RAM 3GB, жесткий диск SATA 125GB); локальная сеть Gigabit­Ether­net. На каждый компьютер установ­лена операцион­ная система Linux. Все процессоры дополни­тельно оснащены СУБД MySQL.

– Платформа 2. Вычисли­тель­ный кластер фир­мы SUN из 22 узлов 2 Quad-core Intel Xeon E5450 CPU/1,87GHz/32GB. Интерконнект между узлами – Gigabit­Ethernet/Infini­band 4X (20Gbps DDR) с 24-порто­выми коммутато­рами Cisco. Дисковая под­система узла – SAS диски XRB-SS2CD-146G10KZ с пропускной спо­соб­ностью 300 МB/s. Как и ранее, – Linux, MySQL.

На рис.3a,b приведены экспериментальные зависимости производительно­сти, полученные усреднением на 5 вариантах перестановок запросов ПТ для плат­формы 1 и разных объемов баз данных.

Обозначим: h_G – граница масштабируемости по числу узлов h, m_G – граничное число страниц. Ха­рактерно, что для любой конфи­гурации при h = h_G= (1+k)m_G производительность кластера всегда максимальна. Эту закономерность подтверждают и ранее проведенные исследования для случая одноядерных узлов ^[14,15]. Заметим, что параметр m_Gзависит от используе­мой платформы и, при неизменных ПТ и схеме БД, рас­тет с увеличением V_БД. Граница масштабируемости максимальна для симметрии: h_G^сим = 2m_G. Но переход от «линейки» к «симметрии» при неизменной нагрузке не приводит к существен­ному увели­чению максимума производительности. Для принятого ПТ конфигурация «линейка» оказыва­ет­ся наиболее эффективной.

Случаю 2-процессорных SMP-узлов отвечает пла­т­форма 2. По ассоциации с пред­ыду­щим ограничимся для нее исследованием конфигура­­ции «линейка». На рис.4a показан полученный для «ли­­нейки» гра­фик зависи­мо­сти време­ни T (сек.) вы­­полнения ПТ от числа рабочих узлов кластера (h) в случае V_БД =5,4GB . Видимый порог масштабируемости h_G =7-8.

Наличие двух процессоров в узле позволяет существенно улучшить масш­та­бируемость «линейки» и повы­сить ее максимальное быстродей­ствие на гра­нице масштабируемости. Это достигается установ­кой на каж­дый SMP-узел вычислительного кластера двух серверов MySQL. Один из них связан с процессами IO, другой – с процессами Join. В итоге появ­ляется еще одна конфигурация, названная «совмещенная симметрия». Для сравнения производительности конфигураций «линейка» и «совмещенная симметрия» при разном числе узлов проведена обработка последовательности запросов как конкатенации трех перестановок ПТ. Полу­ченные результаты представлены на рис.4b. Тройное увеличение длины и соответствующее изменение характеристики внешней нагрузки нового теста привело к снижению величины h_G для «линейки» с 7 до 5. Конфигурация «совмещенная симметрия» показывает h_G = 7 с падением T_min на 25% в сравнении с «линейкой».

В процессе исследований конфигурации «линейка» дополнительно установлены ^[16] факты: 1) значительного («в разы») временного доминирования задержек барьерной синхронизации над всеми другими задержками в системе вблизи порога масштабируемости; 2) резкого нарастания задержек на всех этапах обработки при h ≈ 1,5m_G; 3) критичности системы к использованию чрезмерного числа узлов в связи с ростом порога масштабируемости при увеличении объемов обрабатываемых баз данных. Интенсивная динамическая сегментация при чрезмерном росте h приводит к перегрузке по интерконнекту и, как следствие, к «зависанию» системы.

Переход к мультикластеризации, когда на одном доста­точ­но мощном вычислительном кластере реали­зуется множество одновре­менно ра­бо­та­ющих СУБД Clusterix с репликацией между ними консер­ва­тив­ной базы дан­ных, должен способ­ствовать росту произво­дительности си­с­темы в целом. Такой переход означает изменение идеологии обработки запро­сов в кластерной системе: от «множества маломощных узлов на один запрос» к одному мощному узлу на каждый запрос». При этом «мощный узел» реализуется как монокластер – компонент кластера в целом с установкой на него системы Clusterix. Число узлов монокластера отвечает грани масштабируемости.

Исследование вопро­сов мультиклаcтеризации проводилось на модифицированной натурной модели – СУБД Clusterix-M ^[13]. Host (главная ЭВМ) включает модуль ROUTER, который распределяет по­ток запросов, поступающих от N кли­­­ентов между n монокластерами-компо­нентами. Поддерживаются два вида очередей запросов – внутренних(в монокластерах) и внешней(в ROUTER). По условию запрос не покидает своей очереди до окончания его обра­ботки. Оче­ред­ной запрос от каждого пользователя поступает на вход сервера СУБД сразу, как будет получен ответ на предыдущий запрос. Поэтому в лю­бой момент времени суммарное число запросов L, находящихся в сервере, L = N. Суммарная длина всех внутренних очередей Ɩ_n= r∙n ≤ N, r≥1. Длина внешней очереди L–Ɩ_n ≥ 0.

Основная задача балансировки нагрузки в мультикластере со­сто­ит в нахождении такого способа распределе­ния запросов между мо­нокластерами, который минимизирует (в среднем) время ожидания ответа на вновь по­сту­пивший запрос и разброс этого времени. Круговое распределение – наиболее простой и, как показали исследо­вания, достаточно эффективный метод балансировки нагрузки мульти­кла­сте­ра. Принятое название об-условлено тем, что первые Ɩ_n запросов распреде­ля­ются по монокластерам-ком­по­нен­там в поряд­ке мест, за­нимае­мых ими в об­рабатывае­мой после­дова­тель­ности:

В дальнейшем всякий раз пополняется та из внутренних очередей, ко­торая первой завершила обработку своего 1-запроса. Считается, что в про­цес­­се ра­бо­ты си­стемы значение Ɩ_n неизменно. По оконча­нии об­­ра­ботки любого 1-запроса освободившееся мес­то занимает очередной зап­рос из внеш­­ней очереди. И в тот же момент на вход СУБД поступает новый запрос. Проведенными исследованиями установлено, что наилуч­шее решение сформулированной ранее задачи балансировки нагрузки мультикластера круго­­вым способом обеспечивает выбор значения r = 2.

Преимущества мультикластеризации подтверждают результа­ты про­­­­ве­ден­ного срав­нительного тести­рова­ния равносложных однокластер­ных и мно­го­­кла­с­терных архи­те­ктур на платфтормах 1 и 2 (см. раздел 1). Эксперимент проводится на тестовых базах данных объемами V_БД = 1GB и 5,4GB. Для обе­их пла­т­­форм в случае мультикластера запросы распре­де­ля­лись между моно­кла­стерами по «кру­­говому» алгоритму со зна­чением параметра r = 2. Подсистемой сбора стати­стической инфор­ма­ции СУБД Clusterix фиксиро­ва­лось сред­нее время T выполне­ния ПТ по пяти его переста­нов­кам. Сначала обрабатывалась база данных объемом 1GB на плат­форме 1. Мо­но­кластеры мультикластерной архи­тек­туры конфигурирова­лись как «линей­ка» с числом узлов h_М ≅ h_G=3 (см. рис.3a). Результаты те­сти­рования показаны на рис.5a. При переходе от одно­кла­стер­ной архитек­ту­ры к рав­нослож­ной ­мультикластерной повыша­ется и масш­таби­руе­мость, и производительность.

Затем для платформы 2 была проведена обработка по­сле­дова­тельности как конкатенации трех пере­ста­но­вок запро­сов ПТ с объемом базы данных 5,4GB (рис.5b). Монокла­с­те­ры-ком­поненты кон­фигу­риро­ва­лись как «совмещенная сим­мет­рия», че­му соответствует h_G=7 (рис.4b). Варь­­и­ро­валось ко­­­личество монокла­сте­ров n и число их уз­лов h_m. В случае h_m= 4 наблюдался рост масштабируемости муль­ти­кластера по сра­в­нению с однокластерной систе­мой в 2,3 раза; ­­­­при h_М = 6 – более чем в 2,6 раз. Степень роста производительности на пороге масшта­би­руемости – в 2,4 и не менее чем в 3 раза соответственно.

До сих пор при работах с базами данных мало используется вычислитель­ный потенциал современ­ных многоядерных процессоров. Примером мо­гут служить рассмотренные реализации СУБД Clusterixи Clusterix-M на SUN-кла­­с­те­ре с многоядерными узлами. Использование таких узлов позволяет по иному подойти к решению про­блемы создания мощного узла на основе технологии MySQL (либо PostgreSQL). Самостоя­тель­ное применение СУБД MySQL последних версий поз­воляет полностью исполь­зовать ре­су­р­сы многоядерных узлов с реализацией монокластера на одном узле (стратегия «один узел кластера на множество запросов»). В работе ^[17] удалось обе­спе­чить 100% загрузку всех ядер при специальной настройке MySQL 5.6.

Полученный на платформе 2 при новых услови­ях эксперимента (ПТ – случайная последователь­ность из 800 запросов на множестве запросов ограниченного теста TPC-H), определенной роуте­риза­ции в узле и ограничении V_БД размерами оперативной памяти ОП узла (вся БД хранится в ОП) график зави­симости вре­мени выпол­не­ния ПТ в минутах от количества узлов в си­сте­ме показан на рис.6.

Рис.6. График среднего времени выполнения ПТ

Наблюдается снижение T_minна 25% в сравне­нии с конфигурацией «сов­ме­щенная симмет­рия» (рис.4b) при неизменном h_G=7, прежнем V_БД = 5,4 GB и более чем на порядок большем числе обрабатываемых запросов. Но при значительных V_БД >V_ОП такой подход уже неприменим. Здесь, аналогично Clusterix, необходимо приме­нять хеширование БД на множестве узлов кластера с использованием регулярного плана бработки запросов.

Графические ускорители (GPU) уже применяются для ускорения работы СУБД CoGaDb ^[18], как рас­ширение PG-Storm для Postgres ^[19] и др. Использование GPU позволяет существенно снизить время выполнения отдельных операций. При V_БД ≤ 3GB вся БД может храниться в глобальной памяти GPU (6GB для GPU Fermi). Тогда выполнение сервисных функций (прием запросов, их синтаксический анализ и др.) возлагается на CPU, а обработкой запросов будет заниматься только GPU. Эффективность такой СУБД может быть до­статочно высока. При значительных V_БД необходимость обмена данными с GPU существенно снижа­ет производитель­­­ность. Скорость передачи данных по шине PCI-e значительно ниже, чем скорость обмена с оперативной памятью. Так, скорость чтения/записи для 3-канальной оперативной памяти типа DDR3-1600 составляет 38,4 GB/s ^[20], в то время как для шины PCI-e 2.0x16 – 6,4 GB/s ^[21]. Именно по этой причине достигнутый в ^[22] рост производительности сервера БД от использования GPU при обработке достаточно простых одиночных запросов не превысил 40%. Далее рассматривается возможный подход к использованию GPU-акселераторов на уровне IO в случае хранения распределенной базы данных в оперативной памяти узлов в сжатом виде, передачи по сети сжатых отношений R_i' и возможно максимальной загрузке ядер многоядерного процессора на уровне JOIN с применением в нем GPU-акселерации для разжатия поступающих данных.

Сжатие баз данных. Сжатая база данных сохраняется в оперативной памяти узла. Разжатие данных вносит дополнительную задержку в обработку данных на GPU. Эта задержка частично нивелирует выигрыш во времени передачи. Различают СУБД, ориентированные на хранение данных по строкам и по столбцам. Лучшие показатели по сжатию име­ют СУБД второго типа. Этот вопрос детально исследован в ^[23]. Сжатая база данных разделена на блоки. Под бло­ком данных далее понимается часть сжатого столбца (либо набор «коротких» столбцов) с объемом разжатых данных, равным объему буфера разжатых данных GPU. Алгоритм подготовки данных для сжатия следующий:

1. Найти самое «длинное» поле (длиной RS) в обрабатываемом отношении R.

2. Найти в соответствующем столбце (столбцах) количество записей RC, которое гарантированно умещается в отведенной памяти, RC=[BS/RS], где BS – объем памяти, отведенной для разжатых данных в графическом ускорителе.

3. Выдавать из отношения R данные по столбцам для сжатия с шагом RC.

По условию к каждому IO-узлу по шине PCI-e подключаются 2 графических процессора GPU 1 и GPU 2. Запрос поступает в систему «разбитым» на подзапросы согласно регулярному плану обработки (см. ранее). Для каждой таблицы, участвующей в обработке, проецируется набор колонок, необходимых для выполнения операций «select». В графические укорители GPU 1 и GPU 2 по-блочно последовательно передаются колонки одной таблицы. Пока выполняется расжатие, селектирование одного блока и его сжатие в GPU 1, следующий блок передается в GPU 2 и наоборот. Сжатые результаты возвращаются в хост-память. И так для всех отношений, участвующих в обработке каждого запроса.

Был проведен эксперимент с целью сравнения времен, затрачиваемых на простое копирование, с сум­мой времен, необходимых для копирования данных, сжатых по алгоритму RLE (Run Length Encoding) ^[24], и их разжатия в GPU. Эксперимент проводился на базе вычислительного узла с следующими характеристиками: Quad-core Intel Core i5-4670K CPU/2,5GHz/ 24GB RAM (DDR3-1600 в двухканальном режиме), 64-битная ОС Windows 10, дисковая подсистема узла – SSD SV300S37A/ 120GB с пропускной способностью 450 МB/s, GPU – Nvidia GTX 770 (с объемом памяти 2GB GDDR5).

Наибольшая эффективность передачи данных была достигнута для коэф­фициента сжатия K = 4-5. При бóльшем сжатии увеличивается время разжатия данных, которое может превысить время обычного копирования. В табл.1 показан процент увеличения эффективности передачи сжатых данных (K = 4 и 5) с после­ду­ющим разжатием по сравнению с простым копированием. Как видно из таблицы, при передаче небольшого объема данных простое копирование оказывается быстрее. При объемах >12 Мбайт предварительное сжатие дает ускорение в окрестности 30% (примерно в 1,5 раза). Для сотен Мбайт можно ожидать ускорение до 40%.

Таблица 1. Изменение эффективности передачи данных

Сравнительные оценки времени выполнения операций «select-project» и «join». Используется прежняя платформа, но без GPU. В качестве инструментальной была выбрана СУБД MySQL 5.7. Для запросов прежнего ПТ были сформированы загрузочные модули «select-project» (по каждому R_i) и «join» (по каждому запросу в целом). При этом все операции «project» были «опущены вниз». Объем тестовой БД составил 1GB. Она предварительно загружалась в оперативную память. Сравнивались времена, затрачиваемые на реализацию всех операций «select-project» и единой процедуры «join» по каждому запросу ПТ (см. ниже; ее последовательное выполнение согласно регулярному плану рис.1 оказывается вдвое медленнее), со временами с выполнением этих запросов в целом СУБД MySQL 5.7. Эта процедура выполнялась по следующему алгоритму:

1. Создание промежуточных отношений в памяти MySQL для хранения результата «select-project».
2. Индексация промежуточных отношений.
3. Выполнение операции R₁′join (join R₂′(join R₃′( … ))) … ).

Полученные результаты представлены в табл.2

Таблица 2. Сравнение времен на реализацию по-отдельности операций «select-project», «join»и запроса в целом

Как следует из табл.2, значения t_Σ^σ,π(кроме запросов № 1, 13) и t_Σ^join (кроме запросов № 12, 14) превышают t_общ. Это объясняется тем, что MySQL 5.7 оптимизирует исполнение запросов. Усредненные значения t_общ/t_Σ^σ,π= 0,556 и t_общ/t_Σ^join = 0,571 примерно одинаковы: t_Σ^join /t_Σ^σ,π =0,975. В частности, полученный результат позволяет сделать интересный вывод относительно перспективной стратегии «множество запросов на один узел кластера» с репликацией БД по отдельным узлам, ориентированной на работу с консервативными базами данных умеренных объемов – до 100GB , не превышающих объем оперативной памяти узла (по условию онне пре­вышает 128GB): переход к GPU-кластерам с использованием регулярного плана обработки запросов и ада­птацией инструментальных СУБД к такой платформе в этом случае неконкурентоспособен, независимо от ме­ста реализации «select–project»- и «join»-обработок: на CPU или GPU. Здесь целесообразна разработка специали­зированных СУБД с оптимизацией запросов применительно к использованию графических ускорителей ^[25].

Сжатие данных в результате «select-project»-обработки – полезное для дальнейшего знание. При подсчете объема несжатых данных для любого из рассматриваемых запросов, определялась длина каждого поля каждой строки всех таблиц, участвующих в обработке запроса, и все полученные длины суммировались. Подсчет выполнялся средствами MySQL путем модификации запросов. Пример модификации запроса №3:

Здесь O' – один из подзапросов «select – project», полученных после претрансляции этого запроса; O' LENGTH – запрос для подсчета объема возвращаемых данных. Результаты измерений объемов информации необходимой для обработки запросов приведены в табл.3.

Таблица 3. Объемы данных для обработки запросов TPC-H

В этой таблице: – полный объем отношений, необходимый для выполнения запроса; – сумма объемов тех же отношений после уменьшения объема данных с использованием условий выборки из запроса (секции where). Имеем, в сред­нем, примерно 7-крат­ное уменьшение объема данных.

Анализ для простейшего случая. Рассмотрим пример обработки системой рис.7 с двумя исполнительными узлами (узлы: 1 – IO и 2 – JOIN) и одним управляющим (Mgm) представительского теста ПТ из 14 запросов в случае V_БД= 1GB. Все узлы – 12-ядерные. Узел IO (с GPU) выполняет «select–project»-обра­ботку запросов над сжатой БД. Узел JOIN – единые процедуры «join» по каждому запросу ПТ, параллельно по 12 запросам (ядро на запрос). GPU в JOIN выполняет разжатие сжатых отношений R_i' «на проходе», по мере их поступления в JOIN.

При этом, согласно табл.3, суммарный объем отношений, задействованных в процессе выполнения ПТ, V_общ^∑≈ 9,7GB. В результате сжатия исходной информации после «select–project»-обра­ботки остается (σ, π)_Σ ≈1,4GB с коэффициентом сжатия V_общ^∑/(σ, π)_Σ ≈6,87. Тогда для несжатой БД общий объем информации, передава­е­мой при обработке ПТ в IO-узле от CPU к GPU и обратно, составит [ V_общ^∑+ (σ, π)_Σ ] ≈ 11,1GB. Поскольку предполагается сравнение результатов теоретического анализа с полученными ранее для СУБД Clusterix-M, то рассматривается использование сети GigabitEthernet. Возможными перегрузками по интерконнекту (когда время ожидания передачи по сети для некоторых сообщений превышает значение тайм-аута, что приводит к «зависанию» системы) будем пренебрегать. Полагаем дополнительно, что этапы обработки ПТ в целом («select–project»-обра­ботка → передача ее результата с уровня IO к Mgm и далее – от Mgm на уровень JOIN → собственно «join»-обработка) следуют друг за другом.

Рис.7. Анализируемый простейший случай

Теоретическая скорость передачи по шине PCI-e равна 6,4GB/s. Получение на практике 3,2GB/s можно гарантировать. Поэтому для несжатой БД суммарное время передач информации в каждом IO-узле от CPU к GPU объемом V_общ^∑ составит t_п1 = 9,7GB/(3,2GB/s) = 3,03сек, а от GPU к CPU – t_п2 = 1,4GB/(3,2GB/s) = 0,44сек. Как нами установлено ранее (см. табл.1), хранение исходной БД в сжатом виде с коэффициентом сжатия K=5 уменьшает t_п1 примерно на 40%. Соответственно для 14 запросов ПТ по­­лучаем t_п′ = (3,03+ 0,44) ∙0,6 = 2,08 сек. Дополнительно необходимо учесть время на передачу сжатых данных по сети GigabitEthernet от IO к Mgm t_п'′ = (σ, π)_Σ /(5∙υ_сети) =1,4GB/(5∙0,1GB/s) = 2,8сек. В итоге получаем (t_Σ^σ,π)′ = t_п′ +t_п'′ = 4,88сек.

Полагаем, что выполнение единых по запросам операций «join» начинается по окончании всех сетевых передач для пакета из 14 запросов непрерывного потока. При оценке общего времени на «join»-обработку (t_Σ^join)′ будем учитывать суммарное время передачи t_п'′' сжатых отношений R_i^′ (последовательно формируемых в BUF) от Mgm на уровень JOIN с поправкой на отсутствие передач R_i^′ для запросов №1 и №6, не содержащих операций «join».Сканкатенированные в BUF Mgm части R_i^′ этих запросов будут ретранслированы Mgm без дополнительной «join»-обра­ботки. Согласно табл.3, сумммарный объем R_i^′ по этим запросам равен 135,6 MB. После сжатия имеем 0,028GB. Поэтому t_п'′' = t_п'′ –0,28сек = 2,52сек.

Пакет из оставшихся 12 запросов будет параллельно обрабатываться на 12 ядрах узла JOIN. Время «join»-обработки этого пакета (t_Σ^join)¹² определится самой медленной процедурой. Согласно табл.2, последней завершится обработка по запросу №9, т.е. (t_Σ^join)¹² ≈ 29,04сек. Общее время (t_Σ^join)′ = t_п'′' + (t_Σ^join)¹² = 2,52сек + 29,04сек = 31,56сек. Время обработки системой пакета из 14 запросов T = (t_Σ^σ,π)′ + (t_Σ^join)′ = 4,88сек + 31,56сек =36,44сек. Поправка на GPU-разжатие данных в JOIN должна быть ничтожно малой.

СУБД Clusterix-M на платформе 1 с 6-ю исполнительными узлами показала для ПТ (см. рис.5) T₁ = 268 сек. Учитывая, что при переходе с платформы 1 на платформу 2, благодаря изменению конфигурации узла от «линейки» к «совмещенной симметрии», время обработки ПТ уменьшается примерно на 25% (см. рис.4б), получаем T₂ ≈ 0,75T₁ = 201 сек. >> T. Даже принимая во внимание, что исходная БД при проведении эксперимента с Clusterix-M находилась на диске, приходим к выводу: при обработке пакета 14 запросов ПТ и сравнительно небольших V_БД рассмотренная простейшая система должна быть значительно эффективнее Clusterix-M.

Принятая к разработке натурная модель Clusterix-G организуется на платформе GPU-кластера КНИТУ-КАИ с шестью исполнительными узлами (узлы 1-6) и одним управляющим (Mgm). Параметры узлов: 2 six-core E5-2640 CPU/2,5GHz/DDR3 128GB; 2 448-core GPU Tesla C-2075/1,15GHz/GDDR5 6GB (на Mgm GPU отсутствуют). Дисковая подсистема узла – RAID-массив 4 WD1000 DHTZ/1TB. Операционная система – SUSE Linux Enterprise Server версии 11. Интерконнект между узлами – GigabitEthernet c 24-портовым коммутатором SSE G24-TG4 /10 GigabitEthernet с 8-портовым коммутатором NETGETAR XS708T-100NES.

Сначала рассмотрим случай равномерного распределения исполнительных узлов (рис.8): узлы 1-3 – IO, узлы 4-6 – JOIN. На все узлы установлена СУБД MySQL 5.7. Сравнительно небольшие размеры используемого GPU-кластера ограничивают возможности проведения исследований на его основе случаем V_БД ≤ 200GB. Причина в следующем. Согласно табл.3, суммарный объем про­межу­точных отношений ПТ ≈ 1,4 V_БД. При V_БД = 200GB это дает 280GB. Данные такого объема (но не более!) еще можно разместить в оперативной памяти трех узлов JOIN (по условию один узел «принимает» не более 100GB). Из той же таблицы следует, что суммарные объемы R_i^' для разных запросов ПТ с «join»-обработкой сильно различаются ~ от 0,0065V_БД до 0,428V_БД. Так что при действии непрерывного потока запросов, случайно формируемых на множестве запросов ПТ, в каждый момент времени в одном JOIN-узле могут обрабатываться от одного до десяти запросов.

Рис.8. Структура натурной модели Clusterix-G. Случай равномерного распределения исполнительных узлов

По аналогии с ранее разработанными СУБД Clusterix и мультикластерной СУБД Cluste­rix-M, для целей разработки натурной модели Clusterix-G принят следующий ориентировочный план ее функционирования. Модуль УПР в Mgm ведет очередь запросов, раздает задание на обработку, балансирует нагрузку между узлами IO (в отличие от Clusterixи Clusterix-M, ониработают асинхронно), получает промежуточные и конечные результаты исполнения запросов. Модуль SORT выпол­няет функции агрегации и сортировки результата обработки запроса. Модуль ROUTER – функцию балансировки нагрузки между узлами JOIN. В буфере BUF по каждому запросу осуществляется конкатенация частей сжатых отношений R_i^′ , подлежащих дальнейшему соединению. Функции управления реализуются по сети Gigabit­Ether­net.

На уровне IO последовательно выполняются операции «select – project» по каждому запросу. По условию все операции «project» «опущены вниз».CPU в IO проецируют колонки, формируют блоки сжатой БД, управля­ют очередью своих команд, работой графических ускорителей (2 GPU на узел), пересылкой сжатых данных по шине PCI-e и сети 10 GigabitEthernet. На уровне JOIN реализуются интегрированные процедуры «join» по запросу в целом.Cредствами MySQL 5.7 оптимизируется их выполнение.Все отношения R_i^′ по каждому запросу должны поступить в память узла JOIN перед началом процедуры.

Дадим ориентировочные оценки для случая обработки натурной моделью рис.8 пакета запросов ПТ при V_БД = 200GB. Согласно табл.3, будем полагать, что один из узлов JOIN выделяется исключительно для обработки запроса №4, а два других – для обработки остальных 11 запросов с «join».Учтем дополнительно следующее. Дуплексный характер сети передачи данных позволит организовать совмещение передач от IO к Mgm и от Mgm к JOIN. Аналогичный дуплекс по шине PCI-e и использование двух ускорителей в каждом IO-узле позволит со­вместить во времени разжатие, обработку порции данных, сжатие и передачу результата host-про­цессору в одном GPU с передачей очередной порции другому GPU. Тогда время собственно «select–project»-обра­ботки определится односторонним обменом CPU →GPU по шине PCI-e.

Соответственно, при условии линейных зависимостей от V_БД и в прежних обозначениях: t_п′ ≈ t_п1 = 3,03сек∙0,6∙200/3 = 121,2сек; t_п'′ ≈ 1,4GB∙200/(5∙1GB/s) = 56сек и (t_Σ^σ,π)′ = t_п′ +t_п'′ ≈ 177,2сек ≈ 0,05 час. Учитывая, согласно табл.2, что (t_Σ^join)¹² определяется временем «join»-обработки запроса №9, имеем: (t_Σ^join)′= (t_Σ^join)¹² = 200∙29,04 = 5808сек ≈ 1,61 час. Поскольку (t_Σ^join)′ >> (t_Σ^σ,π)′, то общее время T обработки ПТ в целом T = (t_Σ^σ,π)′ + (t_Σ^join)′ ≈ (t_Σ^join)′. Поэтому в блоке IO целесообразно оставить лишь один узел, дополнив блок JOIN до пяти узлов. Тогда (t_Σ^σ,π)′ ≈ 0,12час, что незначительно повлияет на величину T.

Реальная динамика процессов в системепри действии непрерывного потока запросов, слу­чайно формируемых на множестве запросов ПТ, будет существенно более сложной по сравнению с рассмотренной. При этом рост числа узлов JOIN поможет разгрузить BUF Mgm от накопления R_i^′ по ожидающим исполнения запросам и будет способствовать повышению производительности системы.

При использовании обычных вычислительных кластеров, организация обработки запросов к консервативным БД больших объемов по регулярному плану – пока что объективная закономерность. Это обусловлено необходимостью хеширования таких БД на множестве узлов кластера. Столь же обосновано и динамическое сегментирование промежуточных и временных отношений. Следствием указанных обстоятельств оказывается «квазипараболическая» зависимость времени обработки ПТ от числа узлов (для вычислительных кластеров более характерно приближение к гиперболе). При этом максимум производительности на грани масштабируемости оказывается достаточно низким. Такова в данном случае плата за работу с базами данных больших объемов. Переход к мультикластеризации при ограничении числа узлов в монокластерах-ком­понентах и использовании архитектуры «совмещенная симметрия» значительно улучшает положение, приближая указанную зависимость к гиперболе. Применение перспективной технологии «один узел кластера на множество запросов» ограничено объемом оперативной памяти узла.

В статье показано, что серьезное повышение эффективности (в сравнении с Clusterix-M) при работе с базами данных сравнительно небольших объемов должно иметь место при переходе на платформу GPU-кластера при условии хранения распределенной БД в сжатом виде в оперативной памяти IO-узлов и организации обработки в JOIN-узлах по схеме «запрос на ядро». В IO-узлах GPU-акселерация используется для реализации операции «select». В JOIN-узлах – для выполнения разжатия «на проходе» последовательно поступающих сжатых промежуточных отношений. Реализация по такому принципу GPU-СУБД объемами до нескольких TB требует построения асимметричных кластеров со сравнительно малым числом IO-узлов, достаточно большим числом JOIN-узлов и скоростной сетью передачи данных. Но имеется ограничительное условие: cуммарный объем промежу­точных отношений для любого запроса действующего потока не должен превышать объема оперативной памяти узла.

Представляет интерес вопрос: насколько все же оправдано использование в принятой натурной модели (Clusterix-G) GPU-акселерации, и нельзя ли в данном случае применить схему «запрос на ядро» в блоке IO с хранением несжатой БД в оперативной памяти узла (ОП) и передачей по сети несжатых промежуточных отношений? Поскольку по условию размеры ОП не позволяют загрузку данных объемом >100GB, придется БД хешировать по двум узлам, так что в блоке JOJN останется 4 узла. Но это не повлияет на значение (t_Σ^join)′ = 1,61час для ПТ. Время параллельного функционирования блока IO определится величиной t_Σ^σ,π для самого «тяжелого» на ПТ запроса. Согласно табл.3, таковым вновь является запрос №9. Для него t_Σ^σ,π = 11,355сек∙100 = 1135,5сек ≈ 0,32час. Суммарное время передачи R_i^′ по сети составит теперь t_п'′ ≈ 280сек ≈ 0,078 час. Так что (t_Σ^σ,π)′ = t_Σ^σ,π + t_п'′ ≈ 0,4час, тогда как для одного IO-узла с GPU было получено (t_Σ^σ,π)′ ≈ 0,12час. Найденная разница может серьезно повлиять на выбор целесообразного числа JOJN-улов и достижимую производительность при действии непрерывного потока запросов.

Получение окончательного ответа на вопрос об эффективности применения GPU в случае баз данных больших объемов связывается с разработкой и исследованием натурной модели СУБД Clusterix-G.

Как бы то ни было, но последний рассмотренный вариант представляет принципиальное изменение методологии Clusterix. Суть этого изменения состоит в отказе от распределенной обработки запроса на уровне JOIN и от динамического сегментирования промежуточных и временных отношений, что существенно облегчает разработку СУБД в целом и повышает ее эффективыность. Но нельзя забывать о ранее сформулированном условии относительно cуммарного объема промежу­точных отношений. Гарантировать его выполнение в общем случае невозможно (пример запроса №4). Снятие этого условия означает возврат к методологии Clusterix-M.

Во избежание переполнения памяти Mgm, каждое R_i^′ отсылается в подходящий узел JOJN сразу по окончании накопления этого R_i^′ в BUF. Возможные затруднения, связанные с ограниченным объемом узловой оперативной памяти, можно облегчить для узлов JOJN, если предусмотреть в них последовательное (не интегрированное) выполнение операций «join» (согласно рис.1). И хотя такое выполнение вдвое увеличит t_Σ^join, но «join»-обработка в целом будет частично совмещена с передачей по сети отношений R_i^′.

Выполненный для случая GPU-акселерации анализ в целом имел целью обсуждение принципов высокоэффективного построения консервативных СУБД объемом ≥ 100GB довольно скромными средствами, доступными в настоящее время широкому кругу научно-образовательных организаций. Использование перспективных, но довольно дорогих технологий с объемами оперативной памяти до 2TB и значительным числом ядер (не менее 18) в узле делает подход ^[17] недосягаемым по эффективности другими известными методами построения большеобъемных консервативных СУБД кластерного типа. Во всяком случае, экспериментальных данных, опровергающих это утверждение, пока не имеется.