Do GPU-optimized databases threaten Oracle, Splunk and Hadoop? | Hacker News Reader

Do GPU-optimized databases threaten Oracle, Splunk and Hadoop?

diginomica.com

95 pointstmostak60 comments

Leaving sarcastic comments aside, I think the valid point is made - the rise of commodity, garbage-quality hardware overmanufactured in China and subsequent rise of "commodity-proud" software empowered by penny-wise / dollar-stupid business processes are overdue for correction.

Instead of putting 20 rusty bicycles together and claim to be a revolutionary fuel- and cost efficient rocket ship, why don't we build a rocket ship from the beginning that actually flies quite well?

Hardware and chips optimized for DB engines, queries and huge amount of streaming data will be welcomed.

When/if the business cycle settles out (say Moore's law stops now and international affairs settle due to the emergence of a super being who imposes world peace) I would expect this kind of approach (rocket ship wins) to be prevalent about 10 years hence.

It makes great sense to me as a techie, my users will be happy. My staff will be happy. I will sleep at night. There will be no surprises, everything will just work. We will not have to explain that "the cluster just doesn't do that well when it's 90% full" or "it's been unstable since we lost that node a month ago, we think that the new capacity will let it get to a better state when we put that in" or "there's a network problem, we don't know why, somethings interacting with something else and long queries are getting killed".

However, my CFO will never give me the money to build a rocket ship. NEVER. I have looked into the eyes of his successor and all his acolytes and they will never give me the money either. To make this happen the current corporate hegemons of HR & Finance must be thwarted and destroyed. We must take their significant others, ride their quadrupedal beasts and burn their smartphones. Only when the laments of their personal digital assistants swirl in my ears like a Bach requiem will I take a case to the Operating Committee to do things right.

Until then it would be suicide.

GPUs are already getting slower, CPUs have been stagnant for a while (no 2x every few years), except if they just double the core count. I think in time specialized domain hardware will make financially sense because it will be the only way to grow.

GPUs are already getting slower

Do you mean the rate of change is slowing down, or that they're actually getting slower?

Based on Nvidia's Pascal launch I think you could argue that not only are GPUs getting faster but that the range of change just dramatically accelerated (due to a process node shrink and introduction of super-fast HBM2 memory).

Pascal already launched?

I'm not getting excited until Nvidia really ships something that keeps up with their promises. For the past few years, their products were underwhelming compared to marketing materials before launch.

Only in expensive compute boards. No GPUs yet.

Are cores really doubling every 2 years per unit of cost? Intel's chips seems to be getting more expensive with each new generation. Or they do stuff like calling Atom "Pentium", Avoton "Xeon-D", and make dual-core "Core i7", to trick you into buying lower-performance chips for the same price as the last, more powerful, generation (for the same price).

The per-core speed of a given CPU has been pretty stagnant for about 6 years... However, the number of cores (specifically in server hardware) continues to grow (slowly) and the CPUs themselves are using much less power per core than before.

There's more ways to improve than just faster cores.

CPUs have been stagnant for a while

Performance pr. core has been pretty stagnant, but performance pr watt has been improving. With the current consumer focus being so heavily on various battery powered 'computers', this seems like a reasonable trade off.

One reason the "rusty bicycle" approach has worked so well is because of economies of scale. If you look at mean time to failure on "commodity consumer" vs "enterprise grade" GPUs they're very close and price wise the consumer hardware is significantly less expensive on a flop/W/$ basis.

What are you even talking about? Hardware reliability has gone through the roof in recent years. So has performance in some areas, such as SSDs, GPUs, displays. The ability to run a medium-sized startup or a complex scientific simulation on commodity hardware is a fantastic force of democratization access.

DBs are CPU-limited and, yes, single-core performance has been stagnating. But that's unlikely to be a vast conspiracy.

Depends on the workload: Analytical DBs are often I/O limited.

Modern consumer SSDs are what, 2GB/sec, DDR4 is 60GB/sec. What kind of CPU can process data at these speeds?

Isn't the cache going to be in the 100GB/s range? Why would we even have a cache if memory speed wasn't a bottleneck.

That's not the point. Even trivial meaningful data manipulations are not possible at such speeds. Maybe on some 18-core Xeons, and even then I doubt it.

DBs are CPU-limited and, yes, single-core performance has been stagnating.

What are you basing this on? Database engines are only CPU-limited only if you have unlimited I/O bandwidth. Also, database engines hardly ever have only one query to process. Even if queries were not parallellizable (which they certainly are), single-core performance has little impact on overall performance.

>Hardware and chips optimized for DB engines, queries and huge amount of streaming data will be welcomed.

Oracle has been doing this for years. The only problem is the price.

>SQL in Silicon: Adds co-processors to all 32 cores of the SPARC M7 that offload and accelerate important data functions, dramatically improving efficiency and performance of database applications. Critical functions accelerated by these new co-processors include memory de-compression, memory scan, range scan, filtering, and join assist. Offloading these functions to co-processors greatly increases the efficiency of each CPU core, lowers memory utilization, and enables up to 10x better database query performance. Oracle Database 12c In-Memory option fully supports this new capability in the current release. In addition, this new functionality is slated to be available to advanced developers to build the next generation of big data analytics platforms.

https://www.oracle.com/corporate/pressrelease/sparc-m7-10261...

Because time and again that approach has demonstrated itself to be more expensive and less effective.

Computers are not bicycles. The differences are important: the rate of change of the whole ecosystem is much higher, the ways economies of scale play out are different, load-balancing approaches have no analogue in the physical world, refactoring is zillions of times cheaper than it is with physical objects. Intuitions from physical engineering are often simply wrong when applied to computing.

So, what about Google? A fleet of commodity hardware delivering rocket ships to everywhere.

Maybe you are not wrong for some smaller scale N, but after you need to make globally available datastores the speed of light is your enemy, not interconnect between two processors or some special NUMA configuration.

One can explain by analogy, but arguing by it is not productive.

Interestingly, it seems like GPU acceleration will be available in postgresql in one of the next few releases [0].

From that page it seems once enabled, there aren't any special requirements to get a GPU accelerating a query. As a result, I'd be surprised as a result if "GPU optimized" databases overtake regular-db-with-gpu-acceleration-addins.

[0] https://wiki.postgresql.org/wiki/PGStrom

Not all GPU databases are created equal. Notwithstanding the amazing functionality of Postgres and the impressive work of the PGStrom team, afaik they are still limited to a single GPU and do not cache data on board the GPU. It certainly makes Postgres much faster but is still likely one to two orders of magnitude slower than something like MapD that runs on up to 16 GPUs per server and caches hot data in GPU RAM.

Disclosure: I am the CEO of MapD.

I had not come across you guys yet -- thanks for sharing.

As an expert, how do you view FPGA vs GPU acceleration for databases ?

I'm not an expert on FPGAs, but in general they have much less memory bandwidth than GPUs. Since many queries are memory-bound, I would suspect that would make them less suitable than GPUs for generic SQL.

I'm interested in knowing what subset of SQL MapD supports. How does it handle expressions on strings and complex data types (tstamp zoned, dates?), etc.

It can do most of the basic expressions on strings (i.e. like/ilike) and can do the standard time operations (date_trunc, extract), with the goal of being fully SQL-92 compliant this year.

You have to remember that many of our customers use us with our visual analytics frontend - they don't care about what happens behind the scenes, just that they can interactively explore billions of records with near-zero lag.

I'm a huge fan of PostgreSQL and certainly if you need an ACID transactional database with the latest SQL support and extensions you can't go wrong. But if you need the fastest analytics performance there might be more-suitable platforms. Different tools for different jobs.

And how does it handle mutability, is it purely read-only, partial append support, full delete/update support?

Handles fast append (insert) - can stream large volumes of data in while running queries (one of the advantages of executing on GPU - you leave the CPU free to handle ingest).

Delete/Update in-flight.

> I'm a huge fan of PostgreSQL and certainly if you need an ACID transactional database with the latest SQL support

This answered my question. So now for the follow-up. Are they limited to one core because their goal is to be ACID? As much as people like to blame performance on the tenets of ACID, it's still pretty important for a great deal of things.

Queries are not limited to a single core anymore in the upcoming 9.6 release. There's a lot more that can be parallelized than what's in 9.6 though (sorting most importantly probably).

It doesn't threaten anybody because Oracle/Microsoft/Splunk/SAP/Hadoop/Spark/etc can just add in GPU-optimized code themselves.

Funny how it mentions USPS using GPUdb to "process complex queries and display 2D visualizations in the time it takes to load a Web page", yet every time I visit the post office, It takes at least 8 seconds after scanning a prepaid package for the package details to appear on the screen. They need to port that tech over to where it matters

If they can do all that, how about adding it to their tracking number system so I can see where my package is and an estimate of what time it will arrive?

Probably because FrontEndLayer needs to talk to LegacyLayer1 who talks to LegacyLayer2...

I found out that, at least here in Europe, package delivery companies let their software be developed per country/department. There is no central IT department. Some departments are super high tech, while others are doing the exact same task.. but then with a twenty years old system.

You're just reading it wrong. They use it to "process complex queries and display 2D visualizations in 8 seconds".

GPU databases are around for a while, but not much has changed.

I think bigger thread is cheap memory and raise of in-memory computing. Today you can have a workstation with half TB RAM for fairly reasonable price. Hadoop is already being crushed by Spark.

Hadoop is not map reduce, repeat Hadoop is not map reduce.

Also Spark is not a solution, it is an engine.

We run Spark on HDFS using all the paraphernalia of Hadoop to maintain some sort of sanity around it, how do you manage access? Encryption? Scheduling?

I think we can agree that many users are migrating away from batch processing.

the point overlooked in this article is how much costlier vram is compared to ram. to store same amount of data in vram as ram would cost you an order of magnitude more. not to mention dbs like mapd are not distributed, so you are limited to the amount of gpus you can cram in a single box

I don't think they really threaten Oracle, even for analytics where this makes sense. The performance increase over in memory on sparc m7 per price point won't be that insane. So just like in memory db the main question is how long before Oracle accelerates it's own DB with this kind of tech. I think they have only 3 years before Oracle will be there.

The challenge for Oracle is not how to do it, but how to make it pay. The price point for a TB class homebrew gpu solution is ~$30k. Oracle implementations used to be in the $500k range. This is why Oracle must move to the cloud and take customers with it.

Oracles problem, customers who are keen on the cloud may well go to GCE, MS or AWS. Customers who are not so keen seek to save the money with open source and commodity implementations.

If you are sitting on a huge installed base the very last thing you want to see is disruptive technology shaking out your customer base. Oracle has seen three waves in five years - Hadoop, Cloud and now GPU/SCM. It's a tribute to the software and strategy of Oracle that they aren't bleeding rivers of red ink.

If the 2000s didn't kill Oracle what will?

In the case of Hadoop, it might be possible to transparently translate the scripts to a GPU backend.

Yep, multiple Spark->GPU projects already happening.

AFAIK GPUs only excel at data-parallel tasks (i.e. doing the exact same operation to thousands of data points in parallel, like in a matrix multiplication e.g.). So I wonder how they utilize this for ad hoc SQL queries? Anybody have any pointers to some papers maybe?

SQL is somewhat parallel. All row-level computations are independent and a WHERE maps nicely to a reduce(). I'm not sure if these aren't limited by I/O, though.

Here's a recent article by NVIDIA on using GPUs for graph computation which is somewhat related: https://devblogs.nvidia.com/parallelforall/gpus-graph-predic...

I think it will be highly dependent on how you structure your queries. Some will be absolutely I/O limited while others will be barely faster than on the CPU. Piping the data out to the GPU is definitely going to be an issue too unless your database is small enough to fit in GPU memory (in which case the whole approach is probably overkill anyway).

Oracle already sells A LOT of Exadata; premium priced machines to run databases on overdrive. I think they would be fine competing against a GPU-optimized database.

Open source gpu databases are just presales support.

Maybe a good time to point out we've been specializing more on the visual analytics side (mentioned companies are more like DBs or traditional Tableau) by connecting GPUs in the browser to GPUs in the datacenter: graphistry.com . And, we're hiring ;-)

LOL. Someone sold USPS a solution to the traveling salesman problem.

Getting a solution is easy. The slow part is ensuring you've found the best one.

It is a very lucrative sector

http://www.paragontruckrouting.com/

It's funny to think of all the money and effort spent compared against the savings (in money, energy, and time) you can put in place by simply telling delivery drivers to not make left turns and putting a reasonably intelligent dispatcher in place.

Paragon does multiple drivers / vehicle / load splitting etc.

Even more lucrative (per client) when you apply it to "which tail numbers should fly which routes" for an airline.

"Any headline that ends in a question mark can be answered by the word no."

http://enwp.org/Betteridge's_law_of_headlines

Because we've all had enough of buzzfeed: the article doesn't even come close to bothering to actually answer the question. Decide for yourself whether that makes it link bait or not.

Reply on news.ycombinator.com