Transcript PPSX - Ippokratis Pandis

UNIVERSITY OF TORONTO
Bionic databases are coming.
What will they look like?
*Ryan Johnson & Ippokratis Pandis**
CIDR 2013
UNIVERSITY OF
*
TORONTO
**
UNIVERSITY OF TORONTO
Dark silicon trumps Moore’s Law?
10% serial
power
1% serial
# transistors
voltage
0.1% serial
Over
power
budget
2018 (1024 cores)
Dark silicon
= Amdahl + Power
frequency
“complicated”
(grows as transistors shrink)
More transistors coming, but we can’t use them
UNIVERSITY OF TORONTO
The DBMS is at a crossroads
• Data deluge continues
• Dark silicon looms
• Specialized HW becomes economical
+
=
UNIVERSITY OF TORONTO
Didn’t database machines fail? (yes)
• Economies of scale
– Cloud: Amazon, Facebook, Google
– Appliances: Exadata, Netezza
• Alternatives yield diminishing returns
GAMMA
DIRECT
1985
– OoO: mined out
– MHz: mined out
– Multicore: days numbered
• FPGA allows to “patch” hardware
• NRE: $O(109) for each new Intel process/chip
Past reasons for failure smaller/missing now
UNIVERSITY OF TORONTO
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
UNIVERSITY OF TORONTO
Death by a thousand paper cuts
Transition point is roughly
context switch cost
“Software-friendly” latencies
(10μs or longer)
lock
wait
disk
log
insert
queues
cache
miss
latch
wait
jump or
branch
Fine-grained latencies
(under 10μs)
Offload small latencies to specialized hardware
UNIVERSITY OF TORONTO
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
UNIVERSITY OF TORONTO
One possible bionic DBMS
Query
engine
Space
mgt. &
bpool
CC, SMO
& reorg
Log sync
&
recovery
Route &
schedule
Enhanced
scanner
Overlay
manager
Tree
probe
engine
Log
insertion
Queuing
engine
Columnar database
Database overlay
Log buffer
Log files
UNIVERSITY OF TORONTO
Example: Tree-based indexing
Tree probe in software
Tree probe in hardware
100 operations
target key
not found
wait 300ns
Key
compare
100 operations
wait 300ns
target key
found
is inode
100 operations
wait 300ns
End of
node
is leaf
100 operations
Value
fetch
Simple operation, why waste Intel’s best on it?
UNIVERSITY OF TORONTO
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?
UNIVERSITY OF TORONTO
Beware, bionic DBMSs are coming!