Ускорение СУБД с помощью GPU и CUDA.

Изучал тут про cuDNN и прочее "глубокое обучение" на GPU и напоролся на такое http://cs.kai.ru/proekty/niokr/74-razrabotka-gpu-subd-dlya-platformy-vychislitelnogo-klastera.

Суть что обычную небольшую базу данных засунули в видеопамять видеокарты NVIDIA и с помощью CUDA получили в тестах ускорение для "сложных запросов" до 32 раз по сравнению с обычными CPU.

Но для простых запросов или с индексами/первичными ключами ускорения почти не было.

Вот возникла мысль заюзать это "ускорение" путем приобретения "дешевых" видеокарт с хорошими объемами внутренней памяти (2-4 гига) сборки из них некой системы/кластера и получения бюджетного суперсервера.

(0)+ На sql.ru уже вроде обсуждали http://www.sql.ru/forum/907011/subd-ispolzuushhaya-vychisleniya-na-gpu

от лишь бы не работать. любой херней будем заниматься

то бишь видеопамять круче встроенного кеша в проц?

там выигрыш весь на параллелизме. чего в 1с не бывает. как и сложных запросов.

они в 1с не сложные, а ипанутые. как и структура бд

а проигрышь - nvidia + cuda в реализации хз на чем. я книжку листал по ней - там на фортране чтоли все было

(3) Угу и круче SSD в разы и даже обычной DDR3 RAM

(4) Так задача обычного sql сервера как раз и состоит в параллелизме, когда одновременная обработка кучи запросов от разных клиентов.

>>Вот возникла мысль заюзать это "ускорение" путем приобретения "дешевых" видеокарт с хорошими объемами внутренней памяти (2-4 гига) сборки из них некой системы/кластера и получения бюджетного суперсервера.

Люди еще теорию не проработали даже, а ты уже в продакшен примеряешь?

(3) ага. брутфорс работает в разы быстрее :)

(6) не путай свою шерсть и государственную

задачи sql - чтобы быстро
задачи 1с чтобы доступно и всерьез

GPU — это "числодробилка" для флоатов. Ну, матрицы в один проход перемножать умеют. Каким боком тут базы данных?

(10) если б я уже понял... Пока пытаюсь разобраться как

(11) да очень просто. разрабатываешь свою СУБД, которая умеет чота считать на видеокарте и всё.

(12) Хорошая идея для стартапа в Сколково...

(11) ты же не надеешься, что можно заставить 1C или MS SQLServer чего то там считать на видюхе. Хотя SQLServer вполне может быть уже и использует видюху.

(13) пилить хочешь? пилилка еще не отросла.

>разрабатываешь свою СУБД

уже все разработано

"Стебелек"

В инете давно ходит байка, что на производительность 1С влияет видеокарта. Я думал это юмор, но видимо в любой шутке есть доля...

(14) Не надеюсь что саму 1С а вот sql сервер почему бы и нет?
Да банальную ВК для 1С наваять которая может использовать GPU для шустрой обработки чего то.

(15) Ну вдруг напильник попросят ))

(16) + https://github.com/antonmks/Alenka

(3) Дело далеко не в видеопамяти.
Процессор один, а в видеокарте их около четырех сотен.
Правда узкоспециализированных.
Поэтому если задача паралелиться, то можно получить ускорение в 400раз.

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

(10) Ну теоретически можно придумать некоторые моменты работы с БД, требующие вычислений, и чтобы эти вычисления легко паралелились, и получить очень быстрого сферического коня в вакууме.

(19) ну вот. скопипасть, назови "Иванушка" и в сколково

На узко специфичных задачах типа брутофорсов это давно работает.
Тот же майнинг криптовалюты, или подбор цепочек ДНК.

Чтобы посчитать что-то на видюхе, сначала это что-то нужно туда передать, т.к. процессоры видюхи только с ее памятью могут работать (либо отображаемой для встроенной графики).

ИМХО, идея с СУБД тухлая, т.к. даже современные видюхи имеют всего навсего 8 ГБ на борту.

Jump уже написал, где можно применять мощь видюх.

(24) Выборка/сортировка/соединения/группировка в базах данных по умолчанию хорошо параллелится

(22) затраты на придумывания и реализацию себя не окупят

есть задачи хорошо укладывающиеся в подобные "оптимизации"

а есть - которым ни жарко ни холодно

а есть которым будет хуже - из-за накладных расходов

