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

Alenka: GPU database engine

github.com

Post reply on HN
Print view View original

21–30 of 54 posts

Re: Alenka: GPU database engine

#21

Post by AlphaSite »

floatboth wrote: post #18
nrjdhsbsid wrote: post #12

I keep hearing the promise of GPU databases but they don't seem to be terribly useful for most real world workloads. It reminds me of the big hoopla for GPU h264 encoders. When they came out everyone realized the quality was worse and not much faster. Some things don't lend themselves to parallel processing, notably anything linear like transactions. I mean yeah the GPU can sort a hundred billion items a second but h…

> GPU h264 encoders Are there any GPU (shader) encoders? There are dedicated fixed-function hardware encoders (VCE and NVENC) on graphics cards, and they're very popular, because they're the best way to record game footage if you don't have dedicated capture hardware. You don't want x264/5 hogging the CPU when you're playing games!

CPU encoders are popular enough if you can afford a second box (for the improved quality).

Re: Alenka: GPU database engine

#22

Post by kalleboo »

nrjdhsbsid wrote: post #12

I keep hearing the promise of GPU databases but they don't seem to be terribly useful for most real world workloads. It reminds me of the big hoopla for GPU h264 encoders. When they came out everyone realized the quality was worse and not much faster. Some things don't lend themselves to parallel processing, notably anything linear like transactions. I mean yeah the GPU can sort a hundred billion items a second but h…

> they don't seem to be terribly useful for most real world workloads

It seems to me like there are mainly two kinds of cost-limited database workloads - complicated operations on datasets that fit in RAM, or simple operations on datasets that need to be distributed. For the former you're better off writing custom software, and for the latter you're I/O rather than CPU limited... Maybe SSDs or low-power-high-memory ARM servers could change that equation

Re: Alenka: GPU database engine

#23

Post by dijit »

zer0t3ch wrote: post #17
nrjdhsbsid wrote: post #12

I keep hearing the promise of GPU databases but they don't seem to be terribly useful for most real world workloads. It reminds me of the big hoopla for GPU h264 encoders. When they came out everyone realized the quality was worse and not much faster. Some things don't lend themselves to parallel processing, notably anything linear like transactions. I mean yeah the GPU can sort a hundred billion items a second but h…

> everyone realized the quality was worse and not much faster I can't speak for the h264 situation, as I wasn't involved at the time, but with the newer h265 hardware, it is obnoxiously faster with minimal (in terms of end-user, not distributor) quality loss.

Are those the CPU instructions or the GPU ones?

I remember when h264 CPU accelerators hit the scene. It was a game changer.

Re: Alenka: GPU database engine

#24

Post by Tuna-Fish »

floatboth wrote: post #18
nrjdhsbsid wrote: post #12

I keep hearing the promise of GPU databases but they don't seem to be terribly useful for most real world workloads. It reminds me of the big hoopla for GPU h264 encoders. When they came out everyone realized the quality was worse and not much faster. Some things don't lend themselves to parallel processing, notably anything linear like transactions. I mean yeah the GPU can sort a hundred billion items a second but h…

> GPU h264 encoders Are there any GPU (shader) encoders? There are dedicated fixed-function hardware encoders (VCE and NVENC) on graphics cards, and they're very popular, because they're the best way to record game footage if you don't have dedicated capture hardware. You don't want x264/5 hogging the CPU when you're playing games!

The fixed-function encoders are now less than half as good (that is, they require double the bitrate for same quality) as x264. Anyone who is serious about streaming gets a 8-core CPU or maybe a second computer to do the encoding.

Re: Alenka: GPU database engine

#25

Post by worldsayshi »

nrjdhsbsid wrote: post #12

I keep hearing the promise of GPU databases but they don't seem to be terribly useful for most real world workloads. It reminds me of the big hoopla for GPU h264 encoders. When they came out everyone realized the quality was worse and not much faster. Some things don't lend themselves to parallel processing, notably anything linear like transactions. I mean yeah the GPU can sort a hundred billion items a second but h…

It might that the optimal use cases for this kind of tech hasn't really materialized yet because the tech is not widely used?

Re: Alenka: GPU database engine

#26

Post by valarauca1 »

worldsayshi wrote: post #25
nrjdhsbsid wrote: post #12

I keep hearing the promise of GPU databases but they don't seem to be terribly useful for most real world workloads. It reminds me of the big hoopla for GPU h264 encoders. When they came out everyone realized the quality was worse and not much faster. Some things don't lend themselves to parallel processing, notably anything linear like transactions. I mean yeah the GPU can sort a hundred billion items a second but h…

It might that the optimal use cases for this kind of tech hasn't really materialized yet because the tech is not widely used?

There are several reasons

1. GPU RAM storage isn't as fine grained as CPU virtual memory. While GPU's have virtual memory they don't have the same degree of Copy On Write hardware utilities. This make rolling back snapshots and transactions within memory very difficult.

2. GPU's don't have dedicated non-volatile storage (well some do, but it is used more as a cache, and is treated as volatile). So for loading data you:

      SSD -> RAM -> CPU *copy* CPU -> RAM-> GPU
This isn't really a question of technological maturity it is more a question of PCIe doesn't allow an NVMe SSD to talk directly to a PCIe GPU. Nor do modern OS's have any model how to do this, nor do GPU's support file systems.

