Live data from Hacker News

BlazingDB uses GPUs to manipulate huge databases in no time

techcrunch.com

31–40 of 76 posts

Re: BlazingDB uses GPUs to manipulate huge databases in no time

#31
post #30

Earlier quoted context omitted.

Limiting your queries to ~12gb, the max ram on one GPU, (beyond which PCIe I/O becomes a bottleneck) will be a problem for business use, I'd think

For some reason I am surprised that anyone would want to ship the data whole and as is, to the GPU. Wouldn't it make more sense to use a representative, transformed "GPU-ready" data set, both much smaller in size & designed specifically for the queries that are to be optimized?

Once you read and prune out the dataset to only include the relevant data, then what's left for the GPU to do?

Re: BlazingDB uses GPUs to manipulate huge databases in no time

#32
post #20

Several companies have implemented databases on GPUs but there is a good technical reason that the approach has never really caught on, and some of these companies even migrated to selling the same platform on CPUs only. The weakness of GPU databases is that while they have fantastic internal bandwidth, their network to the rest of the hardware in a server system is over PCIe, which generally isn't going to be as goo…

It would seem that rationalization would fall apart quickly with the new Power CPUs that have NVLink built right into the CPU. Getting data back and forth shouldn't be a problem anymore. Outside of CPU >> GPU, I'm not sure what other data movement you could be talking about. A SAS HBA or Ethernet NIC or Infiniband HBA are almost always going to be operating over the same PCIe bus the GPU uses. In the rare instances t…

What is NVLink, and what does it mean in terms of data transfer?

Re: BlazingDB uses GPUs to manipulate huge databases in no time

#33
The numbers for GPU databases look “good” because you can get pretty high cross-sectional bandwidth to a reasonably large memory from 8 GPUs in one box, and advertise blazing speed from that. But it’s just a trick.

The only thing that matters for them here is the aggregate, cross-sectional bandwidth to your data’s working set in memory. For databases, especially for the approach that many GPU databases take (light on indexes since GPUs aren’t great at data-dependent memory movement or pointer chasing, just brute-force scan much of the data), the working set size is something that will only fit in main memory.

Instead of using 8 GPUs with a peak global, cross-sectional memory b/w of 8 * 320 = 2560 GB/sec and brute-force scans, you can parallelize across ~40 CPU nodes each with ~60 GB/sec b/w to main memory. The cross-sectional bandwidth will be about the same, and the cost to split and join the results of the query is likely small in comparison to actually doing the work, assuming the intermediate results are reasonably small. You can use a broadcast and reduction tree; the added latency of the broadcast and reduction tree's depth likely won't add much, since there isn’t much data to broadcast in a query, and the data returned by each machine for the reduction is hopefully (!) tiny in proportion to the actual data scanned.

If you want to consider indices on data, then maybe the heads of that can remain resident in a CPU’s cache, and will make the individual CPU scans even faster. The GPU caches are tiny and mainly serve to patch up strided loads and other bad uses of memory.

Whether or not it’s worth it one way or another depends upon how large your database size is, the relative cost of GPUs versus CPU nodes to get the memory you want and the cross-sectional b/w you need, perf/W and other issues.

You’re probably nowhere near close to arithmetic throughput bounds on GPUs or CPUs since these workloads have very low op / byte loaded ratios compared to typical HPC workloads, so that aspect of GPUs doesn’t matter. If you’re doing expensive pre- or post-processing on GPUs as well, then that may push the balance more towards GPUs.

Re: BlazingDB uses GPUs to manipulate huge databases in no time

#34
post #32
post #20

Earlier quoted context omitted.

It would seem that rationalization would fall apart quickly with the new Power CPUs that have NVLink built right into the CPU. Getting data back and forth shouldn't be a problem anymore. Outside of CPU >> GPU, I'm not sure what other data movement you could be talking about. A SAS HBA or Ethernet NIC or Infiniband HBA are almost always going to be operating over the same PCIe bus the GPU uses. In the rare instances t…

What is NVLink, and what does it mean in terms of data transfer?

It's a faster link between between future IBM POWER processors and NVidia GPUs, but won't make waves in database market since those systems are niche HPC/supercomputing hardware.

Re: BlazingDB uses GPUs to manipulate huge databases in no time

#35
post #22
post #15

