The End of an Architectural Era

1. The End of an Architectural Era It’s Time for a Complete Rewrite

2. In Summary • Argues that RDBMSs as we know them were designed for a different world • Ad hoc queries • Interactive use • Dumb clients • Time for a change?

3. Design Considerations • Database fits in main memory • Transactions rarely wait  single thread (thread per core, where appropriate, sharing nothing) • Dynamically scale by adding/removing nodes • Replication for fault tolerance • All replicas actively processing • No need to redo, only temporary undo • Self-tuning (“no knobs”)

4. Design Considerations • Run application logic in the same process as the DBMS (stored-procedures) • Use optimistic concurrency control methods • Avoid commit protocols requiring a wait for other sites

5. H-Store • Specify transaction classes in advance • (Class example: “delete all rows from Orders where customer = $(customer)”) • Specify table definitions in advance • Many processing/storage nodes, divided into replica groups • Techniques to accelerate specific subsets of possible transactions

6. Replica Consistency • Timestamp ordering • Assigned locally • Clocks “nearly in sync” (NTP) • Wait a “small period of time” to avoid misordering transactions • Makes reference to a “maximum delay,” which is unbounded on an Ethernet?

7. Optimistic Concurrency • Transactions are short • No local locking at all • Design to avoid contention

8. Tree Schemas Customer Order Order Order Line Line Line Line Line Line

9. Constrained Tree Applications • For each transaction, all queries refer to same entry in root or related rows • Horizontally divide root table according to ranges or hash-ranges on primary key (not automated) • Divide other tables such that rows are colocated with related rows in root table Site 1: Steve Steve’s Orders Steve’s Orders’ Lines Site 2: Dave Dave’s Orders Dave’s Orders’ Lines

10. Making non-trees faster • Single-sited transactions similar to tree case • Replicate read-only data • Try to make applications “one-shot”: • No intra-transaction dataflow • No inter-site communication within transactions • Vertically partitioning tables to achieve this (not automated) • Enables decomposition of transactions into single-sited subplans. • Decompose and dispatch: no need for further communiction

11. Vertical Partitioning Example Managers Drivers Cars Transaction 1: For a given manager, find his cars and set their colour Transaction 2: For a given drivers, find his cars and mark them as sold Store the OWNED column of Cars with its associated worker Store the COLOUR column of Cars with its associated manager Store the primary key of Cars in both locations (it is read only)

12. One-Shot Example • Good: “Find a manager and mark his cars as blue, then find and delete a given driver” • Second phrase doesn’t depend on first • Can decompose even though manager and driver may not be colocated • Bad: “Get a given employee’s salary, and deduct that figure from a department’s budget” • Dependency • Many-to-many relationship • Where to store the departments?

13. Two-phase transactions • Read things from many sites • Maybe abort • Write things to many sites • Strongly two-phase: based on reads, can make a site-local abort decision • No undo logs required

14. Sterile Transactions • Transaction which may run arbitrarily interleaved with any other transaction and always produce the same final state • Obviously no need for concurrency control • However no guarantee that transaction’s commit/abort decision will be unaffected • Need a vote

15. General Transactions: Basic • Decompose to individual sites • At a site, wait for the same “small period of time” • Execute if there are no uncommitted earlier transactions pending, abort otherwise • Need an undo log, as might abort later • Wait for results from sites, issue next wave

16. General Transactions: Advanced • If there are too many aborts • Wait longer to determine if a plan belonging to an earlier transaction appears • If still too many aborts • Track complete read-set and write-set of each transaction, abort if strictly necessary.

17. Performance • TPC-C benchmark • Five transaction classes • Able to make all classes one-shot • Needed to vertically partition a table which never experiences inserts or deletes • Able to make every transaction sterile  the “small delay” was removed for the test! • 82x speedup over an undisclosed “very popular commercial RDBMS”