4 ms·
> Most traditional SQL databases are I/O-bound, meaning that the cost of pulling index pages from disk into memory overwhelms everything else, and adding more C
by gopalv 9y ago
> Most traditional SQL databases are I/O-bound, meaning that the cost of pulling index pages from disk into memory overwhelms everything else, and adding more CPU doesn't do much good.
A traditional database is somewhat tied to a disk for persistence, particularly if it is transactional, but this is more of a top fuel dragster with a mile to run.
The first assumption is that you can fit the current working set into memory - this might not be a raw stream of data, but perhaps hundreds of data-points per cellphone tower which probably occupies around 60-100Gb.
Something like Postgres would be stuck on a single core at this point mostly waiting on memory bandwidth (with associated NUMA bandwidth issues of picking 1 core).
Being able to use the memory bandwidth of the GPUs, plus being forced to write code which is entirely branch independent (CPUs are good, but they still have silicon to expect branches), gives you a massive scan speedup once your data fits within the scale-up single node situation.
If you're willing to shard out your data across multiple machines and never do joins across the shards, you can get distributed scans.
This is never going to be your primary system of record, but just something that can hold a cube/matrix and slice/dice through it faster than a CPU based system can.
If you replace the "GPU and open-source" with "custom silicon and proprietary", you might be looking at something which is very much like Netezza.
- anarazel 9y ago> A traditional database is somewhat tied to a disk for persistence, particularly if it is transactional, but this is more of a top fuel dragster with a mile to run. Sure, for writing that's somewhat true (in many traditional RDBMs you can relax guarantees e.g. with UNLOGGED tables in postgres). But for reads, not really. Most databases have a buffer layer in front of the disk / os. > Something like Postgres would be stuck on a single core at this point mostly waiting on memory bandwidth (with associated NUMA bandwidth issues of picking 1 core). Obviously depends on the type of query (filtering, aggregation, joins ...) you're doing, but postgres can actually parallelize things to multiple cores these days (since 9.6, a lot more to be released with v10). Unfortunately, if you're forced to use a single core, memory bandwidth is seldomly the actual bottleneck. In many cases postgres will be CPU bound elsewhere ("tuple deforming", evaluating filters / aggregation expressions), or for other types of queries memory latency will be much more important due to random access nature (think of hash-joins/aggs or nested-loop joins). We're working on that. > Being able to use the memory bandwidth of the GPUs That only really helps you if a significant portion of the working set fits onto GPUs. Which'll usually not if we're talking 60-100GB of main memory resident data. If you're reading sequentially through all that data you'll be bound by the main memory latency (including those NUMA issues etc you mentioned).
- tmostak 9y ago60-100GB? Many of our users run with 8 GPUs and 192GB VRAM, with larger VRAM buffers likely coming soon. And that's before you consider the fact that you don't need to cache all columns and partitions in a column store or compress the data. Its pretty easy to query 15+ active columns on 5B rows on a single server, and then there's scale out if you need more.
- qeternity 9y agoI want to see how this compares to something like Memsql, which we've had amazing success with.