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

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

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


Вы здесь » Научно-образовательный IT-форум при КНИТУ-КАИ » Доклады и заметки » Гибридные технологии консервативных СУБД больших объемов


Гибридные технологии консервативных СУБД больших объемов

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

1

ГИБРИДНЫЕ ТЕХНОЛОГИИ КОНСЕРВАТИВНЫХ СУБД БОЛЬШИХ ОБЪЕМОВ,
ДОСТУПНЫЕ ШИРОКОМУ КРУГУ ОРГАНИЗАЦИЙ

В.А. Райхлин, Р.К. Классен (КНИТУ-КАИ)

Обсуждаются новые принципы организации консервативных СУБД (с эпизодическим обновлением данных в специально выделяемое время) на сравнительно недорогих кластерных платформах с применением средств MySQL и GPU-акселераторов на исполнительном уровне. Актуальность принятой ориентации на работу с базами данных больших объемов определяется современными тенденциями интеллектуальной обработки больших информационных массивов. Повышение объема баз данных требует их хеширования по узлам кластера. Это обуславливает необходимость использования регулярного плана обработки запросов. Применение однородных кластерных технологий (СУБД Clusterix) требует дополнительно динамической сегментации промежуточных и временных отношений. В отличие от СУБД Clusterix и более совершенной мультикластерной СУБД Clusterix-M для управления базами данных больших объемов предложены гибридные технологии (проекты Clusterix-N и Clusterix-G) с разделением кластера на две части, что позволяет исключить динамическую сегментацию. Одна из них выполняет селектирование и проецирование над хешированной по узлам базой данных (блок IO). Другая – соединение по схеме «ядро на запрос» (блок JOIN). Отличительной особенностью СУБД Clusterix-G с GPU-акселераторами является работа со сжатыми базами данных, что позволяет увеличить их объем при ограниченных объемах оперативной памяти узлов. Функции графических ускорителей в разных частях своеобразны. В блоке IO они выполняют функции разжатия-селектирования исходных отношений и сжатия получаемых промежуточных отношений. В блоке JOIN – функцию разжатия поступивших промежуточных отношений. Проведенный теоретический анализ показал, что предложенные технологий значительно более эффективны в сравнении с Clusterix-M, а по производительности СУБД Clusterix-G должна в разы превышать Clusterix-N для интерконнекта среднего быстродействия.

ПРЕЗЕНТАЦИЯ ДОКЛАДА

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

2

1. Что можно предпринять если запрос(-ы) с большим объемом операций join не были выполнены системой?
2.Почему Clusterix-N увеличивает быстродействие, преимущественно перед Clusterix-G, если использовать более быструю сеть?
3. Чем объясняется преимущество СУБД Clusterix перед MySQL Cluster?

Отредактировано Ghoooster (2017-12-26 15:10:44)

3

1. Что можно предпринять если запрос(-ы) с большим объемом операций join не были выполнены системой?


Можно дождаться освобождения памяти на исполнительных узлах и запустить запрос заново. Или использовать диски для хранения промежуточных отношений (медленно, но зато отказа не будет). Еще можно просто вернуть ошибку пользователю :)

Почему Clusterix-N увеличивает быстродействие, преимущественно перед Clusterix-G, если использовать более быструю сеть?


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

Чем объясняется преимущество СУБД Clusterix перед MySQL Cluster?


У MySQL Cluster есть 2 хорошие вещи: резервирование и отказоустойчивость. Скорость работы оставляет желать лучшего, особенно для больших аналитических запросах. Это происходит в первую очередь из-за стратегии работы "клиент на ядро", т.е. для выполнения одного запроса от одного клиента будет задействовано всего 1 ядро.

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

Если моя информация по MySQL Cluster устарела - поправьте :)

4

Добрый день!
Насколько оправдано использование Clusterix-G с графическими ускорителями для сжатия/разжатия перед Clusterix-N на высокоскоростной сети, например, InfiniBand? Не является ли использование бОльшей пропускной способности и низкой задержкой сети, т.е. переход на современную коммутируемую компьютерную сеть, более приоритетным направлением для работы с хранилищем данных?
Так же вопрос по СУБД. Как я понимаю, MySQL не является принципиально влияющей СУБД на скорость тестов, предложенных в докладе?

5

Насколько оправдано использование Clusterix-G с графическими ускорителями для сжатия/разжатия перед Clusterix-N на высокоскоростной сети, например, InfiniBand?


С сетью 10 Gigabit Ehernet выигрыш G системы перед N составляет ~30%. InfiniBand обладает пропускной способностью близкой к шины PCI-e. Поэтому никакого существенного выигрыша G системы перед N не будет. Даже наоборот, разжатие данных и передача их по PCI-e (в GPU и обратно) может занять время большее, чем просто передача по InfiniBand.

Главный недостаток InfiniBand - это его стоимость. Далеко не каждая организация может себе ее позволить.

MySQL не является принципиально влияющей СУБД на скорость тестов, предложенных в докладе?


MySQL является отправной точкой для расчетов и реализации. Если использовать другую СУБД, то цифры изменятся. Например, СУБД PostgreSQL выполняет запросы теста TPCH за примерно то же время, что и СУБД MySQL, но некоторые запросы обрабатываются дольше, другие быстрее.

Объем передаваемых данных по сети не зависит от СУБД. Выбор СУБД по большей части влияет на скорость выполнения JOIN и SORT.

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


Вы здесь » Научно-образовательный IT-форум при КНИТУ-КАИ » Доклады и заметки » Гибридные технологии консервативных СУБД больших объемов