BlazingDB uses GPUs to manipulate huge databases in no time • Hacker News Board

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

#71

Post by n00b101 » Wed, Sep 14, 2016, 1:22 AM UTC

optimiz3 wrote: post #38

n00b101 wrote: post #13

Earlier quoted context omitted.

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 secondar…

That's very interesting. Have you collected statistical data on these bit errors? Is it always a single bit error?

I'm assuming you are using GeForce cards and not Tesla cards which have an ECC memory protection mode?

I've tried to collect some statistics on GPU memory errors rates but have found them to be normally extremely rare. The only time I've reproducibly seen them is due to faulty hardware, where the errors become highly reproducible and the GPU needs replacement. The other theoretical cause of bit flips is supposed to be random errors due to cosmic radiation but I've never been able to observe that using memory testing software (though I did only run the experiments in AWS).

Could it be that you have faulty or low grade GPUs? I assume these are all low-cost OEM parts, given your application? Or maybe there's something odd about your data center environment?

Regarding the GPU database application, I think the answer is to just use the Tesla grade GPU with ECC memory enabled.

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

#72

Post by optimiz3 » Wed, Sep 14, 2016, 4:45 AM UTC

n00b101 wrote: post #71

optimiz3 wrote: post #38

Earlier quoted context omitted.

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 secondar…

That's very interesting. Have you collected statistical data on these bit errors? Is it always a single bit error? I'm assuming you are using GeForce cards and not Tesla cards which have an ECC memory protection mode? I've tried to collect some statistics on GPU memory errors rates but have found them to be normally extremely rare. The only time I've reproducibly seen them is due to faulty hardware, where the errors…

Generally we prefer AMD cards as most (profitable) mining functions are memory bandwidth dominated. Usually it's a shader unit that gets unstable in the 70-80C range (note that most silicon is rated for higher ranges).

AMD's hardware specifications are more open too which lets one build your own shader compilers and get direct access to the iron.

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

#73

Post by sitkack » Wed, Sep 14, 2016, 2:30 PM UTC

felipe_aramburu wrote: post #48

hendzen wrote: post #14

Earlier quoted context omitted.

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…

The whole point of making things fast is to remove all the if statements. People complain that their current if-heavy algorithm can't run on GPUs therefor GPUs suck. Of course then the algorithms need to be reworked to have less branches.

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

#74

Post by brianwawok » Wed, Sep 14, 2016, 2:43 PM UTC

felipe_aramburu wrote: post #65

brianwawok wrote: post #9

Earlier quoted context omitted.

Seems like a smarter response to me. Go ahead and use a GPU database if you want?? I have yet to see a good use case of one though.

We have seen many. Big joins are our best use case. Joins are hard for many databases to optimize when they have not seen them before or are not "expecting" them like when you let amazon know how to partition your different tables onto the same physical machines so that redshift can return your query in a reasonble amount of time. But most SQL operations can be accelerated by the use of GPU's. Order by (holy smokes i…

This seems more like an analytics workload.. you are querying a bunch of things you can't index ahead of time.

Why not put GPUs on your analytics machines? Or a cluster of them with SPARK. Or heck, distribute the spark cluster on top of your database.

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

#75

Post by felipe_aramburu » Wed, Sep 14, 2016, 3:18 PM UTC

brianwawok wrote: post #74

felipe_aramburu wrote: post #65

Earlier quoted context omitted.

We have seen many. Big joins are our best use case. Joins are hard for many databases to optimize when they have not seen them before or are not "expecting" them like when you let amazon know how to partition your different tables onto the same physical machines so that redshift can return your query in a reasonble amount of time. But most SQL operations can be accelerated by the use of GPU's. Order by (holy smokes i…

This seems more like an analytics workload.. you are querying a bunch of things you can't index ahead of time. Why not put GPUs on your analytics machines? Or a cluster of them with SPARK. Or heck, distribute the spark cluster on top of your database.

We are an Analytical database not a transactional one. We would love to integrate with more tools like spark alas we are a small team of 5 working on the engine and making the engine itself has taken most of our time to date.

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

#76

Post by zlynx » Wed, Sep 14, 2016, 7:32 PM UTC

hendzen wrote: post #28

zlynx wrote: post #26

Earlier quoted context omitted.

You can write code to compare strings without branches. Imagine comparing one string to every string in a database column. Pad to a fixed size first (if you find an ambiguous match later you can do a full string compare then). Subtract the strings, aka compare, and store the result. At the end of all the commparisons you have a memory structure of negative, zero, or positive values. Then you can do something with the…

That sounds like an interesting technique - but it unfortunately does not apply on a majority of real-world data. In particular I mean sorting non-English text which any serious database needs to be able to do. Subtracting characters doesn't work when you're dealing language specific Unicode collation [0]. [0] - http://www.unicode.org/reports/tr10/

Yeah, well, you just can't do it that way and be fast at the same time. I mean seriously fast.

What you can do is decide how your comparison should be collated and preprocess your strings into a sort key form that is strictly big-endian binary (first byte has highest weight). Or little-endian I suppose, whichever works best for your hardware.

Your sort key doesn't have to be the actual string.