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

BlazingDB uses GPUs to manipulate huge databases in no time

techcrunch.com

Post reply on HN
Print view View original

41–50 of 76 posts

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

#41

Post by snuxoll »

jzelinskie wrote: post #37
fulafel wrote: post #34

Earlier quoted context omitted.

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.

CAPI is "open" solution to do the same thing, though NVLink supposedly still offers more bandwidth. Unfortunately CAPI is only available on POWER8 hardware at the moment and I'm not sure if IBM is open to license it beyond OpenPOWER - still, there's a decent number of CAPI-capable cards already available and more coming to the market in the future.

GPU's may not be great for every unit of work a RDBMS has to perform, but given their ability to rapidly compute hashes it could help a lot with joins (as evidenced by PGStrom).

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

#42

Post by escap »

marcell wrote: post #32
tw04 wrote: 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?

http://www.nvidia.com/object/nvlink.html - NVIDIA® NVLink™ is a high-bandwidth, energy-efficient interconnect that enables ultra-fast communication between the CPU and GPU, and between GPUs.

And a big on the PowerPC roadmap http://www.nextplatform.com/2016/04/07/ibm-unfolds-power-chi... "With NVLink, multiple GPUs can be linked by 20 GB/sec links (bi-directional at that speed) to each other or to the Power8 processor so they can share data more rapidly than is possible over PCI-Express 3.0 peripheral links. (Those PCI-Express links top out at 16 GB/sec and, unlike NVLink, they cannot be aggregated to boost the bandwidth between two devices.)"

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

#43

Post by felipe_aramburu »

kusmi wrote: post #19
jandrewrogers wrote: post #8

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…

Is the data stored in GPU memory?

I am the CTO of blazingDB. The data is not stored in GPU or even RAM. We operate from the disk though we we will cache information in RAM when we have plenty of it available.

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

#44

Post by dharma1 »

jandrewrogers wrote: post #8

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…

When did you ask? GPUs have been getting a lot faster year on year.

Though, I would like to see Xeon Knights Landing compared to GPUs for db uses.

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

#45

Post by felipe_aramburu »

j1vms wrote: post #30
VodkaHaze wrote: post #27

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?

We are not shipping all of the data as a whole to the gpu. We are going to be releasing some whitepapers that explain this in more detail but lets get a few things clear. Data is sent to the gpu compressed since it is compressed when it is stored. We can decompress VERY quickly on GPU's (30-50GB/s is easily achievable on a K80) and because each of our columns are compressed using one of our cascading compression algorithms (which everyone offers the best in terms of compression and throughput). We are a column store and only send over the columns that are being used in processing. So for example

select id, name, age, avg(income) from people group by gender

In this case only the income and gender columns would actually be sent to the gpu and they would do so in a compressed fashion to increase the "effective" bandwidth of data over PCIE. Even more interesting is that id, name, and age, would be pulled from our horizontal store instead of our compressed columnar store in order to minimize the number of iops necessary to fill the result set.

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

#46

Post by felipe_aramburu »

jhj wrote: post #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…

You bring up some really good points about badnwidth to the data and how many of our competitors have gotten ridiculously high benchmarks. We do NOT cache on the gpu, EVER. The reason why is because most of our columns are much too large to fit on one or even 8 gpus let alone the rest of the space required for processing on it.

which are why we actually prefer to have only 1 GPU per server when we are making our own boxes. We find that our most optimal running environment is when we have smaller instances with only 1 gpu. This is due to the fact that two smaller rigs with a gpu each will benefit from increased CPU RAM throughput (basically double 1 rig) and you have 2x the PCIE bandwidth since you are splitting it across two machines. While we don't have the enviable op / byte loaded that some machine learning tool sets might use we are able to greatly enhance these throughputs by using compression and doing things like running multiple arithmetic operations in one kernel call.

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

#47

Post by felipe_aramburu »

hendzen wrote: post #4

