Научно-образовательный IT-форум при КНИТУ-КАИ

Информация о пользователе

Привет, Гость! Войдите или зарегистрируйтесь.


Вы здесь » Научно-образовательный IT-форум при КНИТУ-КАИ » Доклады и заметки » СУБД Clusterix-N класса «Big Data» на платформе GPU-кластера


СУБД Clusterix-N класса «Big Data» на платформе GPU-кластера

Сообщений 1 страница 8 из 8

1

РАЗРАБОТКА И ИССЛЕДОВАНИЕ КОНСЕРВАТИВНОЙ СУБД Clusterix-N
КЛАССА «Big Data» НА ПЛАТФОРМЕ GPU-КЛАСТЕРА

Р.К. Классен (КНИТУ-КАИ)

Рассматриваются вопросы обработки сложных аналитических запросов к базам данных консервативного типа большого объема на платформе GPU кластера КНИТУ-КАИ. Предлагается архитектура параллельной СУБД Clusterix-N. Она сравнивается с оригинальными архитектурами Clusterix и PerformSys. Сравниваются результаты экспериментов на ограниченном тесте TPC-H (без операций записи) с VБД=60 GB и VБД=120 GB для Clusterix-N и PerformSys. Обсуждаются полученные результаты.

ПРЕЗЕНТАЦИЯ

ВИДЕО ДОКЛАДА:

2

Здравствуйте.

Скажите, пожалуйста, есть ли ещё способы, чтобы уменьшить ожидание на MGM-модуле? Есть ли ещё какие-нибудь другие узкие места, помимо сети?

Также хотелось бы узнать, по какой причине время работы Clusterix-N при объёме БД=60ГБ значительно больше, чем у PerformSys? можно ли добиться меньшего значения времени, если использовать другие модули выполнения запросов JOIN (последовательный JOIN на одном ядре, интегрированный JOIN на одном ядре или хешированный JOIN на множестве узлов)?

3

Здравствуйте.

Скажите, пожалуйста, есть ли ещё способы, чтобы уменьшить ожидание на MGM-модуле?


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

Есть ли ещё какие-нибудь другие узкие места, помимо сети?


Конечно есть. Например, загрузка данных в СУБД занимает существенную долю времени обработки. Удаление данных из СУБД тоже занимает довольно много времени. Проблему можно решить заменой СУБД на более производительную с поддержкой In-Memory Database или использованием собственного движка.

Еще одно узкое место - это хеширование на GPU. В случае использования 10GigabitEthernet потребуется 5-6 видеокарт уровня Tesla M2075 для обеспечения скорости хеширования сопоставимой со скорость передачи по сети.

Также хотелось бы узнать, по какой причине время работы Clusterix-N при объёме БД=60ГБ значительно больше, чем у PerformSys?


PerformSys обрабатывает сразу 72 запроса, против 1 у Clusterix-N. Вся база умещается в ОЗУ узла и система не ожидает получения данных с дисков (ровно как и Clusterix-N). Но Clusterix-N передает данные по сети и распределяет нагрузку по узлам. Как раз  на передачи и уходит большая часть времени.

можно ли добиться меньшего значения времени, если использовать другие модули выполнения запросов JOIN (последовательный JOIN на одном ядре, интегрированный JOIN на одном ядре или хешированный JOIN на множестве узлов)?


Как раз хешированный JOIN на множестве узлов и был использован в экспериментах, он и обуславливает использования всего кластера для обработки всего запроса.

Интегрированный JOIN, требует загрузки всех временных отношений в память узлов JOIN для каждого запроса и исполняется на 1 ядре. Т.е. на GPU кластере КНИТУ-КАИ в конфигурации MGM 2xIO 4xJOIN одновременно будет обрабатываться до 48 запросов. Такой join выгодно применять для небольших БД, но, опять же, передача данных занимает большое количество времени и большая часть процессорных ядер на уровне JOIN будет простаивать. Так что производительность все равно была бы хуже, чем PerformSys, т.к. требуется передача по сети.

Последовательный JOIN требует наличия на узле всего двух отношений для выполнения операции join. Метод экономит память, но работает существенно медленнее интегрированного JOIN. Его можно применять при работе с большими БД с высокой интенсивностью запросов. Но при 60 ГБ PerformSys будет быстрее, т.к. он использует интегрированный JOIN и не передает промежуточные данные по сети.

4

Какие еще недостатки имеются у используемого движка MySQL Memory?
И хотелось бы узнать, почему хэширование идёт быстрее, чем передача данных в систему?

5

Какие еще недостатки имеются у используемого движка MySQL Memory?


MySQL Memory хранит данные в выровненной структуре, т.е. если максимальный размер одной строки таблицы 200 байт, то она и будет занимать в памяти 200 байт, даже если в строке не записано столько данных. Например, БД TPC-H размером 1 ГБ после загрузки в этот движок занимает более 1.5 ГБ и это еще без индексов. Хотелось бы применить сжатие, но сжатие требует дополнительных вычислительных ресурсов, а движок создан для максимального быстродействия.

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

К тому же этот движок, в отличии от остальных, не хранит данные на диске. При выключении питания все содержимое таблиц на этом движке будет очищено.

Еще у этого движка имеются проблемы с блокировками. Операции записи блокируют таблицу целиком, поэтому многопоточное изменение одной таблице невозможно. А операции изменения схемы (например, удаление таблицы) блокируют всю БД. Поэтому в Clusterix-N удаление начинается только после завершения всех операций.

На самом деле движок хороший. Быстрый, работает в ОЗУ, не требует диска (то, что нам и нужно :) ). И, самое главное, в PostgreSQL нет ничего подобного.