Earlier quoted context omitted.

It's surprising you can still do cryptocurrency mining with GPUs. Not bitcoin, then?

The GP didn't say that their mining is done on GPUs.

It is implied that mining is how they are familiar with bit error problems in GPUs.

Re: BlazingDB uses GPUs to manipulate huge databases in no time

#36
post #30

Earlier quoted context omitted.

For some reason I am surprised that anyone would want to ship the data whole and as is, to the GPU. Wouldn't it make more sense to use a representative, transformed "GPU-ready" data set, both much smaller in size & designed specifically for the queries that are to be optimized?

Once you read and prune out the dataset to only include the relevant data, then what's left for the GPU to do?

The transformation to GPU-ready would not be as trivial and effectively redundant as pruning the data of course. It would be produce a secondary data structure, like an index on a column, though in this case of course destined to be processed within the math-oriented, high-branch-cost setting of a GPU.

Re: BlazingDB uses GPUs to manipulate huge databases in no time

#37
post #34
post #32

Earlier quoted context omitted.

What is NVLink, and what does it mean in terms of data transfer?

It's a faster link between between future IBM POWER processors and NVidia GPUs, but won't make waves in database market since those systems are niche HPC/supercomputing hardware.

I've also seen NVLink on some of the pre-Pascal roadmaps for nVidia's gaming-oriented graphics cards. Since the current generation gaming consoles has HSA, I'm hoping that it gains in popularity and because less niche. Problem is that it'd be a pretty vital component to be nVidia proprietary.

Re: BlazingDB uses GPUs to manipulate huge databases in no time

#38
post #13

How do they guarantee the correctness of results? A major problem with GPUs is you see single bit errors with surprisingly high frequency. For graphics this usually doesn't matter as a minor color or vertex deviation isn't noticeable, but for compute it can be devastating. We do cryptocurrency mining on an industrial scale and constantly see single bit errors from hardware that is brand-new without modifications.

We do cryptocurrency mining on an industrial scale and constantly see single bit errors from hardware that is brand-new without modifications. That's very surprising and interesting. How do you detect these single bit errors?

Detection of false positives: Run candidate solutions through the CPU

Detection of false negatives: Compare solution distribution and frequency to expected models; switch to debug kernels if outside tolerance.

However, this works because the mining problem space is stateless and follows strict mathematically predictable models.

A DB is stateful and the answers generally can't be verified without consulting a secondary copy, which is why I'm super curious how they would engineer correctness and reliability in a cost-effective way using GPUs.

Re: BlazingDB uses GPUs to manipulate huge databases in no time

#39

Several companies have implemented databases on GPUs but there is a good technical reason that the approach has never really caught on, and some of these companies even migrated to selling the same platform on CPUs only. The weakness of GPU databases is that while they have fantastic internal bandwidth, their network to the rest of the hardware in a server system is over PCIe, which generally isn't going to be as goo…

You pretty much hit the nail on the head, a big limitation is the feeding the GPUs in the first place.

Furthermore, all that memory bandwidth is calculated against all the cores. So you have to be VERY careful in usage patterns (it doesn't work like a giant CPU). Not to mention how much it costs involved per GB or TB!

I have some experience in this area, and where GPU's & database really shine is building (and especially) re-building indexes.

Running a database on GPUs isn't going to replace all DBs overnight. But, the hardware does have it's uses; just like improved SIMD on CPU's and NVMe storage, plus developments in networking - Basically look where Intel is going since we're coming to the limits of silicon transistors..

Re: BlazingDB uses GPUs to manipulate huge databases in no time

#40
post #15

How do they guarantee the correctness of results? A major problem with GPUs is you see single bit errors with surprisingly high frequency. For graphics this usually doesn't matter as a minor color or vertex deviation isn't noticeable, but for compute it can be devastating. We do cryptocurrency mining on an industrial scale and constantly see single bit errors from hardware that is brand-new without modifications.

It's surprising you can still do cryptocurrency mining with GPUs. Not bitcoin, then?

Ethereum, Monero, and even Ethereum-Classic (difficulty/arbitrage/exchange rate permitting) are all good GPU candidates -

SHA-256d (Bitcoin) and Scrypt (Litecoin) have ASICs, X11 (Dash - formerly Darkcoin) has FPGAs.

Post reply on HN