This has been tried many times. Unless you are doing a computation with sufficient arithmetic intensity [0] the cost of shipping the data over PCIe and back dominates any gain you might get over a CPU. [0] - http://www.nersc.gov/users/application-performance/measuring...

Seems kind of like a blanket statement to make if you have not investigated this for yourself. So let me give you some example use cases.

Decompression for processing: We can roundtrip decompress 8 byte integers RRleDeltaRle 4x on an AWS g2.2xlarge faster when we use the GPU. This includes sending the data TO the GPU and brining it back. Our decompression segments on CPU were set up so that every thread was processing a segment to be decompressed so we were using every avaiable thread at about 100%.

Sorting data: Here the difference can be startling. On an aws g2.2xlarge we are able to sort orders of magnitude faster than you can on GPU. Checkout thrust to run some exmaples http://docs.nvidia.com/cuda/thrust/#axzz4K7CRY352

A few modifications there can let you run this with both and NVIDIA backend and one that runs on CPU threads. It will run orders of magnitude faster on GPU than CPU on a small gpu instance on amazon. Even a laptop gpu would still outperform the cpu sorting capacity by at least an order of magnitude.

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

#48

Post by felipe_aramburu »

hendzen wrote: post #14
sitkack wrote: post #7

Earlier quoted context omitted.

You would need a GPU with an onboard SSD (exists). Or GPUs and drivers with the ability to talk directly to infiniband hardware (exists). Or the ability to not be ridiculously wasteful of existing resources (also exists). Your naysaying doesn't make you smart. Your naysaying makes you cut off from learning a different, better way of doing things.

Database workloads tend to be very branch heavy, e.g. string comparisons. If you've ever programmed a GPU you know that taking a data-dependent branch serializes the execution of the GPU stream processing units. So already the 70-100x benefit GPUs give on vectorized floating point workloads is greatly reduced. Add in the memory bandwidth penalty and it's a complete waste for IO intensive database workloads. Save the…

Yes data dependent branch serialzizes the execution of the gpu stream processing units (this is not true for amd actually). Yes it sucks operating on string sometimes on gpu and we don't always do it because of this. But we are ignoring certain aspects. Long strings are dictionary encoded in our database usually (no one picks this an optimizer finds the best cascading compression scheme and imposes this). Dictionary encodings are sorted so that each dicitionary value's key is in sorted order. So guess what you can already do comparison and equality checks on much smaller datasizes. A long string can be encoded in 8, 4 ,2 sometimes even 1 byte. Many times we have to do string comparisons on strings that we hhave not encoded ie

select * from table where column1 = "some awesome text here"

In this case we actually do a comparison between hashes of the data. Hashing is cheap, fast, and makes comparisons on the GPU's be a breeze. So long story short, we have no data dependent branching. We do this by never using certain statements inside of kernel code.

the use of "if" is expressly forbidden at blazing for any gpu code and it's use is punished viciously (said individual usually has to be the one that captures meaningful input from one the 80 log files of our 80 gpu cluster ).

Editing to mention the way you can encode a long string down to a 1 byte is by doing a dictionary compression and then bit packing the keys. On gpu the way you do this is getting the max key (min key is always 0) and then you can store this data in 1 byte (if max(key) < 255).

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

#49

Post by scottlocklin »

mcphage wrote: post #3
zitterbewegung wrote: post #2

It would be interesting to benchmark this against https://wiki.postgresql.org/wiki/PGStrom .

And MapD, too.

Got pals at MapD. I'd like to see any of them benchmarked against Kx. Pretty much all database problems are IO bound, and not many get it as right as Art did.

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

#50

Post by lmeyerov »

j1vms wrote: post #36
Johnny555 wrote: post #31

Earlier quoted context omitted.

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.

This is basically the bread and butter of columnar compute systems, not just GPU ones. GPUs ones just get to throw more compute at them, and thus do even better for these kinds of space/time trade-offs. Interestingly, most big data systems are increasingly columnar.
Post reply on HN