почему хэширование идёт быстрее, чем передача данных в систему?


Первоначальная реализация хеширования на CPU позволяла выполнять хеширование со скоростью 20-25 МБ/с на 1 ядре. Параллельная реализация позволила ускорить хеширование до  50-60 МБ/с на 12 ядрах. Такой низкий прирост производительности, вероятно, получился из-за наличия всего 4-х каналов ОЗУ. Следующая реализация (которая и использовалась в экспериментах) была выполнена на GPU. Она показала производительность ~200-250 МБ/с на Tesla M2075.

Скорость передачи данных по GigabitEthernet не превышает 100 МБ/с. Поэтому процесс хеширования идет быстрее передачи данных по сети. Если бы эксперимент проводился с сетью 10GigabitEthernet, то узким местом системы было бы хеширование данных.

6

Кстати, если кому-то будет интересно, исходный код систем можно посмотреть здесь:
- PerformSys https://github.com/rozh1/PerformSys
- Clusterix-N https://bitbucket.org/rozh/clusterixn
- gpuhash https://github.com/rozh1/gpuhash

7

Здравствуйте!

После просмотра Вашего доклада у меня появилось несколько вопросов:
1. Какая конфигурация дисковой подсистемы использовалась в тестах PerformSys и Clusterix-N? Использовался ли RAID (программный или аппаратный)? Какие-нибудь СХД? Пробовали ли Вы использовать SSD? Насколько я понял из Вашего доклада, то главным "узким местом" в системе PerformSys являются именно операции ввода/вывода. Т.е. теоретически, если использовать более быстрый ввод/вывод, то результаты PerformSys будут лучше?
2. Немного не понял, как работает связь между инструментальной СУБД и параллельной СУБД. Вся работа идет через инструментальную СУБД, но "за кулисами" драйвер передает выполнение запросов в параллельную СУБД? Я правильно понимаю?
3. Инструментальной СУБД может быть только MySQL или есть драйверы для других СУБД (например, Oracle, MS SQL Server и т.д.)?
4. Клиент, который подключается к СУБД должен ли иметь какие-то специальные настройки (например, параметры строки подключения, использование каких-либо дополнительных драйверов и т.д.)? Или клиент вообще "не понимает", что работает с параллельной СУБД?

Отредактировано alex_spq (2018-04-22 20:10:46)

8

Здравствуйте, alex_spq!

Какая конфигурация дисковой подсистемы использовалась в тестах PerformSys и Clusterix-N? Использовался ли RAID (программный или аппаратный)?


Для обоих систем конфигурация дисковой подсистемы была одинаковая: аппаратный RAID 10 на 4-х дисках с интерфейсом SATA.

Какие-нибудь СХД? Пробовали ли Вы использовать SSD?


SSD не использовались. К сожалению, мы ограничены аппаратной платформой.

Насколько я понял из Вашего доклада, то главным "узким местом" в системе PerformSys являются именно операции ввода/вывода. Т.е. теоретически, если использовать более быстрый ввод/вывод, то результаты PerformSys будут лучше?


Абсолютно верно. В случае работы с базами данных, которые невозможно поместить в ОЗУ узла, активно используется дисковый ввод/вывод. Увеличение количество каналов на доступ к дискам и увеличение пропускной способности дисков должны существенно повысить производительность PerformSys.

Немного не понял, как работает связь между инструментальной СУБД и параллельной СУБД. Вся работа идет через инструментальную СУБД, но "за кулисами" драйвер передает выполнение запросов в параллельную СУБД? Я правильно понимаю?


Инструментальная СУБД - это СУБД, которая используется Clusterix-N для обработки запросов на исполнительных узлах. Она может быть как параллельной, так и нет. Clusterix-N ориентирована на работу с не параллельными инструментальным СУБД (MySQL, MonetDB, PostgreSQL, и тд).

Параллельная СУБД (здесь это Clusterix-N) получает запрос, транслирует его для параллельного выполнения (в текущей версии используется набор претранслированных запросов), раздает его части на выполнение в исполнительные узлы, где драйвер связывается с инструментальной СУБД. Т.е. Запрос -> Clusterix-N -> инструментальная СУБД.

Инструментальной СУБД может быть только MySQL или есть драйверы для других СУБД


В качестве инструментальной СУБД может выступать любая СУБД. Достаточно лишь реализовать драйвер с определенным интерфейсом.

В процессе разработки были написаны драйвера для MonetDB и PostgreSQL. Но MonetDB работала не стабильно, PostgreSQL - не имела возможности работать только в ОЗУ. Поэтому в текущей версии эти драйвера удалены.

Клиент, который подключается к СУБД должен ли иметь какие-то специальные настройки (например, параметры строки подключения, использование каких-либо дополнительных драйверов и т.д.)? Или клиент вообще "не понимает", что работает с параллельной СУБД?


В исследовательской версии отсутствует клиентский интерфейс. Реализация клиентского интерфейса требуется только в модуле MGM. Она может быть выполнена как для определенной системы (например, это может быть простая пересылка строк по сети или передача информации в xml), так и в виде реализации интерфейса одной из открытых СУБД (например, MySQL). В обоих случаях Clusterix-N для клиента выглядит как один сервер СУБД, т.е. клиент вообще "не понимает", что работает с параллельной СУБД. Второй вариант реализации интересен тем, что он позволяет внедрять Clusterix-N без изменения клиентской системы.


Вы здесь » Научно-образовательный IT-форум при КНИТУ-КАИ » Доклады и заметки » СУБД Clusterix-N класса «Big Data» на платформе GPU-кластера