3. SQL based data querying is parallel friendly. At it's core SQL is 99% Filter/Map operations. The original goal of SQL was to be bottle necked by HDD access times so the vast majority of the query work is done in O(n). With a

      SSD -> RAM -> CPU *copy* CPU -> RAM-> GPU
You are already paying that O(n) load+process price at copy time (minus branches).

So the savings are only present if the data can persist on the GPU. Ultimately having multiple CPU threads to do the Map/Filter do the same job

There isn't just one problem:

1. GPU's don't support features to make holding data in RAM useful

2. PCIe doesn't support features to make loading data into the GPU fast.

3. The very design of SQL makes copying data into the GPU moot. Spreading a Map/Filter over 10-20 threads isn't rocket science.

Re: Alenka: GPU database engine

#27

Post by tmostak »

kalleboo wrote: post #22
nrjdhsbsid wrote: post #12

I keep hearing the promise of GPU databases but they don't seem to be terribly useful for most real world workloads. It reminds me of the big hoopla for GPU h264 encoders. When they came out everyone realized the quality was worse and not much faster. Some things don't lend themselves to parallel processing, notably anything linear like transactions. I mean yeah the GPU can sort a hundred billion items a second but h…

> they don't seem to be terribly useful for most real world workloads It seems to me like there are mainly two kinds of cost-limited database workloads - complicated operations on datasets that fit in RAM, or simple operations on datasets that need to be distributed. For the former you're better off writing custom software, and for the latter you're I/O rather than CPU limited... Maybe SSDs or low-power-high-memory A…

By your logic the entire in-memory CPU database space is wasted energy. I'm sure every analyst who wants to do some filters, group bys, joins and subqueries over a big dataset wants to write custom code (in C/C++ to be fast!), hoping their code will be as fast as a database optimized for such purposes, and then rewrite it all as soon as they need to tweak their query.

Re: Alenka: GPU database engine

#28

Post by tmostak »

nrjdhsbsid wrote: post #12

I keep hearing the promise of GPU databases but they don't seem to be terribly useful for most real world workloads. It reminds me of the big hoopla for GPU h264 encoders. When they came out everyone realized the quality was worse and not much faster. Some things don't lend themselves to parallel processing, notably anything linear like transactions. I mean yeah the GPU can sort a hundred billion items a second but h…

Not every database is a transactional database. The precise goal of databases like Redshift, Vertica, MemSQL, SAP HANA, Exasol and Impala are to be able to crunch multi-billion row datasets as fast as possible. Indexes often don't help with analytic queries as frequently good chunks of tables need to be scanned. You might apply a limit at the end of the query but that doesn't mean you don't need to scan billions of rows to get to the result that you are applying a limit to. There are many use cases for speed but the simplest one I can think of is powering Tableau/other BI products. If GPUs help make your dashboard refresh interactively instead of taking 30 seconds when filtering/exploring the data, and allow tens to hundreds of concurrent users on a system rather than just a few, that's a huge win for most of the Fortune 1000.

Data warehousing is a $30B/year business and it often boils down to a price/performance game. Any technology (including but not limited to GPUs) that can change the equation by at least an order-of-magnitude will be disruptive in that space.

Re: Alenka: GPU database engine

#29

Post by tmostak »

valarauca1 wrote: post #26
worldsayshi wrote: post #25

Earlier quoted context omitted.

It might that the optimal use cases for this kind of tech hasn't really materialized yet because the tech is not widely used?

There are several reasons 1. GPU RAM storage isn't as fine grained as CPU virtual memory. While GPU's have virtual memory they don't have the same degree of Copy On Write hardware utilities. This make rolling back snapshots and transactions within memory very difficult. 2. GPU's don't have dedicated non-volatile storage (well some do, but it is used more as a cache, and is treated as volatile). So for loading data yo…

Your first point is an implementation detail. Why couldn't CPU RAM be used as well in a GPU database system?

Re CPU vs GPU performance you are neglecting the fact that GPU RAM can be an order-of-magnitude faster than CPU RAM, not to mention the fact that complex queries can often become compute bound (geospatial queries are a prominent example).

Re: Alenka: GPU database engine

#30

Post by arnon »

nrjdhsbsid wrote: post #12

I keep hearing the promise of GPU databases but they don't seem to be terribly useful for most real world workloads. It reminds me of the big hoopla for GPU h264 encoders. When they came out everyone realized the quality was worse and not much faster. Some things don't lend themselves to parallel processing, notably anything linear like transactions. I mean yeah the GPU can sort a hundred billion items a second but h…

You're thinking about transactional databases, and you're right. Transactional databases will probably not benefit hugely from a GPU. That's not saying it's impossible, but probably not worth the effort.

However, there are so many types of databases around. Lambda architectures are all the rage now - you keep one database for your transactionals, and another for analytics. Analytics are huge, in the multi-billions of dollars every year and they've become one of the most important parts of steering a business and deciding on new strategy. Larger businesses don't just 'go for it' anymore, they analyze, and inspect, and dig deep into their historical data to find out if something is worth doing.

GPUs tend to lend themselves well to analytics, contrary to transactions. Specifically, columnar databases. When the columns are all of the same data type, and the data locality is high, GPUs perform /very/ well.

Regarding your sorting point you may not really want to sort everything, you got that bit right. But what if you want to perform a `JOIN` on a bunch of data?

It makes more sense to sort it first, because the JOIN would be much faster - matching keys would be much easier.

Now, if you were performing really fast SORT on a GPU, you're saving precious processing time.

Post reply on HN