1. U NIVERSITY U NIVERSITY OF T ORONTO U NIVERSITY OF T ORONTO Bionic databases are coming. What will they look like? *Ryan Johnson & Ippokratis Pandis** CIDR 2013 ***

2. U NIVERSITY U NIVERSITY OF T ORONTO Dark silicon trumps Moore’s Law? More transistors coming, but we can’t use them “complicated” (grows as transistors shrink) power # transistors voltage frequency Dark silicon = Amdahl + Power

3. U NIVERSITY U NIVERSITY OF T ORONTO The DBMS is at a crossroads Data deluge continues Dark silicon looms Specialized HW becomes economical + =

4. U NIVERSITY U NIVERSITY OF T ORONTO Didn’t database machines fail? (yes) Economies of scale – Cloud: Amazon, Facebook, Google – Appliances: Exadata, Netezza Alternatives yield diminishing returns – OoO: mined out – MHz: mined out – Multicore: days numbered FPGA allows to “patch” hardware NRE: $O(10 9 ) for each new Intel process/chip Past reasons for failure smaller/missing now DIRECT

5. U NIVERSITY U NIVERSITY OF T ORONTO OLTP is fast enough. Why care about it? Operational analytics – OLTP “solved” but takes over the server – OLTP “solutions” make analytics harder Data acquisition is the new OLTP – Not just bread and butter transactions any more – Facebook, Twitter graphs, ad serving, financials, sensors, smart devices,... – App devs learning hard way that ACID is nice Goal: free resources for other/more uses

6. U NIVERSITY U NIVERSITY OF T ORONTO Death by a thousand paper cuts disk log insert lock wait latch wait queues cache miss jump or branch “Software-friendly” latencies (10μs or longer) Fine-grained latencies (under 10μs) Offload small latencies to specialized hardware Transition point is roughly context switch cost

7. U NIVERSITY U NIVERSITY OF T ORONTO Control flow in HW? HW good at control flow too – Many algs are state machines (sorting networks, regexp, FFT, etc.) – OS/server basic block size: 3 (load/compare/jump) Toolchains needs a lot of work – Everybody needs it, hard problem, out of scope Software platform needs to adapt – Computer architects are stuck – Ship computation to specialized components – Structure/design HW to make SW’s job easier

8. U NIVERSITY U NIVERSITY OF T ORONTO One possible bionic DBMS Columnar database Log files Log buffer Overlay manager Queuing engine Log insertion Enhanced scanner Space mgt. & bpool Log sync & recovery Query engine Route & schedule Database overlay Tree probe engine CC, SMO & reorg

9. U NIVERSITY U NIVERSITY OF T ORONTO Example: Tree-based indexing 100 operations wait 300ns 100 operations Tree probe in software Key compare End of node Value fetch is inode is leaf target key not found target key found Tree probe in hardware Simple operation, why waste Intel’s best on it?

10. U NIVERSITY U NIVERSITY OF T ORONTO Conclusions Custom database hardware is coming – Alternatives yield diminishing returns – Cloud/vertical providers have economies of scale How to benefit OLTP and data gathering? – Speedup unlikely, focus on power, latency offload – Must integrate with analytics Software and tools need to adapt – How to fit HW into SW ecosystem? – How to design hardware quickly?

11. U NIVERSITY U NIVERSITY OF T ORONTO Beware, bionic DBMSs are coming!