The End of an Architectural Era

Document Sample
The End of an Architectural Era Powered By Docstoc
					The End of an Architectural
 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
• Avoid commit protocols requiring a wait for
  other sites
• 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

       Order                 Order             Order

          Line                   Line                  Line

Line               Line                 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
• Divide other tables such that rows are
  colocated with related rows in root table
           Site 1:                 Site 2:
            Steve                  Dave
       Steve’s Orders         Dave’s Orders
    Steve’s Orders’ Lines   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
   – Enables decomposition of transactions into single-
     sited subplans.
   – Decompose and dispatch: no need for further
  Vertical Partitioning Example

          Managers                                        Drivers


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
• Execute if there are no uncommitted
  earlier transactions pending, abort
• 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
• 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”

Shared By: