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

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?

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”)

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

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

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?

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

Tree Schemas Customer Order Line

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

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

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)

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?

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

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

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

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.

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”