Download Lazy Evaluation of Transactions in Database Systems

Lazy Evaluation of Transactions
in Database Systems
Authors: Jose Faleiro, Alexander Thomson, Daniel Abadi
Presenter: Atharva Deshmukh
Lazy Database Systems
• Based on Lazy Evaluation – Actual state of database may differ from
what has been told to client. Only after client requests a read,
promises about database state changes has to be kept.
• Perform transaction partially, just enough to return commit/abort
promise.
• Only when client performs a read of database state, remaining work
of transaction is performed.
Commit/Abort promises
• Transaction can abort in two cases:
Transaction logic can cause transaction to abort(e.g. violation of integrity
constraint) – dependent on state of database.
Database decides to abort for nondeterministic reasons(e.g. deadlock,
database crashes) – independent on state of database.
• Lazy Evaluation of transactions is viable only for deterministic
databases, which disallow the second type of aborts.
• Determine in transaction initiation whether transaction logic will
abort or not and return promise!
What’s in it for us?
• Improved cache locality
• Temporal load balancing
• Avoid unnecessary work
• Reduced contention footprint
• Reduced transaction execution latency
There are certain tradeoffs. Later…
Lazy Transactions
• Divide transaction in two phases:
• now-phase – Executed Immediately
• later-phase – Execution is deferred until some element of write set needs to
be substantiated.
• No need to write out actual values, put placeholders or stickies instead.
These correspond to unexecuted deferred logic that will be taken care of in
later-phase.
• This process of creating placeholder stickies is called stickification and
execution of transaction to overwrite the stickies with actual values is
called as substantiation.
Lazy Database Design
Lets explore how to –
• Split transactions in now and later phases?
• What are the consequences of splitting and tradeoffs?
• How do stickies serve their purpose?
..all with the help of an example scenario.
Remember now and later phases?
• We split transactions in now-phase and later-phase
• now-phase is executed immediately – gives a commit/abort promise
• Execution of later-phase is deferred – it does remaining part
now-phase
later-phase
What to make of later-phase/deferred logic?
• Since we are not executing it immediately, we won’t write out actual
values of records. But…
• We insert ‘stickies’ corresponding to unexecuted later-phase.
‘read A, process A, write A’ etc.
External Reads
• Till now we only dealt with transaction requests that expected just a
promise – commit/abort.
• External read is a read that must be returned to a database user. In
case of such read, we need to perform the deferred transaction.
• Thus, external reads depend on some deferred transaction which in
turn may also depend on other deferred transactions.
The subset of dependency graph that a transaction may depend on can grow
very large – which means higher read latency. So,
Tradeoffs
• Higher bound on maximum depth means larger batches and hence
improved cache locality
• Larger bound on depth means higher external read latency
Advantages of lazy transactions
• Improved Cache locality
• Temporal Load Balancing
• Reduced Contention/Simplified Concurrency Control
• Exploiting Blind Writes
• Reduced Latency for transactions returning only commit/abort
decisions
Experimental Evaluation – Cache Locality
Experimental Evaluation – Temporal Load
Balancing
Reduced Contention
• What is contention footprint? A transaction’s contention footprint is
duration of time that it limits the total concurrency achievable in the
system.
• Lazy database system – Contention footprint between now-phases is
reduced(owing to shorter length). Later-phase contention manifests
as dependencies when substantiating stickies.
TPC-C Throughput
TPC-C Latency
Blind Writes
• Some workloads contain “blind writes” to data – writes that are not
preceded by reads to the same records
• Lazy systems like blind writes - since by delaying writes to an item,
these writes may never have to be performed if they are rendered
unnecessary by a blind write.
Experimental Evaluation – Blind Writes
Experimental Evaluation – External Read
Latency CDF
Conclusion
• Lazy evaluation of transactions in database systems can
Improve cache locality
Temporally load balance a workload during spikes of transactional activity
Simplify concurrency control
Reduce latency for transactions that return only a commit or abort decision
Leverage blind writes to improve throughput
• Though lazy evaluation is not suitable for some workloads where
queries need to be evaluated immediately, there is class of workloads
for which lazy evaluation is able to improve throughput and latency
Acknowledgements
• http://www.jmfaleiro.com/pubs/slides14lazy.pdf
• Lazy Evaluation of Transactions in Database Systems – Paper itself
• Thanks to Jose for directing me to these slides and letting me use
them(specifically, the example transactions and graph slides).
Questions?
Thank you!
TPC-C Throughput