Follow Slashdot stories on Twitter


Forgot your password?

Why Don't Open Source Databases Use GPUs? 241

An anonymous reader writes "A recent paper from Georgia Tech (abstract, paper itself) describes a system than can run the complete TPC-H benchmark suite on an NVIDIA Titan card, at a 7x speedup over a commercial database running on a 32-core Amazon EC2 node, and a 68x speedup over a single core Xeon. A previous story described an MIT project that achieved similar speedups. There has been a steady trickle of work on GPU-accelerated database systems for several years, but it doesn't seem like any code has made it into Open Source databases like MonetDB, MySQL, CouchDB, etc. Why not? Many queries that I write are simpler than TPC-H, so what's holding them back?"
This discussion has been archived. No new comments can be posted.

Why Don't Open Source Databases Use GPUs?

Comments Filter:
  • by Anonymous Coward on Wednesday December 25, 2013 @11:10AM (#45781889)

    ...because I/O is the limiting factor of database performance, not compute power?

    • by Arker ( 91948 ) on Wednesday December 25, 2013 @11:29AM (#45781975) Homepage

      Wow, a fp that hit the nail on the head.

      Indeed, database applications tend to bottleneck on I/O, not processor, so most uses would see little gain from this. That's probably the biggest reason no one has bothered to do it.

      Certain uses would probably benefit, but then there are other reasons too. You run databases on machines built for it, not gaming machines, so it's not like they already have this hardware. You would have to buy it and add it as an expense. And GPUs are error prone. Not what you want in most database applications either (although again, there may be niches where this would be ok.)

      • by Runaway1956 ( 1322357 ) on Wednesday December 25, 2013 @11:40AM (#45782005) Homepage Journal

        I'll add that most people who put up the cash for high performing GPU's aren't much interested in actually "computing" with them. They are far more interested in "gaming". They demand video performance, as opposed to crunching database numbers. Those companies that are most likely to pay people for manipulating data bases generally have little interest in top notch video, so they aren't going to pay for hundreds of GPU's.

        • by houstonbofh ( 602064 ) on Wednesday December 25, 2013 @11:53AM (#45782065)

          ... so they aren't going to pay for hundreds of GPU's.

          Especially when they have already blown the budget on fast SSDs that actually make a real difference in real performance, not just synthetic benchmarks.

          • by girlintraining ( 1395911 ) on Wednesday December 25, 2013 @02:08PM (#45782617)

            Especially when they have already blown the budget on fast SSDs that actually make a real difference in real performance, not just synthetic benchmarks.

            Is now a bad time to point out that many researchers have built clusters based out of thousands of GPUs to model the weather, protein folding, and other things? As it turns out, gamers aren't the only ones that buy GPUs. And GPUs aren't functionally all that different from FPGAs, which as I understand Linus went off to Transmeta to build CPUs based off such architecture.

            I'm irritated whenever people here on slashdot can't see past their own personal experience; it's become quite sad. The true innovators don't see something that's already been done and figure out how to do it better. They see the same things as everyone else, but put them together in radically new ways nobody's ever thought of before.

            GPUs for database processing? That's crazy! Which is why it's innovative and will push the limits of informational technology. three hundred quintillion polygasmic retina displays with 99 billion pixels to play Call of Duty 27 will never do that. Most slashdotters that put down an idea like this really have no concept of what geeks and hackers do.

            We push the limits. We fuck with things that ought not to be fucked with. We take the OSI 7 layer model, set it on fire, turn it inside out, and hack out new ways to do do it by breaking every rule we can find. We go where we aren't wanted, aren't expected, and we push every button we can find. We do things precisely because people tell us it's impossible, that it can't or shouldn't be done, and take great pleasure in finding novel new ways to do something even if there's already twenty proven ways to do it.

            And while probably 99 times out of a 100, the experience matters only for the hacker or geek doing it, and is done merely to learn... that glorious one time when something unexpected and interesting happens, that is what all progress on this industry is based on. And people like you who belch about "synthetic benchmarks" and insist nobody would do X because that's just stupid will never understand.

            • by znrt ( 2424692 ) on Wednesday December 25, 2013 @03:22PM (#45783029)

              that's all nice and good. but what has that to do with "Why Don't Open Source Databases Use GPUs?". because GPUs do provide little benefit to nowadays DBs! why aren't diamond shaped networks of bread toasters used for open source databases? it's just a stupid question, has nothing to do with "innovation being misunderstood". there's nothing to understand here besides the fact that someone apparently was in need to fill his news-roll with random bullshit.

            • You're answering the wrong question.

              The question is Why don't Open Source Databases use the GPU. There are many answers: Supply and Demand is the best one. The other is that collating database rows in a GPU is fine, but you still have the damn bottleneck getting the data out to main system RAM. So, if your use case is a server then you're fucked because GPUs don't have a NIC interface.

              The true answer is: We don't run databases in the GPU because GPUs are stupidly dedicated designs. General Purpose Comp

            • by LWATCDR ( 28044 )

              Slightly off topic but how about using GPUs for RAIDs?

              • A standard CPU is better, and you are not limited to dedicated (and occasionally had to find) hardware. Look for threads about ZFS or mraid over hardware raid for a lot of discussion on this.
            • I get your point but mostly due to the fact that I've been a heretic for the last forty-four years. The funny part is, what I was doing then is what everyone else is doing now, just twenty or so years later. The difference being, in one case, having to forklift my big data into the data center. It keeps me amused.
        • by ron_ivi ( 607351 ) <<sdotno> <at> <>> on Wednesday December 25, 2013 @01:00PM (#45782339)

          performance ... put up cash...

          The biggest opportunity for GPUs in Databases isn't for "performance". As others pointed out - for performance it's easier to just throw money at the problem.

          GPU powered databases do show promise for performance/Watt.


          However, energy efficiency is not enough, energy proportionality is needed. The objective of this work is to create an entire platform that allows execution of GPU operators in an energy proportional DBMS, WattBD, and also a GPU Sort operator to prove that this new platform works. A different approach to integrate the GPU into the database has been used. Existing solutions to this problem aims to optimize specific areas of the DBMS, or provides extensions to the SQL language to specify GPU operation, thus, lacking flexibility to optimize all database operations, or provide transparency of the GPU execution to the user. This framework differs from existing strategies manipulating the creation and insertion of GPU operators directly into the query plan tree, allowing a more flexible and transparent framework to integrate new GPU-enabled operators. Results show that it was possible to easily develop a GPU sort operator with this framework. We believe that this framework will allow a new approach to integrate GPUs into existing databases, and therefore achieve more energy efficient DBMS.

          Also note that you can write PostgreSQL stored procedures in OpenCL - which may be useful if you're doing something CPU intensive like storing images in a database and doing OCR or facial recognition on them: []

          Introducing PgOpenCL - A New PostgreSQL Procedural Language Unlocking the Power of the GPU

        • by BLKMGK ( 34057 )

          Actually as one of those "gamers" I'd love to be using my GPU to speedup real world things like x.264 and ffmpeg but sadly GPU isn't being used there and seems to be actively scorned. A real bummer as I'd love to be putting this bad boy to more use in things I do that tax my heavily overclocked CPU.

          GPU crunch numbers well, look at the differences made in password cracking for instance. In the right situation the GPU isn't used for video at all.
          I know several people who have invested serious cash in GPU that

      • Well, gaming machines do make great servers. What is a gaming machine? Fast CPU, lots of memory, fast storage. The only difference is the video card. For home built servers in PC cases, I just don't bother with the pesky high end video cards. They run so much cooler and quieter. I'd hate to have a rack of servers at the house. I rather not have a jet engine running in the next room. :)

      • Curious why do you think GPUs are error prone?

    • Not true (Score:5, Insightful)

      by kervin ( 64171 ) on Wednesday December 25, 2013 @12:07PM (#45782127) Homepage

      ...because I/O is the limiting factor of database performance, not compute power?

      Just a few projects into Database Performance Optimization would convince you that's not a true statement. IO/Memory/CPU are in fact largely interchangeable resources on a database. And depending on your schema you can just as easily run out of any of these resources equally.

      For instance, I'm currently tuning a SQL Server database that's CPU heavy based on our load projection targets. We could tweak/increase query caching that would cause more resultsets to stay in memory. This would mean that less complex queries would be run, drastically reducing I/O and some CPU resource usage. But then drastically increasing memory usage. This is just a simple example of course to illustrate the point.

      Databases run out of CPU resources all the time. And a CPU advancement would be very well received.

      My guess as to why this hasn't been done is that it would require end-users to start buying/renting/leasing GPU enabled hardware for their Database infrastructure. This would be a huge change from how we do things today and this sector moves very slowly.

      Also we have many fairly old but more important Database advancements which have been around for years and are still almost unusable. If you ever tried to horizontally scale most popular Open-source databases you may know what I'm talking about. Multi-master, or just scaling technology in general, is required by about every growing "IT-dependent" company at some point. But that technology ( though available ) is still "in the dark ages" as far as I'm concerned based on reliability and performance measurements.

      • by Bengie ( 1121981 )
        Rule of thumb, if your dataset can fit in memory, it probably won't benefit from GPUs. Talking about 10TB+ datasets and few long running Data Warehouse style queries, not small OLTP style queries. GPUs take a crap if you have any branching, so all queries used must not have any conditions that can cause different rows to take different branches to be useful, so very basic WHERE statements.
      • Indeed. We have a large WordPress based site and it is bound by database CPU despite the fairly powerful CPU it uses. It should scale to many cores, so I'm thinking of trying a pair of the 8 core AMD processors. Intel is faster PER CORE, but an AMD rig could have 16 cores.

    • Very good point, entirely correct. However... for an in-memory database I wonder if there's gains to be had? I'm not sure CPU-memory I/O is much of a bottleneck, though such DBs aren't suitable to every task of course.

      • Even with in-memory databases, most of the stuff are simple computations with a large amount of data with often random access. GPUs like a lot of computation with streaming data. Also: data copying, virtual memory support. But perhaps Kaveri and its successors will be more useful for that.
    • by CODiNE ( 27417 )

      In other words... For databases that fit in memory GPU makes a lot of sense. For really large data sets the limit is how fast you can get the data off the hard disk.

      But what "io bottleneck" people may be missing is that an io bound server could still benefit from this if the freed up CPU time can be used for other things when it's not shuttling data to and from the GPU. It also could end up saving a lot of energy, and that's money.

      • Except that GPUs are bad for most of the tasks a database do. Normaly, databases require random memory access (not mapping arrays) and complex selection rules. GPUs are best doing maps over continuous arrays, and with very simple (best if none) conditional cases.

      • by Bengie ( 1121981 )

        For databases that fit in memory GPU makes a lot of sense.

        A bit more selective that that. For datasets that fit in memory, where memory patterns are sequential, and the queries have almost no branching. GPUs are very picky.

    • by fatphil ( 181876 ) on Wednesday December 25, 2013 @01:25PM (#45782433) Homepage
      Read the paper - page 7 (which bizarrely doesn't render clearly for me at all, and I can't copy/paste)
      "Scale Factor 1 (SF 1) ... data fits in GPU memory"

      They ran the TPC-H ("H"="Huge") with a dataset that was ABSOLUTELY FUCKING TINY.

      No, I'm not shouting at you, I'm shouting at the fucking bogus pseudo-academics who wanted to bullshit with micro-optimisation rather than making actual advancements in the field of databases.

      • by TheRaven64 ( 641858 ) on Wednesday December 25, 2013 @02:51PM (#45782849) Journal

        No, I'm not shouting at you, I'm shouting at the fucking bogus pseudo-academics who wanted to bullshit with micro-optimisation rather than making actual advancements in the field of databases.

        Any paper that does X on a GPU generally fits into this category. It's not science to run an existing algorithm on an existing Turing-complete processor. At most it's engineering. But it's a fairly easy way to churn out papers. Doing X 'in the cloud' or 'with big data' have a similar strategy. It's usually safe to ignore them.

      • by ddt ( 14627 )

        Nice catch, Fatphil!

        Also, writing, debugging, and maintaining GPU code is a lot less fun than CPU code. Much open source GPU code do you know of that is still in use after 5 years?

        • by fatphil ( 181876 )
          Someone else spotted this before me, it appears; I replied to him below, something-dad or something-lad.

          One of the problems is that things are just a little bit too new to be tested for longevity. Fragmented architectures plus chipset vendors pushing separate languages didn't help.

          To be honest, with modern GPUs, I believe that I was born too early. I was massively getting into optimisation 90s to early 00s. I'm tired of dicking about with all that kind of stuff now. And the kids these days have got it way t
    • by gweihir ( 88907 )

      Bah, pesky facts! Don't you know that the latest buzzwords have to be accepted unquestioningly to be truly hip (and utterly incompetent)?

  • by AHuxley ( 892839 ) on Wednesday December 25, 2013 @11:10AM (#45781891) Journal
    The people with the skills have day jobs and want to enjoy time off with other projects.
    The people with the skills have no jobs and want to write the code but the hardware is too expensive.
  • by Maury Markowitz ( 452832 ) on Wednesday December 25, 2013 @11:12AM (#45781907) Homepage

    The R&D effort in the SQL field is roughly zero, so it's not surprising people aren't keeping up with the latest developments in the hardware field.

    It's bad enough that the only standardized access system is ODBC, designed 25 years ago when pipes were short and thin and a WAN was the next building over. If we can't get that problem fixed, what's the hope for integrating new technologies?

    • Re: (Score:2, Informative)

      by Anonymous Coward

      The R&D effort in the SQL field is roughly zero, so it's not surprising people aren't keeping up with the latest developments in the hardware field.

      Except for the part where errybody's keeping up with the latest developments. They're just actually looking at developments that matter. GPUs... Do not matter. If you want to know more, check the first post.

      Processing power is inconsequential compared to I/O. RAM is pretty straightforward; newer, faster RAM comes out, larger amounts become cheaper, you buy it, you throw it into the mix.

      The cool stuff is happening around SSDs (which are also pretty straight forward), solid state memory devices (think

    • Run a big query on your database. Now, while the hard drive light is solid red, look at your CPU load. See how it is not using all the CPU because it is waiting on the hard drive? A GPU will not help that.
  • by FaxeTheCat ( 1394763 ) on Wednesday December 25, 2013 @11:12AM (#45781909)

    so what's holding them back?

    Wrong question. It is open source. If you need it, you fix it.

    • so what's holding them back?

      Wrong question. It is open source. If you need it, you fix it.

      No, it is the right question. And the answer is, the people that actually understand these things work also know this will not help anything in real world applications. They are also busy optimizing for additional cheap ram, and the new and fast SSD cards that are almost affordable.

  • Risk aversion. (Score:2, Interesting)

    by Anonymous Coward
    Because a lot of us have personal experience on how "reliable" GPU calculations are.

    A few screen "artifacts" tend to be less painful than db "artifacts". Maybe things have changed. But it's not been that long since nvidia had a huge batch of video cards that were dying in all sorts of ways.

    As for AMD/ATI, I suspect you'd normally use some of their crappy software when doing that GPU processing.
  • by vadim_t ( 324782 ) on Wednesday December 25, 2013 @11:15AM (#45781927) Homepage

    "Many queries that I write are simpler than TPC-H, so what's holding them back?" -- simple queries don't need acceleration.

    A "SELECT * FROM users WHERE user_id = 12", or a "SELECT SUM(price) FROM products" doesn't need a GPU, it's IO bound and would benefit much more from having plenty cache memory, and a SSD. A lot of what things like MySQL get used for is forums and similar, where queries are simple. The current tendency seems to be to use the database as an object store, which results in a lack of gnarly queries that could be optimized.

    I do think such features will eventually make it in, but this isn't going to benefit uses like forums much.

    • by tranquilidad ( 1994300 ) on Wednesday December 25, 2013 @11:37AM (#45781997)


      If you go beyond the abstract and read the paper you'll notice that they chose a TPC-H scale factor of 1 (1 GB of data) so that the entire dataset would fit in the GPU.

      The question they seem to really be asking is more akin to, "Why don't we make our datasets small enough for complex queries that it can all fit in the storage attached to a processor we like?"

      They continue to answer their own question when discussing results and admit they can't compare costs of "traditional" implementations because those tests were all run with scale of 100 (100 GB of data).

      They say the comparison is difficult against complete systems because of the scaling factor and "...this paper is about the effectiveness of mapping relational queries to utilize the compute throughput [of] GPUs".

      So, it seems to boil down to a test of compute power on data sets small enough to fit in memory rather than an effective test of relational query processing, though they did use relational queries as their base testing model.

      • So, it seems to boil down to a test of compute power on data sets small enough to fit in memory rather than an effective test of relational query processing, though they did use relational queries as their base testing model.

        Or... Just because you can do something, doesn't mean you should.

      • by fatphil ( 181876 )

        "They say the comparison is difficult against complete systems because of the scaling factor[...]"

        The TPC go a little bit further:
        Note 1: The TPC believes that comparisons of TPC-H results measured against different database sizes are misleading and discourages such comparisons. The TPC-H results shown below are grouped by database size to emphasize that only results within each group are comparable.

        Their toy is simply irrelevant in the field of real world databases.
    • Select * from orders order by amount For huge sorting queries gpu destroys cpu.
  • They're coming... (Score:4, Informative)

    by Heretic2 ( 117767 ) on Wednesday December 25, 2013 @11:26AM (#45781965)
  • Many queries that you write are simpler than TPC-H. Necessity is the mother of invention.
  • Why not? (Score:4, Funny)

    by Black Parrot ( 19622 ) on Wednesday December 25, 2013 @11:49AM (#45782043)

    It's waiting for you to get on it.

  • What's holding them back? I'd have thought it was obvious!

    The big issue with GPGPU for DB work is that you have to have the DB entirely in memory or your performance will suck (even SSDs aren't that fast). To get a big database to work in such a scenario, you have to split it into many smaller pieces, but that makes working with these sorts of things expensive even with an open source DB. The paper even says this. That makes this sort of work only really interesting for people with significant budgets, and

  • All of these SGBDs are actually toys being sold for more then they are capable of. So developers there have to try to catch up to PostgreSQL before it becomes (even) easier to use and eat their lunch.

    Meanwhile, the issues meriting scarce development and, mainly, review time at PostgreSQL are more interesting than accelerating a few workloads in hardware which is not yet in the servers out there. Things like making PostgreSQL even easier to install, set-up and manage, even more ISO SQL compliant, even more

  • It depends (Score:5, Funny)

    by Waffle Iron ( 339739 ) on Wednesday December 25, 2013 @12:01PM (#45782109)

    Research shows that there is good news and bad news on this approach.

    The good news: Certain SQL queries can get a massive speedup by using a GPU.

    The bad news: Only a small subset of queries got any benefit. They generally looked like this:

    SELECT pixels FROM characters JOIN polygons JOIN textures
    ON characters.character_id = polygons.character_id
    WHERE = 'orc-wielding-mace' AND = 'heavy-leather-armor' AND color_theme = 'green'
    ORDER BY y, x

    • Re: (Score:2, Funny)

      by Anonymous Coward

      ORDER BY z ... sorry

  • I'm responsible for a large university learning management system (Sakai). The daabase is completely CPU limited. I assume that's because the working set of data fits in memory. I would think lots of university and enterprise applications would be similar. Another data point is the experiments done on a no-SQL interface to innodb. That shows very large speedups. Surely some of this is due to the CPU overhead in processing SQL.
    • I assume that's because the working set of data fits in memory.

      As memory access count as CPU time, not I/O, doing any query in a dataset that is in memory will be CPU bound. But that does not mean that you'll get improvements by adding CPU speed.

    • by Arker ( 91948 )

      As the other poster pointed out, given that your set fits in memory, it's going to appear to be CPU bound. It still probably is not, however. Memory access is still likely to be the actual bottleneck.

  • Besides datasets not fitting in to GPGPU memory, and I/O bottlenecks, I'm still seeing plenty of badly written SQL

    A current contract has plenty of SQL work (not for me though), and the bulk of their time is cleaning up data exceptions, badly written report queries, and moving oft-used or large-dataset queries to stored procedures. GPGPU's will hide some of the rot, but if the SQL was written better in the first place, we're able to use parallelism and better use existing commodity hardware in clients virtua

    • This might be a stupid question as I'm not a DB expert, but isn't the problem of badly-written SQL something that could be mitigated by improvements in the SQL parser of a RDMBS? Other programming language compilers are frequently designed to optimize output code despite non-optimal constructs written by programmers. It seems to me that some of the improvements you talk of could be automated, especially moving oft-used queries to stored procedures.

      • I honestly don't know of any decent AQL optimisers...

        I know MS SQL Management Studio has SQL Profiler, Index Tuning Advisor, and Database Performance Tuning Advisor.
        But there's nothing in Aqua Data Studio that works with PostgreSQL, which means co-workers and I must rely on good looks and mad skillz (I'm only passable on both)

      • by Bengie ( 1121981 )
        When your queries start getting into the 10 table joins, the join optimizer starts to attempt to make educated guesses because of the number of possible join arrangements. The metadata used is based on samples of the current data. To mitigate having to keep these metadata perfectly up to date, which would be very expensive and slow, the RDMBS only samples a subset.

        While this works most of the time, there are some cases that don't. I've had quite a few times where I had to force join orders and/or join ty
        • See, (again I'm speaking from a position of relative ignorance here) it seems like the RDMBS should be intelligent enough to figure this stuff out automatically, instead of requiring an in-house expert. It should be adaptive and learn from the current usage patterns, in relation to the data it stores. So if, for instance, breaking the query up and using temp tables speeds things up, the DB should figure this out and do it automatically. It wouldn't work for one-time queries, but if the same kind of queri

          • by Bengie ( 1121981 )
            Many of these optimizations that are done "manually" can be done because I know certain things that the RDMBS does not know about the usage case. It can guess about things and use current meta data, but those guesses are not always correct.

            Lets make an example. Say table A is a small table with a relation to table B, and table B is several magnitudes larger than A. Now say table B has a relation to table C, but table C is only a few factors larger than B.

            Lets assume there is also a reverse, where tabl
  • by slackergod ( 37906 ) on Wednesday December 25, 2013 @01:05PM (#45782355) Homepage Journal

    Looks like exactly what PostgreSQL's PGStrom [] project is trying to acheive.

  • it doesn't seem like any code has made it into Open Source databases like MonetDB, MySQL, CouchDB, etc.

    Lemme guess, MySQL fanatic?

    You can already go download: []

    if it fits your problem domain and PostGIS has some hackers adding GPU support: []

    Why not the others? Perhaps because PostgreSQL makes developing extensions easier - it's got the largest extensio

  • by loufoque ( 1400831 ) on Wednesday December 25, 2013 @02:29PM (#45782749)

    A GPU, even a GTX Titan, simply isn't 7 times faster than a modern 32-core x86 CPU in real life. Most of the gain probably comes from just general optimization that could have been done on the CPU too.

  • Gee, a $1000 GPU that runs 7x as fast a 1/8th of an $1500 CPU. It woud be good idea if you didn't need that CPU to run it, but just barely so. If you cheap out on the CPU and only spend ~$750 on it, assuminng there is no slowdown on the GPU because of it, then the economics break. And people wonder why GPU compute on databases isn't catching on.

    Then there is the power use aka TCO/running costs to think about. And everything mentioned above. And.... This study has all he hallmarks of an Nvidia research project who's targets are financial analysts rather than potential customers. The science is fine but that is not the intent.


  • This is clearly the question that corporate co-authors Nvidia and Logicblox hoped you would ask.

    The paper seems to represent more of an evolutionary rather than revolutionary approach, but suffers from some unfortunate hand-waving, particularly in their attempt to negate the real cost of memory->PCIe transfers (to their credit, at least they call out that latency), their unwillingness to perform comparisons on like-to-like base hardware, and their rather odd choice of front-end environment. Coupled with
  • Typical reponses above:
    (a) DB operations aren't CPU intensive
    (b) Servers don't come with dedicated graphics cards of any note
    (c) Loading each server with a AMD or Nvidia card would increase power usage

    So in summary, certain operations may benefit using GPUs but there's not a cost-effective solution to warrant such experimentation.

    I'd be surprised ARM if haven't sponsored cloud research into OpenCL on the Mali GPUs.

Neutrinos have bad breadth.