Компания MapD Technologies объявила (http://www.prnewswire.com/news-releases/mapd-technologies-op...) об открытии исходных текстов СУБД MapD Core (https://www.mapd.com/products/core/), обеспечивающей создание хранилища в оперативной памяти (IMDB - in-memory database). СУБД поддерживает SQL и оптимизирована для решения задач по анализу и визуализации данных. Код написан на языках C++ и Go, и распространяется (https://github.com/mapd/mapd-core) под лицензией Apache 2.0.
Особенностью MapD Core является задействование GPU (поддерживается NVIDIA CUDA) для ускорения анализа данных. Отмечается, что обработка данных на стороне GPU позволяет за миллисекунды выполнять запросы, охватывающие миллиарды строк, что на порядок быстрее, чем можно добиться от самых быстрых решений на основе CPU. Например, на системе с несколькими современными видеокартами можно добиться пропускной способности при работе с видеопамятью на уровне 6 TB/sec, что более чем в 40 раз быстрее, чем при работе с памятью на обычном сервере.
Если размер хранимых данных сопоставим с суммарным размером видеопамяти (VRAM) всех GPU, то данные хранятся (https://www.mapd.com/faq/) только в видеопамяти. В противном случае видеопамять всех имеющихся GPU используется как низкоуровневый кэш, в котором поддерживается набор столбцов, наиболее часто востребованных в запросах, а для обработки сложных запросов применяется комбинированная схема, в которой параллельно используются CPU и GPU. Для экономии памяти данные хранятся в сжатом виде.Общий размер хранилища может многократно превышать размер видеопамяти и ограничен лишь возможностями по наращиванию ОЗУ. Но подобный комбинированный подход медленнее, поэтому для достижения наивысшей производительности рекомендуется, чтобы все данные вмещались в видеопамять. Для сохранения состояния БД между перезапусками возможно поддержание актуального архива данных на SSD-накопителях.
Запросы оформляются на обычном SQL. Поддерживается создание фильтров, группировка, агрегирование данных, слияния запросов (join).
Каждый SQL-запрос компилируется с использованием JIT-компилятора в форму, пригодную для выполнения на GPU NVIDIA, а также в вид машинных инструкций для CPU. Такой подход, основанный на идее компиляции SQL в готовый к исполнению обработчик, позволяет обойтись без интерпретаторов и планировщиков запросов. При обработке данных применяется массовое распараллеливание операций, что позволяет добиться максимальной производительности без необходимости использования индексов (перебор огромным числом параллельно выполняемых потоков выполняется быстрее, чем при использовании индексов).
Для подсоединения к СУБД поддерживаются интерфейсы JDBC, ODBC, Apache Thrift, Kafka и Sqoop. MapD также предоставляет встроенный движок отрисовки, позволяющий визуализировать результаты выполнения запросов в виде PNG-изображений на стороне СУБД (для визуализации на стороне клиента требуется передача больших объёмов данных по сети). В случае необходимости создания больших хранилищ или для обеспечения отказоустойчивости предоставляются средства для развёртывания распределённых конфигураций. При этом движок визуализации, компоненты для создании кластерных конфигураций, а также драйверы ODBC и LDAP остаются закрытыми и доступны только в коммерческой редакции MapD Analytics Platform Enterprise Edition.
URL: https://www.mapd.com/blog/2017/05/08/mapd-open-sources-gpu-p.../
Новость: https://www.opennet.ru/opennews/art.shtml?num=46553
Фигня! Хочу чтобы БД хранила данные в буфере клавиатуры! Сколько там в 8042? Байт 16 точно есть.
NVIDIA GEFORCE GTX 1080 поставляется с 64Гб видеопамяти.
Даже не близко.
> 64 Гб.Пруф модели будет? На ямаркете есть только с 11264 Мб.
"Заправь плечи" у титанаХ этой линейки куда как меньше.
при этом в задачи памяти типа gddr не входит контроль и обеспечение целостности данных.
nvidia говорит что опционально включаемо начиная с fermi
на tesla 20x говорит что кэш и регистры автоматически ecc
Бывают разные, даже с процессором и около 64к памяти.
Есть радеоны с терабайтным SSD на борту. Луркай Radeon Pro SSG.Ссылка: http://www.amd.com/Documents/Radeon-Pro-SSG-Technical-Brief.pdf
> СУБД MapD Core, использующей GPU для хранения и обработки данных, поддерживает SQLВсякие куды, шейдеры, вулканы теперь не нужны. Теперь пикселя считает база! Ждем ААА игры на SQL!
Ну и откуда петросяновщина? Вроде ж уже все в курсе, что "видеокарты" - это такие мощные параллельные считалки чего попало?
Увидели знакомые слова "СУБД" и "GPU" в непривычной связке, шаблон порвало, вот и начали "хохмить" (а по факту демонстрировать свою неосведомленность; по уровню комментариев видно, что их авторы не удосужились ну хотя бы прочитать статью "CUDA" в википедии).
> Ну и откуда петросяновщина? Вроде ж уже все в курсе, что "видеокарты"
> - это такиемалонужные асики, которые умеют немного майнить и запускать иоба, но их покупку нужно как-то обосновать руководству/родителям.
видяха не асик
пруф?
> пруф?- электровоз — не самолёт
- пруф?
электровоз от самолета можно визуально отличить.
ты без рентгена и не имея исходников фирмвари, которой прошиваются видяхи умеешь отличить асик или нет?!
да ты супермен!
Да ладно... Ты не можешь визуально отличить асик от видеокарты?
тёплое от мягкого...а ну ка, умник, скажи что где изображено?
http://i.imgur.com/B5rPveu.png
где ASIC где GPU - а где CPU, если что?!
> тёплое от мягкого...
> а ну ка, умник, скажи что где изображено?
> http://i.imgur.com/B5rPveu.png
> где ASIC где GPU - а где CPU, если что?!Микросхемы какие-то. Среди них нет видеокарты.
Подсказка: У асика нет VGA разьема
> электровоз от самолета можно визуально отличить.
> ты без рентгена и не имея исходников фирмвари, которой прошиваются видяхи умеешь
> отличить асик или нет?!
> да ты супермен!А материнскую плату от клавиатуры ты можешь отличить визуально?
> Вроде ж уже все в курсе, что "видеокарты" - это такие мощные параллельные считалки чего попало?На самом деле нет, не чего попало. И таки да, всем известно что на GPGPU (а не любое GPU) можно эффективно считать только ограниченный круг задач.
Понятно, что я преувеличил слегка для простоты, но то, что выше - совсем уж ярый гон.
> Ну и откуда петросяновщина? Вроде ж уже все в курсе, что "видеокарты"
> - это такие мощные параллельные считалки чего попало?Невежество в данном вопросе колоссальное у людей думающих что мощные параллельные считалки чего попало (на самом деле далеко не чего попало) будут хорошо работать реализуя например бизнес-логику реляционных баз данных.
То что сказано в новости- узкий круг специфичных задач...
В новости нигде и не сказано, что эту штуку позиционируют как конкурента "СУБД общего назначения". Да, это нишевый инструмент. И что?
Из-за чего бурление? Из-за того, что ребята написали интересную штуковину да ещё и открыли код?
Правильно ! Да здравствуют БД на GPU и графика на CPU !
>Правильно ! Да здравствуют БД на GPU и графика на CPU !и фреймбуффер на SSD
срочно выкидываем все стойки с блэйдами и ставим писюки набитые видюшками...
Так уже давно делают, см. из чего сделаны разные кластера из торNNN.
Вот, теперь твой черёд капитаном Очевидность поработать... Могу тоже прицепиться - туда не совсем писюки пихают и не совсем с видюшками (а таки с GPGPU)... но, опять же, в сравнении с явным невежеством товарища выше - не принципиально.
да, явное невежество товарищей не понимающих разницы между вычислительным кластером и инфраструктурой для баз данных - на лицо :)
> Так уже давно делают, см. из чего сделаны разные кластера из торNNN.и на скольки изэтих кластеров работают базы данных????
Ну чего , парни ищут инвестиции, порадоваться за них надо. вон какую презентацию налабали,даже на русский перевели, не иначе, на сколковский гранд рассчитывают. Интересно, кроме синтетики, это вообще можно применить для хоть каких-то данных
Неа, более того, тот же ClickHouse для задач аналитики на CPU уделывает этого немасштабируемого монстра, ведь ему не требуется железо за котлету денег и скейлится на многие задачи он горизонтально и почти линейно.
Звучит, конечно, как фантастика.Ребята не юзают ни индесов, ни оптимизаторы и на каждый запрос тупо перебирают всю базу. Понятное дело, что сложную логику на gpu сложно реализовывать, но для практического использования этот метод не подойдет. Если сейчас размер бд ограничивается памятью видеокарт, то его можно применять только в очень узких задачах (в статье написано, что можно использовать базы большие, чем память видеокарт, но, если для любого запроса нужно все данные пропускать через память карточки, то более традиционные in-memory бд с оптмизациями будут намного выигрышнее).
Хотя перспективы, конечно, большие.
>Ребята не юзают ни индесов, ни оптимизаторы и на каждый запрос тупо перебирают всю базуТаких изобретателей квадратноколёсых велосипедов полно. Тоже встречал деятелей, которые полгода на си писали бизнеслогику (ну анси си же быстрый!11111) на самодельных структурах, подозреваю, что на банальных array-ях.
Потом (мне) было очень смешно, когда первая попавшаяся графовая субд написанная на "тормозной жабе" порвала эту поделку как Тузика.
Опять ты свои байки рассказываешь :)>когда первая попавшаяся графовая субд
Что за БД? Сколько в нее угрохали сил и времени? Тоже полгода потратили? Не верю.
>Что за БД? Сколько в нее угрохали сил и времени?Читать глазами, а не Ж не пробовал? Вместо велосипеда на си взяли готовую субд (название не вижу смысла писать) и оно оказалось быстрее в тысячи раз.
Уверен, что на не локалхостовых проектах MapD сольёт банальной ну например Кассандре.
> Уверен, что на не локалхостовых проектах MapD сольёт банальной ну например Кассандре.Отличная отмазка. Если что, то проект "недостаточно нелокалхостен", да?
> и оно оказалось быстрее в тысячи раз.
Ну, тут конечно не тысяча, а только четверь, зато вполне конкретно, а не "название не вижу смысла писать" ...
https://www.reddit.com/r/programming/comments/2svijo/command.../
> Command-line tools can be 235x faster than your Hadoop clusterИ что теперь? Выкидываем все хадопы или все же задумываемся о рукопопии?
Хотя да, если продолжать традиции опеннета:
Быстрее в 235 раз, Карл!
хадоп == жабка, юникстулс == си,
235х ... обтекайте. :)
> хадоп == жабка, юникстулс == си,
> 235х ... обтекайте. :)Там еще веселее, основную работу делает код на awk, так что это awk в 235 раз быстрее жабы :)
1ГБ тестовых данных для распределенных вычислений, это мощно! Типичный кульсисоп локалхоста опоносил Хадуп. Другие кульсисопы бездумно разносят помои дальше по инету...А караван идёт себе дальше... Кстати, Хадуп был моден 10 лет назад, щас рулит Spark.
.
А вот встроенный движок отрисовки диаграмм в PNG - зачётно. Сколько приходится городить костылей в бизнес приложения из-за этого. GnuPlot, MatPlotlib, RRDTools, GoogleChart и еще с десяток - так или иначе приходится изучать и лепить... в 80% случаев ради десятка простых диаграмм. Хочу в SQLite такую штуку.А в целом у современных компьютеров, продающихся в розницу - 50% цены это видюха. Грех не задействовать это добро. Вот в LibreOffice - включенный OpenCL реально помогает в расчетах больших таблиц, ускорение расчета в 4-8 раз.
> А вот встроенный движок отрисовки диаграмм в PNG - зачётно. Сколько приходитсяненужная чушь
> городить костылей в бизнес приложения из-за этого. GnuPlot, MatPlotlib, RRDTools, GoogleChart
> и еще с десяток - так или иначе приходится изучать и
> лепить... в 80% случаев ради десятка простых диаграмм. Хочу в SQLite
> такую штуку.Возьмите готовый BI или его бесплатный аналог и не мучайтесь.
> А в целом у современных компьютеров, продающихся в розницу - 50% цены
> это видюха. Грех не задействовать это добро. Вот в LibreOffice -
> включенный OpenCL реально помогает в расчетах больших таблиц, ускорение расчета в
> 4-8 раз.Задействовать то можно.. но чтоб оно было прозрачно и без необходимости переустанавливать инфраструктуру.
Вроде постгрес уже давно обещали видюхами ускорять, правда я забросил следить за этим делом
CUDA - проприетарщина, поэтому опенсорсу толку от этого ноль.
Практически всё железо проприетарщина. Но Вы же сюда не с "Паскалины" пишет.
Хорошо, для анализа видео/аудио информации самое оно! Можно писать систему наблюдения и безопасности на ней.
А что, GPU уже научились работать с целочисленными данными, битовыми и символьными строками wchаr/wstring? Или о каких данных идет речь?
О тех, с которыми они работать умеют, вестимо.Из того, что я видел - та же финансовая статистика во float ложится отлично, для аналитики там куча однообразных расчётов, так что CPU-bound выходит, а объёмы хоть и приличные, но довольно предсказуемые, из оперативки заливать в "горячий кэш" на видеокарте - вполне реально.
Полагаю это может быть полезно для алгоритмов Machine Learning.
Где скорее важно работать не с текстом, а с всевозможными алгоритмами, использующими его векторизацию тем или иным способом. Например TF-IDF, Word2Vec и другие. И мы получаем какраз представление текста как разреженного вектора float высокой размерности (легко размерность может быть до миллиона, если текст не слишком короткий). А тут уже, скажем для алгоритмов кластеризации, где нужно считать расстояния между разреженными векторами GPU какраз должно быть, теоретически, весьма эффективно.
а как там у видеокарт с памятью в плане коррекции ошибок? где то читал там память в этом смысле даже хуже чем обычная, важна скорость и ошибки там не исправляются.
вы часто сталкивались с проблемами решаемыми коррекцией ошибок памяти?
Одно время занимался отладкой в специфичном ядре этой самой корекции.
Вродебы польза есть.
Идя хорошая. Рано или поздно комп начнет строиться вокруг пула процессоров (GPU), а не ЦП.ЦП уже сейчас работает как IO периферия для GPU.
круто!
а про перебор данных для обучения нейросетей только я подумал?
там таких объемов что в память влезает может хватить вполне
