Live data from Hacker News

BlazingSQL is Now Open Source

blog.blazingdb.com

21–30 of 65 posts

Re: BlazingSQL is Now Open Source

#21
post #7

What kind of benefits does CUDA bring to databases? I've never heard of running a database on a GPU before. Couldn't find anything on their homepage other than comparison with a few other db options

Check out https://www.omnisci.com/learn/resources/gpu-database In summary, you get snappy, interactive query speeds on large data sets. I've ran that locally and the results are pretty amazing compared to Postgres or even Tableau in-memory. I'm personally more excited about GPUs in stream processing; its just quite a natural fit: https://github.com/rapidsai/cudf

If you're interested in stream processing, check out FASTDATA.io PlasmaENGINE. We do both stream and batch processing with Apache Spark on the GPU.

https://fastdata.io/plasma-engine/

* It's not open-source and I work there.

Re: BlazingSQL is Now Open Source

#22
post #20

Earlier quoted context omitted.

Thats a great question. The answer is two-fold. Early on when we first started playing around with General Processing on GPU's we had Nvidia cards to begin with and I started looking at the apis that were available to me. The CUDA ones were easier for me to get started, had tons of learning content that Nvidia provided, and were more performant on the cards that I had at the time compared to other options. So we buil…

Thanks for answering my question so quickly! That seems like a pretty good reason...I have been looking to learn some GPU programming to optimize some matrix math that I've been doing for a pet project, and while my first instinct was telling me OpenCL since it's portable, if people who actually know what they're talking about are saying that CUDA is simpler to start with, it might be worth it to me to pick up a chea…

The collab link below let's you use a gpu for free on Google cloud

Re: BlazingSQL is Now Open Source

#23
post #21

Earlier quoted context omitted.

Check out https://www.omnisci.com/learn/resources/gpu-database In summary, you get snappy, interactive query speeds on large data sets. I've ran that locally and the results are pretty amazing compared to Postgres or even Tableau in-memory. I'm personally more excited about GPUs in stream processing; its just quite a natural fit: https://github.com/rapidsai/cudf

If you're interested in stream processing, check out FASTDATA.io PlasmaENGINE. We do both stream and batch processing with Apache Spark on the GPU. https://fastdata.io/plasma-engine/ * It's not open-source and I work there.

Hi Kichik :)

Re: BlazingSQL is Now Open Source

#24
post #7

What kind of benefits does CUDA bring to databases? I've never heard of running a database on a GPU before. Couldn't find anything on their homepage other than comparison with a few other db options

CUDA by itself brings easy-to-run parallel algorithms. It's not of much value for databases unless you have a proper infrastructure set up to use it correctly. Same is true for columnar aspects, for example.

People have been building columnar databases to do analytics quickly. GPUs (with CUDA) can run analytics operations (think join, group by, math, sorting) on columnar data in a much more efficient manner. They're designed for operations on vectors, which columns are.

We've been doing this ourselves too with SQream DB: https://sqream.com. It's an enterprise data warehouse with GPU acceleration. We use CUDA exclusively too.

Re: BlazingSQL is Now Open Source

#25
post #12

This seems pretty cool, and I'll probably play with this at some point, but sadly literally all of my GPUs are AMD or Intel at this point. I'm sure you had a good reason, so I'm genuinely curious to why CUDA was chosen instead of something like OpenCL? (I'll add my typical disclaimer that I'm not saying this as some passive-aggressive way to criticize; I'm genuinely curious to the reasoning behind the choice.)

CUDA has two APIs:

1. The runtime api (libcudart.so)

2. The driver api (libcuda.so).

The driver api is very close to the opencl api and is very low level. Most people use the CUDA runtime api which is vastly more convenient. The main difficulty with OpenCl and the driver api is that you have to manually load GPU code onto the device which then returns a handle. You generally have to load the code onto every device which means multiple handles for the same function. This makes executing kernel quiet a lot of work. The runtime api does this all automatically which make programming with CUDA quiet easy since launching a kernel is basically a function call. The CUDA rutime also automatically handles context creation which is another time saver.

When I first learned OpenCL I was shocked at how difficult is was to simply write a simple vector add program since there was all this additional code loading, creating contexts, etc. The setup / boiler plate was greater than the actually code itself.

It basically boils down to convenience in my opinion. Couple this with the fact the NVIDIA generally has the most powerful and energy efficient cards and it's no surprise they took the market.

Re: BlazingSQL is Now Open Source

#26
post #5

Is this due to PartiQL?

PartiQL is a query language, based in SQL and extended to be more natural with unstructured and nested data. It can be used with various database and querying engines.

BlazingDB/SQL is a querying engine, more similar to Presto or Apache Drill, and specializes in using GPUs for processing power.

Re: BlazingSQL is Now Open Source

#27
post #14

This is great. The BlazingDB guys are awesome and now that the project is open source this is another good reason for my teams to experiment with different workloads and compare it against a SparkSQL approach

Also! We have a guy in Lima pushing out some GIS work into cuDF and BlazingSQL too.

Re: BlazingSQL is Now Open Source

#29
Looks like an good way to do analytics on the GPU. The Python API is clean and simple.

The premise is that GPUs will accelerate columnar data analytics. And, with "Dask" [1], you can run those worldloads on a cluster.

I wonder if careful indexing on initial write would outperform this system. This system looks like it's best when you have totally raw, unindexed data. Perhaps a future thing to do is to generate a side index during initial column scans to speed up future queries?

Also, GPU memory is pretty expensive. How does the total-cost-of-ownership compare to just running on RAM with powerful multi-core CPUs? There's like 512-bit vector operations these days.

[1]: https://rapids.ai/dask.html

Post reply on HN