Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

BlazingSQL is Now Open Source

blog.blazingdb.com

Post reply on HN
Print view View original

11–20 of 65 posts

Re: BlazingSQL is Now Open Source

#11

Post by felipe_aramburu »

reilly3000 wrote: post #9
bsamuels wrote: 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

Blazingsql is built on top of CUDF. We are contributors to rapidsai

Re: BlazingSQL is Now Open Source

#12

Post by tombert »

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.)

Re: BlazingSQL is Now Open Source

#13

Post by felipe_aramburu »

bsamuels wrote: 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

This is a Distributed SQL engine not a database. We store no data. You store your data in HDFS, S3, posix, NFS etc. We allow you to query directly from these filesystems of the file formats you have already. You can look here to see the file formats cudf supports. https://github.com/rapidsai/cudf/tree/branch-0.9/cpp/src/io

You can try it out yourself here https://colab.research.google.com/drive/1r7S15Ie33yRw8cmET7_...

Or use dockerhub https://hub.docker.com/r/blazingdb/blazingsql/

The benefits are.

Greatly increased processing capacities. We can just perform orders of magnitudes more instructions per second than a cpu with the gpus we are using.

Decompression and parsing of formats like CSV and parquet happens in the GPU orders of magnitude faster than the best cpu alternatives.

You can take the output of your queries and provide it to machine learning jobs with zero copy ipc and get the results back the same way. We are all about interoperability with the rapidsai eco system.

Re: BlazingSQL is Now Open Source

#14

Post by rburhum »

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

Re: BlazingSQL is Now Open Source

#16

Post by lmeyerov »

samstave wrote: post #6

Can someone give me some use case examples? I read that site, and the RAPIDS site - but would like to hear from some ppl using this in prod/test and what they are using it for...

We worked with the team early on it. In turn, that means it's inside one of the powertools at gov, bank, etc. teams, even if most of the users don't quite know what a GPU DB is :) We do GPU visual graph analytics over event data (security, fraud, customer 360, ...). We use for a bunch: interactive sub-100ms timebars, histograms, etc. Any full-table compute stuff you'd do in pandas, sql, spark, etc. Any UI interaction like a filter can trigger tons of queries, and w/ GPUs, that means they can quickly compute all sorts of things.

The reason Graphistry picked BlazingSQL is it fit in as part of our approach of end-to-end GPU services that compose by sharing in-memory Apache Arrow format columnar data. When the Blazing team aligned on Nvidia RAPIDS more deeply than the other 2nd-wave GPU analytics engines, it made the most sense as an embedded compute dependency. Going forward, that means Blazing can focus on making a great SQL engine, and we know the rate of their GPU progress won't be pegged to their team but to RAPIDS. A surprise win over just cudf (python) was eliminating most of the constant overheads (10ms->1ms / call), and looking forward, seems like an easier path to multi/many-GPU vs. cudf (dask).

We should share a tech report at some point - bravo to the team!

Re: BlazingSQL is Now Open Source

#17

Post by felipe_aramburu »

tombert wrote: 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.)

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 built up lots of expertise in this specific way of coding for GPUS. We also found time and time again that it was faster than opencl for what we were trying to do and the hardware available to us on cloud providers was Nvidia GPUs.

The second answer to this question is that blazingsql is part of a greater ecosystem. rapids.ai and the largest contributor by far is Nvidia. We are really happy to be working with their developers to grow this eco system and that means that the technology will probably be CUDA only unless we somehow program "backends" like they did with thrust but that would be eons away from now.

Re: BlazingSQL is Now Open Source

#18

Post by chrisjc »

felipe_aramburu wrote: post #13
bsamuels wrote: 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

This is a Distributed SQL engine not a database. We store no data. You store your data in HDFS, S3, posix, NFS etc. We allow you to query directly from these filesystems of the file formats you have already. You can look here to see the file formats cudf supports. https://github.com/rapidsai/cudf/tree/branch-0.9/cpp/src/io You can try it out yourself here https://colab.research.google.com/drive/1r7S15Ie33yRw8cmET7_..…

Is there any reason why a SQL format isn't is that list? Wondering if there's a way to join SQL sources with file storage sources. An example of this would be filtering or enrichment operations.

// sorry if this is a stupid question.

Re: BlazingSQL is Now Open Source

#19

Post by roaramburu »

chrisjc wrote: post #18
felipe_aramburu wrote: post #13

Earlier quoted context omitted.

This is a Distributed SQL engine not a database. We store no data. You store your data in HDFS, S3, posix, NFS etc. We allow you to query directly from these filesystems of the file formats you have already. You can look here to see the file formats cudf supports. https://github.com/rapidsai/cudf/tree/branch-0.9/cpp/src/io You can try it out yourself here https://colab.research.google.com/drive/1r7S15Ie33yRw8cmET7_..…

Is there any reason why a SQL format isn't is that list? Wondering if there's a way to join SQL sources with file storage sources. An example of this would be filtering or enrichment operations. // sorry if this is a stupid question.

Not a stupid question. The reason is priorities, but definitely our ideal to do predicate push down and join databases to files, streams, etc.

Re: BlazingSQL is Now Open Source

#20

Post by tombert »

felipe_aramburu wrote: post #17
tombert wrote: 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.)

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 cheap Nvidia GPU/Jetson Nano and do some processing that way.

Post reply on HN