MapD is the company blog of a GPU-accelerated SQL database for analytics and visualization of very large datasets.
HN commenters link it as an example of GPU databases, including its use of LLVM to compile SQL queries to CPU and GPU code.
hi - i took a look at the sqlite db. not to nitpick, but you have 4 indexes there?
the overhead of indexes at tiny data sizes like this is minimal, so no surprise that sqlite or pg will compare favorably at laptop scale (FWIW, i ran this on a 4-core macbook pro with no GPU (i.e CPU only) and without indexes, mapd runs the query at ~1.5 sec while sqlite takes ~6).
however, the bigger point is about how this experience scales. take a look at this public demo - https://www.mapd.com/demos/ships. it's 11 billion geo data points, and you'll see the same low millisecond response that FridgeSeal is talking about - again, no indexing (to verify, go to dev tools in your browser, turn on SQLLogging(true) in the console and look at the query times reported for the round trip. i'm sure you appreciate that the overhead (both creation and maintenance) of indexing scales with data size, plus sqlite/pg dont (AFAIK) offer anything by way of GPU-rendered charting.
In terms of "in general", there's mapd, a startup doing something on a very similar space http://mapd.com/
It's definitely the case that our work is not ready to be shrink-wrapped and sold. But the need for it is there. I'm no longer at AT&T Research and can't answer for their current needs, and I unfortunately cannot talk about the usage scenarios when I was there. There's the academic paper you can read, http://nanocubes.net/paper.pdf, which has a few examples.
In practical terms, the difference in a system that has latency of a few seconds to one in which the queries come back in 60fps is significant, and enables a bunch of interesting stuff that might not be obvious at first sight.
Here is a paper on how to accelerate SQL database operations
on a GPU: http://www.cs.virginia.edu/~skadron/Papers/bakkum_sqlite_gpgpu10.pdf (University of Virginia, 2010) and an ealier work: http://www.researchgate.net/profile/Qiong_Luo2/publication/237618362_Relational_Query_CoProcessing_on_Graphics_Processors1/links/0046353abc1a0c5dfd000000.pdf (Hong Kong University of Science and Technology, 2009)
And here are similar pojects:
http://www.mapd.com/
https://github.com/antonmks/Alenka
FRom a series of Google searches and webcrawls i maintain for myself for my middle and upper managers. So this is not technical stuff
http://www.infoworld.com/article/3123747/data-center/faster-with-gpus-5-turbocharged-databases.html
https://blazingdb.com
http://diginomica.com/2016/04/11/do-gpu-optimized-databases-threaten-the-hegemony-of-oracle-splunk-and-hadoop/
https://www.kinetica.com
https://www.mapd.com
and of course many many more scholarly articles through arxiv
This is a great intro into the subject.
We use LLVM to at MapD (http://mapd.com) to compile SQL queries to CPU and GPU machine code - it has given us a major boost over an interpreter based approach. For more see here - http://devblogs.nvidia.com/parallelforall/mapd-massive-throughput-database-queries-llvm-gpus/. If you have a background in LLVM or compilers in general and are interested in tackling problems like this please reach out at jobs@mapd.com.
Hi infinite8s, to get additional information on how that chart was made, you can to go https://www.mapd.com/product/ scroll down to the bar chart, and click “See Details” under the chart. Shows the machines used, queries, and the source data set and size. Note that the machine configurations used to generate the chart were normalized for equivalent cost on AWS, i.e. the chart is hardware-dollar normalized.