CC BY
34
ОРГАНИЗАЦИЯ ПАРАЛЛЕЛЬНОГО ИСПОЛНИТЕЛЯ ЗАПРОСОВ НА БАЗЕ МНОГОПРОЦЕССОРНОГО ВЫЧИСЛИТЕЛЬНОГО КОМПЛЕКСА МВС-100/1000
Т.Ю. Лымарь, Л.Б. Соколинский *
Челябинский государственный университет
Описываются принципы организации и структура исполнителя запросов в прототипе параллельной системы управления базами данных Омега для отечественных многопроцессорных вычислительных комплексов МВС-100/1000. Предлагается оригинальная модель распараллеливания и синхронизации операций в дереве запроса. Эксперименты, проведенные на данном прототипе, показывают, что предложенная потоковая модель способна обеспечить сравнительно высокую производительность, обеспечивая в то же время устойчивость по отношению к перекосам данных.
Ключевые слова: параллельные СУБД, исполнители запросов, потоки данных, планирование загрузки.
Одной из проблем, возникающих при реализации параллельных систем управления базами данных (СУБД), является проблема эффективной организации параллельного выполнения запросов. В данной работе описывается организация параллельного исполнителя запросов в прототипе параллельной системы управления базами данных Омега [1] для отечественных многопроцессорных вычислительных комплексов МВС-100/1000 [2]. Система Омега имеет трехуровневую иерархическую аппаратную архитектуру. Данная архитектура характеризуется высокой готовностью данных при аппаратных отказах, демонстрируя, в то же время, сравнительно высокую общую производительность [3].
Существуют две хорошо известные общие модели, используемые при реализации параллельных исполнителей запросов, называемые скобочной и операторной моделями [4]. Скобочная модель была применена в целом ряде параллельных СУБД, например, в системах Gamma [5] и Bubba [6], операторная модель — при реализации параллельной СУБД Volcano [7].
В системе Омега мы используем новую модель для организации параллельного выполнения запросов, названную потоковой. Она соединяет в себе преимущества скобочной и операторной моделей и оптимальным образом учитывает особенности аппаратной архитектуры системы Омега.
Потоковая модель основана на парадигме “производитель — потребитель” и использует механизм потоков под управлением данных для эффективной организации обменов данными между операциями. Каждая опера-
* Работа выполнена при поддержке РФФИ (грант № 00-07-90077).
ция дерева запроса представляется в виде отдельного легковесного процесса (нити). В системе Омега каждый процесс рассматривается как корневая нить (на одном процессорном модуле может быть запущен только один процесс). Любая нить может породить произвольное число дочерних нитей. Таким образом, нити образуют иерархию, поддерживаемую менеджером нитей. В зависимости от реализуемой реляционной операции, нити делятся на два класса: конъюнктивные и дизъюнктивные. Для передачи управления используется значение динамического приоритета, вычисляемое с помощью фактор-функции нити. Более детальное описание работы менеджера нитей и формулы вычисления динамического приоритета можно найти в работе [8].
Нами описаны программная структура исполнителя запросов, общий операторный фрейм, используемый в предлагаемой потоковой модели для унифицированного представления узлов дерева запроса на физическом уровне, структура и специфика применения специального оператора обмена, используемого в потоковой модели для организации внутриоперационного параллелизма, а также приведены результаты проведенных экспериментов.
1. ИЕРАРХИЯ МОДУЛЕЙ И КЛАССОВ ИСПОЛНИТЕЛЯ ФИЗИЧЕСКИХ ЗАПРОСОВ
Исполнитель физических запросов СУБД Омега представляет собой виртуальную машину, способную выполнять физические запросы, то есть запросы, выраженные в терминах физической алгебры. На уровне физической алгебры любая “параллельность” в выполнении запроса реализуется только явно. В частности, аргументами и результатами операций физической алгебры являются фрагменты отношений. Параллельные операции над отношениями, базирующиеся на их фрагментации, реализуются на более высоких уровнях системной иерархии.
Иерархия модулей и классов исполнителя изображена на рис. 1.
Класс Stock реализует абстрактный тип “Склад”, необходимый для осуществления модели “поставщик — потребитель”.
Класс Stream реализует абстрактный тип “Поток данных”, обобщающий все имеющиеся типы источников данных.
Модуль интерпретатора операций физической алгебры описывает структуру и типы параметров операций с различными кодами и предоставляет процедуры реализации операций.
Класс Tree реализует абстрактный тип “Дерево запроса” и предоставляет методы создания и обхода деревьев.
Рис. 1
Модуль исполнителя реализует скобочную модель и предоставляет методы создания, исполнения и уничтожения деревьев физических запросов.
2. ОПЕРАТОРНЫЙ ФРЕЙМ
В системе Омега узлы дерева запроса реализуются на основе общего операторного фрейма, который может потреблять и производить гранулы данных и который способен выполнять в точности один оператор. Операторный фрейм является развитием концепции скобочного шаблона [4]. Он содержит следующие слоты, заполняемые при построении физического плана выполнения запроса: указатель на функцию тела нити, реализующую соответствующую операцию физической алгебры; указатель на фактор-функцию нити; указатель на выходной поток (см. ниже); указатель на левого сына (может быть пустым); указатель на правого сына (может быть пустым); тип нити (конъюнктивная или дизъюнктивная). Максимальное количество сыновей ограничивается числом два, так как в системе Омега физическая алгебра состоит только из унарных и бинарных операций [8].
Выполнение физического плана происходит следующим образом. Менеджер запросов запускает нить, соответствующую корневому операторному фрейму в дереве фреймов, представляющем данный физический план.
Указатель на соответствующий операторный фрейм присваивается переменной cargo, ассоциированной с данной нитью (менеджер нитей для каждой нити поддерживает атрибут cargo типа void* 1. Это необходимо для того, чтобы в теле нити и в теле фактор-функции в процессе их выполнения можно было бы через данный атрибут получить доступ к значению любого атрибута (слота) соответствующего операторного фрейма. Сразу после своего запуска нить проверяет значение указателя на левого сына своего операторного фрейма. Если данный указатель непуст, то запускается нить, соответствующая левому сыну, и переменной cargo, ассоциированной с этой нитью, присваивается указатель на левого сына. Аналогичные действия выполняются для правого сына. Таким образом, рекурсивно, будут запущены нити для всех узлов дерева запроса. Причем иерархия нитей будет в точности соответствовать иерархии операторных фреймов.
Если при выполнении физического плана узлам в дереве запроса соответствуют нити, выполняющие соответствующие операции, то мы можем сказать, что ребрам соответствуют потоки [9]. Поток является обобщением понятия файла и действует как виртуальный FIFO-файл. Поток представляет собой реализацию фрагмента отношения на уровне физической алгебры. Потоки являются аргументами и результатами операций физической алгебры, то есть входными и выходными данными узлов дерева запроса. В системе Омега над потоком можно выполнять следующие основные операции:
— открыть поток;
— закрыть поток;
— поместить гранулу в поток;
— извлечь гранулу из потока;
— вернуть количество гранул в потоке.
Менеджер запросов системы Омега поддерживает потоки следующих предопределенных типов: хранимый файл; временный файл; канал кондуктора; канал маршрутизатора; склад [9].
Представлением потока типа <Файл> является открытый хранимый файл. Операции открытия и закрытия потока <Файл> не влияют на состояние файла, соответствующие действия выполняются над файловым итератором: при открытии потока он создается, при закрытии — уничтожается.
1 Указатель на пустой тип в языке Си (соответствует указателю на значение неопределенного типа).
Представлением потока типа <Временный файл> является временный файл. Он создается и уничтожается вместе с соответствующим потоком.
Представлением потока типа <Канал кондуктора> является канал Омега-кондуктора. При создании и открытии потока <Канал кондуктора> создание канала не происходит, он создается только в процессе операции записи или чтения и после завершения операции немедленно уничтожается.
Представлением потока типа <Канал маршрутизатора> является канал Омега-маршрутизатора. Механизм его работы аналогичен каналу кондуктора.
Представлением потока типа <Склад> является объект типа Stock. Склад создается и уничтожается вместе с соответствующим потоком.
Выбор конкретного типа и, соответственно, механизма передачи данных зависит от физического расположения сообщающихся узлов — на одном или разных процессорах, в одном или в разных кластерах.
Приведенная концепция обмена данными реализована в исполнителе запросов классом Stream. Он предоставляет базовые методы для создания абстрактных объектов типа “Поток” и сервисные функции, реализующие конкретные типы потоков и доступ к ним. Интерфейс сервисных функций класса Stream максимально унифицирован. Это позволяет обращаться к потоку, не задумываясь о конкретном механизме его работы, что существенно облегчает дальнейшую разработку системы в целом и исполнителя запросов в частности.
В системе Омега основным видом потоков, используемых для представления деревьев запросов, является склад. Склад представляет собой буфер, располагающийся в оперативной памяти и функционирующий по принципу FIFO. При длине склада, равной одному, мы получаем фактически стандартную итераторную модель, используемую для управления потоками данных в большинстве СУБД [4].
Концепция склада реализована в исполнителе запросов классом Stock. Этот класс реализует абстрактный тип выходных буферов нитей в модели “поставщик — потребитель”. Экземпляры класса Stock имеют структуру очереди. В склад можно помещать и извлекать из него элементы, представляющие собой байтовые строки фиксированной длины. Информация о складах содержится в дескрипторах, хранящихся в статическом массиве. Дескриптор включает следующие поля: максимальное количество элементов в складе, длина элемента, адрес блока выделенной под склад памяти, указатели на текущие <голову> и <хвост> склада.
С каждым существующим складом связывается значение, называемое коэффициентом заполнения склада. Значение коэффициента вычисляется динамически и учитывается при диспетчеризации нитей.
Как показывают результаты экспериментов, при наличии перекосов в распределении значений атрибутов соединения использование складов с длиной больше единицы может значительно повысить производительность системы.
3. СТРУКТУРА ОПЕРАТОРА ОБМЕНА
Для реализации внутриоперационного (горизонтального) параллелизма в системе Омега используется специальный оператор обмена exchange [10]. Оператор exchange реализуется на основе использования стандартного реализационного фрейма и может быть добавлен в качестве узла в любое место дерева запроса.
Оператор exchange имеет два специальных параметра, определяемых пользователем: номер порта обмена и указатель на функцию распределения. Функция распределения для каждой гранулы данных вычисляет логический номер процессорного узла, на котором данная гранула должна быть обработана. Параметр “порт обмена” позволяет включать в дерево запроса произвольное количество операторов exchange (для каждого оператора указывается свой уникальный порт обмена).
Реализация оператора обмена exchange изображена на рис. 2. Оператор exchange является составным и включает четыре оператора: gather, scatter, split и merge. Все указанные операторы реализуются на базе общего операторного фрейма, описанного выше.
Оператор split — это конъюнктивный бинарный оператор, который осуществляет разбиение гранул, поступающих из входного потока (ассоциируется с левым сыном), на две группы: свои и чужие. Свои гранулы — это гранулы, которые должны быть обработаны на данном процессорном узле. Эти гранулы помещаются в выходной поток (склад) оператора split. Чужие гранулы, то есть гранулы, которые должны быть обработаны на процессорных узлах, отличных от данного, помещаются оператором split в выходной поток (склад) правого сына, в качестве которого фигурирует оператор scatter. В данном случае выходной поток оператора split играет роль входного буфера (это достигается путем инвертирования фактор-функции, которая в данном случае будет выдавать значение один для пустого склада и значение ноль — для полностью заполненного склада).
Нульарный оператор scatter извлекает гранулы из своего выходного потока (склада) и пересылает их по каналам кондуктора на соответствую-
I
Рис. 2
щие процессорные узлы, используя заданный номер порта. Запись гранулы в порт может быть завершена только после того, как реципиент выполнит операцию чтения из данного порта.
Нульарный оператор gather выполняет перманентное чтение гранул данных из указанного порта со всех узлов кластера, отличных от данного. Считанные гранулы помещаются в выходной поток (склад) оператора gather. При переполнении склада процесс чтения гранул приостанавливается.
Оператор merge определяется как дизъюнктивный бинарный оператор, который забирает гранулы из выходных потоков (складов) своих сыновей и помещает их в собственный выходной поток (склад).
Отличительной особенностью оператора обмена exchange является то, что он может быть помещен в любом месте дерева запроса, не оказывая при этом никакого влияния на соседние операторы. Оператор exchange не участвует в обмене данных на логическом уровне представления запроса, и поэтому на данном уровне он выглядит как пустой оператор. Однако на физическом уровне оператор exchange выполняет функцию, которую не может выполнять никакой другой оператор и которая заключается в перераспределении данных между процессорными узлами при параллель-
ном выполнении реляционных операций. Таким образом, оператор обмена exchange инкапсулирует в себе все механизмы, необходимые для реализации внутриоперационного параллелизма. Данный подход значительно облегчает реализацию параллельных алгоритмов в системах баз данных и делает их более надежными. Кроме того, такой подход позволяет сравнительно легко переносить на платформу Омега алгоритмы выполнения реляционных операций, разработанные для систем с архитектурой без совместного использования ресурсов.
4. РЕЗУЛЬТАТЫ ЭКСПЕРИМЕНТОВ
В соответствии с принципами, описанными в данной статье, нами был спроектирован и реализован прототип менеджера запросов параллельной СУБД Омега для платформы МВС-100 в 8-процессорной конфигурации. Используя данный прототип, мы провели ряд вычислительных экспериментов, в которых исследовали эффективность потоковой модели при различных значениях параметров системы и базы данных.
В качестве запросов мы использовали мультисоединения, представленные в виде левонаправленных деревьев с максимальной глубиной (количеством операций join), равной трем. Мы предполагаем, что отношение R имеет три атрибута: а\,а2,а^. Атрибут а\ является атрибутом соединения для отношения Q1, атрибут <22 является атрибутом соединения для отношения Q2, атрибут аз является атрибутом соединения для отношения Q3.
600 ---------------------------------
350 Н--------1------1------1------1------1------1------1-------1------1
2 6 10 14 18 22 26 30 34 38
Размер склада (в гранулах)
Рис. 3
440 -I------1------1------1-----1------1------1------1-----1------1
2 6 10 14 18 22 26 30 34 38
Размер склада (в гранулах)
Рис. 4
Эксперименты проводились при следующих значениях основных системных параметров. Процессорные модули МВС в нашей конфигурации разделены на два Омега-кластера [3]. Каждый кластер состоит из четырех процессорных модулей и имеет четыре диска. Максимальная длина кратчайшего пути между процессорными модулями кластера равна двум. Размер гранулы данных равен 1000 байт, размер отношения — 1600 гранул.
Параметр VCF(R, аг) вычисляется как отношение щ, где |Д| — размер отношения R, V — количество различных значений в столбце аг- отношения R. В наших экспериментах мы предполагали, что все атрибуты отношения R имеют одинаковое значение параметра VCF, равное 0,1.
Фактор селективности определяется как отношение размера результата соединения к размеру исходного промежуточного отношения. Мы предполагаем, что все операции join в дереве запроса имеют один и тот же фактор селективности.
При проведении экспериментов мы использовали тестовую базу данных, состоящую из отношений с целочисленными атрибутами. Для генерации значений атрибутов мы использовали Зипфово и равномерное распределения. По умолчанию все атрибуты генерировались по закону Зипфа, в соответствии с которым двадцати процентам значений атрибута соответствует восемьдесят процентов кортежей.
На рис. 3 изображены результаты эксперимента, в котором мы исследовали эффективность потоковой модели при различных распределениях
значений атрибутов соединения. Здесь Z обозначает Зипфово распределение, II обозначает равномерное распределение. В числителе указан закон распределения для атрибутов отношения Я, в знаменателе — закон распределения для атрибутов отношений (^1 (г = 1, 2, 3).
Результаты данного эксперимента показывают, что, по сравнению с традиционной итераторной моделью, потоковая модель может значительно (на 30-40%) повысить эффективность выполнения мультисоединений при неравномерном распределении значений атрибутов соединения. При этом максимальный эффект достигается при длине склада, составляющей 20-30 гранул.
В эксперименте, результаты которого изображены на рис. 4, мы исследовали эффективность потоковой модели при различных значениях параметра УСР.
Как показали результаты проведенного эксперимента, при малых значениях параметра УСР эффективность потоковой и итераторной моделей оказывается примерно одинаковой. Однако при больших значениях параметра УСР потоковая модель более эффективна. Данный результат является естественным, так как большое количество одинаковых значений нивелирует неравномерность распределения.
Третий эксперимент был посвящен исследованию эффективности потоковой модели в условиях изменения фактора селективности (<5-Р). Как показывают результаты данного эксперимента (см. рис. 5) увеличение селективности операций (большая селективность соответствует меньшим значениям параметра БР) снижает относительную эффективность потоковой модели.
На основе проведенных экспериментов мы можем заключить, что предложенная потоковая модель способна обеспечить сравнительно высокую производительность, обеспечивая в то же время устойчивость к перекосам в распределении значений атрибутов соединения.
Таким образом, нами была предложена новая модель распараллеливания запросов, названная потоковой моделью, которая позволяет выполнять на процессорном узле несколько различных запросов одновременно. Каждый из этих запросов может быть автоматически распараллелен на любом количестве процессорных узлов. Это достигается путем введения специального оператора обмена, инкапсулирующего в себе все механизмы, необходимые для реализации внутриоперационного параллелизма. Данный подход значительно облегчает реализацию параллельных алгоритмов в системах баз данных и делает их более надежными.
Отличительной особенностью потоковой модели является автоматическая синхронизация и диспетчеризация процессов выполнения операций
Рис. 5
в дереве запроса. Основой реализации потоковой модели является операторный фрейм и класс объектов данных, называемых потоками. Указанные механизмы обеспечивают устойчивость потоковой модели к перекосам в распределении значений атрибутов соединения.
Описанная модель была реализована в прототипе параллельной СУБД Омега на базе МВС-100 в 8-процессорной конфигурации. Были проведены вычислительные эксперименты, подтверждающие высокую эффективность предложенного подхода.
Список литературы
1. Sokolinsky L.B., Axenov О., Gutova S. Omega: The Highly Parallel Database System Project // Proceedings of the First East- European Symposium on Advances in Database and Information Systems (ADBIS’97). St.-Petersburg, 1997. Vol. 2. P. 88 - 90.
2. Забродин А.В., Левин В.К. Опыт разработки параллельных вычислительных технологий. Создание и развитие семейства МВС // Высокопроизводительные вычисления и их приложения: Тез. докл. Всерос. науч. конф., г. Черноголовка, 30 окт. - 2 нояб. 2000 г. М.: Изд-во Моск. ун-та, 2000. С. 3 - 8.
3. Соколинский Л.Б. Проектирование и анализ архитектур параллельных машин баз данных с высокой отказоустойчивостью // Высокопроизводительные вычисления и их приложения: Тез. докл. Всерос. науч. конф., г.Черноголовка, 30 окт. -
2 нояб. 2000 г. М.: Изд-во Моск. ун-та, 2000. С. 56 - 61.
4. Graefe G. Query evaluation techniques for large databases// ACM Computing Surveys. June 1993. Vol. 25, № 2. P. 73 - 169.
5. DeWitt D.J., et al. The Gamma database machine project // IEEE Trans, on Knowledge and Data Engineering. March 1990. Vol. 2, № 1. P. 44 - 62.
6. Boral Н., Alexander W., Clay L., Copeland G., Sanforth S., Franklin М., Hart B., Smith М., Valduriez P. Prototyping Bubba: a Highly Parallel Database System // IEEE Trans, on Knowledge and Data Engineering. March 1990. Vol. 2, № 1. P. 4 - 24.
7. Graefe G. Encapsulation of Parallelism in the Volcano Query Processing Systems // Proceedings of the 1990 ACM SIGMOD International Conference on Management of Data, Atlantic City, NJ, May 23 - 25, 1990. Atlantic City, 1990. P. 102 - 111.
8. Соколинский Л.Б. Эффективная организация легковесных процессов в параллельной СУБД Омега для МВС-100 // Фундаментальные и прикладные аспекты разработки больших распределенных программных комплексов: Тез. докл. Всерос. науч. конф., Новороссийск, 21 - 26 сент. 1998 г. М.: Изд-во Моск. ун-та, 1998. С. 132 - 138.
9. Lymar T.Y., Sokolinsky L.B. Data Streams Organization in Query Executor for Parallel DBMS // Databases and Information System. Proceedings of the 4th IEEE International Baltic Workshop, Lithuania, Vilnius, May 1 - 5, 2000. Vilnius: Technica, 2000. Vol. 1. P. 85 - 88.
10. Лымарь Т.Ю., Соколинский Л.Б. Инкапсуляция параллелизма в исполнителе запросов СУБД Омега // Высокопроизводительные вычисления и их приложения: Тез. докл. Всерос. науч. конф., г. Черного ловка, 30 окт. - 2 нояб. 2000 г. М.: Изд-во Моск. ун-та, 2000. С. 136 - 140.
SUMMARY
The work describes the principles of organization and structure of the query executor for the prototype of the parallel data base management system Omega for the Russian multiprocessor computational complexes MVS-100/1000. An original model of parallelism and operations synchronization implementation in a query tree is proposed. The tests run on the prototype indicate that the proposed stream model is capable of rather high performance while providing stability in presence of data skew.
