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

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

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


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


Архитектура параллельной СУБД на платформе GPU-кластера

Сообщений 11 страница 12 из 12

1

АРХИТЕКТУРА ПАРАЛЛЕЛЬНОЙ СУБД НА ПЛАТФОРМЕ GPU-КЛАСТЕРА
Дмитрий Александрович Павлов, southpark444@yandex.ru
Руководитель: Р.Ш. Минязев
Казанский национальный исследовательский технический университет им. А.Н. Туполева

Рассматривается архитектура параллельной СУБД, функционирующей на платформе GPU-кластера. На GPU выполняются операции SELECT, PROJECT, JOIN. База данных делится горизонтально с использованием операции хеширования по ключевому полю каждого отношения. Каждый GPU-акселератор хранит в своей памяти свой фрагмент базы данных. Вычислительный узел хранит все фрагменты исходной базы данных в своей оперативной памяти. Рассматривается случай работы с консервативными данными, объем которых соизмерим с объемом оперативной памяти вычислительного узла.

МАТЕРИАЛЫ ДОКЛАДА

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

Отредактировано Shigapova (2014-05-30 22:31:46)

11

Доброе время суток. Просмотрев и прослушав данную работу возникли неоднозначные чувства, по поводу проделанной работы. Итак по порядку:
1) Высокопроизводительные веб-порталы. Как я понял ваша работа подразумевает разработку АИС, которая будет обрабатывать огромный поток данных и выводить информацию по требованию пользователя. И для более высокой скорости обработки запроса, вы используете GPU, в качестве дополнительной среды обработки запроса. Я правильно понял?
2) Реализация именно самих команд запросов, выполняемых с помощью GPU-акселераторов не совсем понятна. Каким образом происходит обращение памяти GPU с сетевым запросом? Какие именно данные вы хотите ускорить вывод и ввод? Что получит конечный пользователь, который отправлял SQL запрос? Где хранятся данные на момент получения запроса? Как происходит распределение нагрузки?
3) Следующий момент. База данных хранится на всех узлах вашей ветки. Опять таки вопрос, а что произойдет, если база данных будет превышать размер памяти кластеров? Как будет реализовано соединение данных в этом случае?
4) Дальше идет самая мутная часть. Вы проводите эксперимент и получаете данные скоростных замеров выполнения операции. Но как я понял это релевантно лишь для единичного запроса, единичного пользователя. А что будет если будет 10 000 пользователей, которые отправят хотя бы по 2-3 запроса? Что произойдет со скоростью обработки запроса? Как оно будет отличаться от результата для одного пользователя? По моему скромному мнению двоечника, вы пытаетесь иррационально использовать вычислительную мощь кластеров, т.к. при большой нагрузке, скорее всего финальная производительность метода будет зависеть уже не от дополнительной мощности GPU, а пропускной способности сети, жесткого диска и всевозможных других параметров. Тогда возникает резонный вопрос, а чем он лучше существующих ныне методов и подходов? Опять таки нет результатов сравнения эксперимента с действующей системой стандартного подхода.
5) Выходящий из 4 пункта вопрос, а на сколько метод доступен с коммерческой стороны? В чем резон использовать метод? Дешевле или дороже он аналога? В чем может быть сложности применения вашей работы на практике? Опять таки внятного ответа на эти вопросы я не услышал.

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

12

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

1) Можно сделать акцент не на повышении числа запросов в секунду, а на максимально быстром ответе на каждый запрос, которых может быть и не очень много. Соответственно выбирать область применения.
2) Данные до начала работы загружаются в память GPU. Система осуществляет выборку данных по SQL-запросу, как и любая другая СУБД. Этот запрос как раз и может приходить по сети.
4) Оптимизация алгоритмов использования GPU для работы именно на кластере (параллельного выполнения запросов от нескольких пользователей и т.д.) - отдельная задача, и в рамках диссертационной работы я ее не решал вообще.
5) Аналогично, анализ коммерческой выгоды и выявление всех подводных камней - это скорее тема для отдельного исследования.


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