|
|
|
|
The Database State Machine |
|
Epsilon Serializability |
|
Epsilon-DBSM |
|
Experiments |
|
Conclusion |
|
|
|
|
Overcomes problems of traditional synchronous
replication protocols - contention and deadlocking |
|
Update-everywhere and deferred updates
replication |
|
Atomic multicast to propagate the transaction´s
processed data |
|
Total order combined with local conflict
detection phase to ensure 1SR. |
|
|
|
|
Serializability is the standard notion for
correctness in transaction processing |
|
Serializability is however too strict since even
read-only transactions need to scheduled in a serializable order |
|
Serializability has a strong impact on the
system’s overall performance and on the effective number of concurrent
transactions |
|
|
|
|
Changes to the isolation level: Allows unbounded
inconsistency and often cannot be tolerated (eg. read-uncommited) |
|
Exploiting the applications’ semantic: It must
be rebuilt for each new application |
|
Snapshot Isolation: It is not always available
and introduces versoning overhead and CC aborts (W-W conflicts) |
|
Epsilon-Serializability... |
|
|
|
|
|
Framework to stretch the database consistency |
|
Generic and can be manipulated per transaction |
|
Bounds the allowed inconsistency and may still
produce serializable results |
|
Improves performance by allowing more
concurrency or a larger number of effective transactions |
|
In our case |
|
Allows read-only transaction to produce bounded
inconsistency results |
|
Update transactions are executed preserving the
serializability criteria |
|
|
|
|
Locks can be granted if neither the imported nor
the exported inconsistencies are exceeded. |
|
Imported inconsistency is local to each Q while
inconsistency exported by U is a sum of the imported |
|
Divergence can assume various forms: absolute
values, aging, # of uncommited transactions, # of conflicts, etc. |
|
|
|
|
The motivation for this integration is the
improvement of the execution of read-only transactions |
|
Depending on the type of the load and on the
number of clients read-only transactions can be impaired |
|
Reduce the number of aborts of read-only
transactions caused by certification of remote transactions |
|
Increase concurrency by reducing contention
during local concurrency control |
|
|
|
|
Read-only transactions are handled locally |
|
Remote transactions may abort locally read-only
transactions to ensure 1 SR. |
|
ESR-DBSM simply augments the local CC mechanism. |
|
|
|
|
|
TPC-C Benchmark |
|
Transactions are annotated with tolerated number
of ESR conflicts |
|
Clients are uniformly distributed among 3 database sites |
|
Simulation tool combining real and
simulated code |
|
Database, clients and network are simulated |
|
DBSM and GC protocols are real implementations |
|
|
|
|
|
ESR allows to trade-off between consistency and
performance |
|
Consistency can be relaxed in a controlled and
consentaneous way |
|
ESR-DBSM is upper bounded by the strict locking
policy and lower bounded by the snapshot |
|
Without resorting to semantic specific epsilons
overall latency in the DBSM can be reduce by 40%. A very small number of
ESR conflicts contributes to this value |
|
Abort rate for read-only transactions is almost
eliminated |
|
|
|
|
Allow update transactions to import
inconsistencies |
|
Basically, by improving the DBSM using
reservation techniques among sites |
|
|
|