3 ms·

The article links to a presentation by one of the authors of VoltDB. On slide 17 he makes the crucial point that overhead (latching, locking, recovery, and buf

by jmulho 16y ago

The article links to a presentation by one of the authors of VoltDB. On slide 17 he makes the crucial point that overhead (latching, locking, recovery, and buffer pool) makes up 88% of the work that a typical RDBMS must do. Useful work (doing your SQL) accounts for only 12%. Attempting to gain speed by optimizing the useful work (sorting, joining, indexes) is thus pointless. Doing the database in memory (getting rid of buffer pool) is a good way to gain speed, but it can only hope to be two times faster (because the other 3 types of overhead remain). The only way to get really fast is to address all four types of overhead, which is what VoltDB attempts to do. Point taken. However, the author needs to work his pie chart skills. The 12% useful work on slide 17 is displayed as a tiny sliver (more like 3%) of the pie. This hinted to me that the whole presentation is a bit of an exaggeration.

jhugg 16y ago
The pie chart is based on this paper: http://cs-www.cs.yale.edu/homes/dna/papers/oltpperf-sigmod08.pdf http://cs-www.cs.yale.edu/homes/dna/papers/oltpperf-sigmod08.... The pie chart numbers have been updated to reflect the right charts in the paper, but the graphic hasn't. We'll try to get that fixed for future presentations. The point is very real. Stavros, Dan, Sam and Mike took the Shore RDBMS and stuck it on top of memory. Then they removed parts of it and measured the performance difference. Logging, buffer management, and concurrency management make up about 93% of the instructions run and 88% of the cycles for TPC-C "new order". There was no single area that dominated this overhead, so removing one piece doesn't make enough of a difference. Results on Oracle, SQL Severer and DB2 might be different, but it's hard to imagine they'd be dramatically different. Because VoltDB was built without these sources of overhead, it's usually quite a bit faster than systems that take legacy RDBMSs and back them with memory. VoltDB has limitations (especially in 1.0), but if your workload fits, it will go as fast as you need it to.

by jmulho 16y ago

jhugg 16y ago

The pie chart is based on this paper: http://cs-www.cs.yale.edu/homes/dna/papers/oltpperf-sigmod08.pdf http://cs-www.cs.yale.edu/homes/dna/papers/oltpperf-sigmod08.... The pie chart numbers have been updated to reflect the right charts in the paper, but the graphic hasn't. We'll try to get that fixed for future presentations. The point is very real. Stavros, Dan, Sam and Mike took the Shore RDBMS and stuck it on top of memory. Then they removed parts of it and measured the performance difference. Logging, buffer management, and concurrency management make up about 93% of the instructions run and 88% of the cycles for TPC-C "new order". There was no single area that dominated this overhead, so removing one piece doesn't make enough of a difference. Results on Oracle, SQL Severer and DB2 might be different, but it's hard to imagine they'd be dramatically different. Because VoltDB was built without these sources of overhead, it's usually quite a bit faster than systems that take legacy RDBMSs and back them with memory. VoltDB has limitations (especially in 1.0), but if your workload fits, it will go as fast as you need it to.