News for hackers. Stuff that matters.
Re:BlazingSQL – A GPU SQL Engine for RAPIDS Open-Source Soft... by fulafel on Friday October 12, 2018 @09:32AM (#18201274)
High end GPU memories are quite big (multi-GB), so the whole database fits in GPU memory for most databases. And this seems to support distributing the database over many servers and GPUs, so you can get a couple of order of magnitudes bigger via that route.
Re:BlazingSQL – A GPU SQL Engine for RAPIDS Open-Source Soft... by arnon on Friday October 12, 2018 @09:37AM (#18201305)
32GB is big?
Re:BlazingSQL – A GPU SQL Engine for RAPIDS Open-Source Soft... by randyzwitch on Friday October 12, 2018 @10:16AM (#18201551)
The p2.16xlarge EC2 GPU instance has 16 GPUs, 732GB of GPU RAM.
Re:BlazingSQL – A GPU SQL Engine for RAPIDS Open-Source Soft... by arnon on Friday October 12, 2018 @10:21AM (#18201586)
You're assuming the data is split among the K80 GPUs (12GB per GPU instance), which may not be the case here. Who's doing the split? How is the data partitioned along the GPUs?
Re:BlazingSQL – A GPU SQL Engine for RAPIDS Open-Source Soft... by felipe_aramburu on Friday October 12, 2018 @10:42AM (#18201738)
Hopefull the library that the user is employing! In our case we have a few different components that actually make up BlazingSQL. We have Relational Algebra nodes that are stateless and can do nothing but receive inputs and interpret relational algebra. They are coordinated by an orchestration node whose purpose it is to divide up queries.

There are three cases to consider here for dividing up the data.

1. Data coming from the user in Python this can be large or small, if it is large you can partition it amongst the nodes, if small you can just let every node have a copy, what is large or small depends on the size of your nodes, the interconnect, etc. 2. Data that resides in the datalake You can partition the dataset by dividing up the files and having each node perform the i/o necessary to retrieve that data and start processing it 3. Data that resides in previous distributed result sets this is great because well its already partitioned for you. If you have some nodes with large percentages of the result set you might make those partitions

So thats just for getting the query started. After that there are loads of operations that are not trivial to distribute. ( distributiong a + b is a heck of a lot easier than doing a distributed join). To reduce the amount of coordination we need between nodes something we do is sample before execution and generate partitioning strategies that will allow each node to PUSH its information to another node whenever this is required. This is much simpler than trying to coordinate distribution during the execution phase and allows every node to keep moving its process forward.

Re:BlazingSQL – A GPU SQL Engine for RAPIDS Open-Source Soft... by randyzwitch on Friday October 12, 2018 @10:39AM (#18201719)
Can you point to a commercial GPU database offering that doesn't distribute calculations over multiple GPUs out-of-the-box? That's table stakes, not a point of differentiation.
Re:BlazingSQL – A GPU SQL Engine for RAPIDS Open-Source Soft... by fulafel on Friday October 12, 2018 @10:45AM (#18201766)
Yes, in a database context. It's bigger than most databases. You can fit billions of items there.
Re:BlazingSQL – A GPU SQL Engine for RAPIDS Open-Source Soft... by arnon on Friday October 12, 2018 @11:31AM (#18202093)
I've had larger excel sheets :P