Embed Size (px)
DESCRIPTION
For 30 years the central fact of database performance was the gigantic difference in the time it takes to access a random piece of data in RAM versus on a hard drive. It’s now feasible to skip all that heartache by placing your data entirely in RAM. It’s not as simple as that, of course. You can’t just take a btree, mmap it, and call it a day. There are a lot of implications to a truly memory-native design that have yet to be unwound. These two trends are producing an entirely new way to think about, design, and build applications. So let’s talk about how we got here, how we’re doing, and hints about where the future will take us.
Citation preview
CPU Register 1 nsMain Memory 100 nsFlash Drive 100,000 nsHard Drive
10,000,000 ns
Prehistorical Times
The Database
The Web Server
The Inter-Net
The User
2000: Load Balancing Solves Everything!
2002: Replication Solves Everything!
2002: Replication Solves Everything!
2004: Memcached Solves Everything!
2004: Memcached Solves Everything!
>_< >_<
>_< >_<
2006: Sharding Solves Everything!
2008: NoSQL Solves Everything!
2010: Map/Reduce Solves Everything!
Bringing you yesterday’s insights, tomorrow!
2012: NoSQL Solves Everything, Again!
2012: NoSQL Solves Everything, Again!
2014: What now?
?
2014: What now?
Load balancing (with failover)
Replication (without wasted hardware)
RAM storage (without cache invalidation)
Sharding (with management)
Analytics (without ETL headaches)
SQL (because, math)
2014: SQL RAM Clusters Solve Everything!
2014: The Definite Article
The Web Tier
The Data Tier
The End!
Those who ignore computer
history are condemned to
GOTO 1
NUMA NUMA
Throughput and latency
always have the last laugh.
2016: [ ??? ] Solves
Everything!