(25) Правильно, поэтому для сильно больших баз это не актуально.
Но если часть (часто используемую) базы засунуть в память видеокарт как в некий кэш и далее работать с ней там?

Понятно что будет долгий старт сервер (пока данные с диска в видеопамять копируем) и долгое выключение сервера (из видеопамяти скидываем на диск).

Вот тут https://habrahabr.ru/company/mailru/blog/266811/ хорошая статья про устройство РСУБД.
Из всего, что требует вычислительной мощи, можно выделить расчет хешей, расчет статистики и оптимизатор запросов. Вся остальная работа СУБД укладывается в формулу: "Пойди туда — сам знаешь куда, принеси то — сам знаешь что. И побыстрее!"

+ вот ещё хорошая статься для понимания JOIN https://habrahabr.ru/post/278087/

(0)СУБД это в основном работа с данными, прочитать, записать, и каких то мега сложных громоздких параллельных вычислений не предполагается на ней выполнять. Это все ранво что ускорять файловую систему ntfs за счет CUDA.

Сложными вычислениями занимается уже конкретное приложение  его и нужно затачивать под использование видеокарт.

(0) Идея интересная, но имеет много подводных камней. Если очень хочется скорости для СУБД, то можно поступить проще. Берем 32+ ГБ DDR3/DDR4 памяти, создаем виртуальный диск в памяти и получаем скорость записи и чтения 8-9 ГБ/с. В 32 раза это конечно не ускорит, но в несколько раз думаю легко, особенно для 1с+postgresql с их блокировками таблиц.

(32) Слишком стандартно и никакого ускорения от например параллельной проверки на условия в выборке, путем разделения таблицы между процессорами на равные куски.

(32) Я так делал. Для 1с этот вариант не сработает. Потому, что узким местом будет не чтение/запись базы данных, а алгоритмы внутреннего движка самого 1С которые достаточно прожорливы .

Ускорить работу 1С можно только увеличивая частоту/скорость работы процессора и памяти.

обычный сервер и проц то на 100% не использует, а данные и так в кэше лежат

Как понимаю Хэш джойн на картах считают?

(29) (30) Фишка GPU не вычислительная мощь, как раз одно ядро GPU не сильно быстрое но их же дофига!

Больше на вскидку нигде параллельность не применить

*вычислительную

(26) Да.
Но должны быть запросы с кучей таких вещей, чтобы это себя оправдало.
Т.е опять же узкая специализация.

Можно увидеть конкретную ситуацию с кучей таких запросов, и купить под это дело кластер из видеокарт.

А вот имея кластер видеокарт, искать под него задачи - дело глухое.

(28) Не понял в чем смысл использования памяти видеокарт???
Не проще ли оперативную память использовать?
Это проще, дешевле, быстрее, и производительнее.

(37) Это как раз и есть вычислительная мощь.

(36) Так как наличие индексов не дает прироста, то скорее всего так и есть

(31) Попробуйте написать алгоритм "кодом" для получения результата сложного запроса 1С.

Причем никаких Сортировать() или Группировать() из коробки у ТЗ не использовать, чисто методом пузырька или другими.

И вот поговорим о сложности вычислительной...

(41) DDR3 vs GDDR5, но что обычная оперативка дешевле это так.
Но с обычной проблема с кол-вом ядер, вроде больше 8 пока нет в широком доступе камней. Хотим больше ядер придется разоряться на кластер из нескольких блейдов.

Автор еще аналог ТВ не дописал, а уже что то новое мутит. Мощён.

(46) https://habrahabr.ru/post/137723/

(47) Это все ты?

До появления SSD была такая вещь, как RAM-диск, чтобы все данные в памяти жили. Сейчас, правда, не очень актуальная, так как все данные итак можно сложить в памяти.
Что касается множества процессоров, то число теоретически, можно даже сравнение строк выполнять сразу скопом (по шине памяти), которая, например, у видеокарт 256 или 512 бит.
То есть поиск строк по совпадению без индекса, конечно, видеокарта сможет ускорить очень сильно - вопрос только в том, что проще добавить индекс и не сканировать все таблицы.

(48) Нет это не я, но я сделал подобный лисапед свой

(49) Да но индексы они требуют просто дофига места на hdd/ssd и накладных затрат на создания/поддержание/обновление.

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

(51) Вообще принято деление на ОЛТП с минимум индексов и ОЛАП где уже все как надо.

(52) А в курсе сколько времени занимает заливка данных (с вычислениями) в OLAP? Прежде чем можно ее нагружать будет

(53) Вот тут моно параллельностьпо полной юзать