Rethinking Serializable Multi-version Concurrency Control Jose - PowerPoint PPT Presentation

Rethinking Serializable Multi-version Concurrency Control Jose Faleiro and Daniel Abadi Yale University

Theory: Single- vs Multi-version Systems Single-version T w – Write X T r – Read X system X 0 Multi-version T r – Read X T w – Write X system X 0

Theory: Single- vs Multi-version Systems Single-version T r and T w cannot T w – Write X T r – Read X system simultaneously X 0 execute Multi-version T r – Read X T w – Write X system X 0

Theory: Single- vs Multi-version Systems Single-version T r and T w cannot T w – Write X T r – Read X system simultaneously X 0 execute Multi-version T r and T w can both T r – Read X T w – Write X system simultaneously X 0 X 1 make progress

Theory: Single- vs Multi-version Systems Single-version T r and T w cannot T w – Write X T r – Read X system simultaneously X 0 execute Multi-versioning obviously buys more concurrency, right? Multi-version T r and T w can both T r – Read X T w – Write X system simultaneously X 0 X 1 make progress

Practice: Multi-version Systems T 0 : T 1 : if savings + checking >= 100 if savings + checking >= 75 savings -= 100 checking -= 75 Savings: 100 Checking: 50 Constraint: savings + checking >= 0

Practice: Multi-version Systems T 0 commits T 0 : T 1 : if savings + checking >= 100 if savings + checking >= 75 savings -= 100 checking -= 75 Savings: 100 Savings: 0 Checking: 50 Constraint: savings + checking >= 0

Practice: Multi-version Systems T 0 commits T 1 commits T 0 : T 1 : if savings + checking >= 100 if savings + checking >= 75 savings -= 100 checking -= 75 Savings: 100 Savings: 0 Checking: 50 Checking: -25 Constraint: savings + checking >= 0

Practice: Multi-version Systems T 0 commits T 1 commits T 0 : T 1 : if savings + checking >= 100 if savings + checking >= 75 savings -= 100 checking -= 75 Savings: 100 Savings: 0 Checking: 50 Checking: -25 Constraint: savings + checking >= 0

Practice: Multi-version Systems T 0 commits T 1 commits T 0 : T 1 : if savings + checking >= 100 if savings + checking >= 75 savings -= 100 checking -= 75 “Solution”: Use conservative isolation techniques similar to single-version systems Savings: 100 Savings: 0 Checking: 50 Checking: -25 Constraint: savings + checking >= 0

Practice: Multi-version Systems T 0 : Monotonic timestamp savings += 100 generator begin: end: Savings: 25 Savings: 75 begin: 0 end: 10 begin: 10 end: inf

Practice: Multi-version Systems T 0 : Monotonic timestamp savings += 100 generator begin: end: Savings: 25 Savings: 75 begin: 0 end: 10 begin: 10 end: inf

Practice: Multi-version Systems T 0 : Monotonic timestamp savings += 100 generator begin: 12 end: Determines Savings: 25 Savings: 75 snapshot visible to txn begin: 0 end: 10 begin: 10 end: inf

Practice: Multi-version Systems T 0 : Monotonic timestamp savings += 100 generator begin: 12 end: Savings: 25 Savings: 75 begin: 0 end: 10 begin: 10 end: inf

Practice: Multi-version Systems T 0 : Monotonic timestamp savings += 100 Determines generator visibility of begin: 12 end: 18 txn’s writes Savings: 25 Savings: 75 Savings: 175 begin: 0 end: 10 begin: 10 end: 18 begin: 18 end: inf

Practice: Multi-version Systems T 0 : Monotonic timestamp savings += 100 generator begin: 12 end: 18 Global counter Scalability bottleneck ! Savings: 25 Savings: 75 Savings: 175 begin: 0 end: 10 begin: 10 end: 18 begin: 18 end: inf

Practice: Multi-version Systems T 0 : Monotonic Version management timestamp savings += 100 overhead generator begin: 12 end: 18 Savings: 25 Savings: 75 Savings: 175 begin: 0 end: 10 begin: 10 end: 18 begin: 18 end: inf

Practice: Multi-version Systems • Offer the same amount of concurrency as single- version systems • Do not effectively exploit multi-versioning • Significant sources of overhead • Contended counters • Version management

Practice: Multi-version Systems • Offer the same amount of concurrency as single- version systems • Do not effectively exploit multi-versioning Fundamental issue with concurrency • Significant sources of overhead control protocols • Contended counters • Version management Severe performance degradation on multi-core main-memory systems

Root Cause • Multi-version databases enforce serial order dynamically • Concurrency control occurs during transaction execution • Requires conservative concurrency control • Same read-write concurrency as single-versioning • Concurrency control meta-data prone to contention

Our Approach: Bohm • Separate concurrency control from transaction execution • Concurrency control determines transaction order and version visibility • Execution performs logic given concurrency control ordering

Bohm Overview T 0 T 0 Concurrency Execution Control T 1 T 1 T 2 T 2 T 3 T 3 Perform logic Determine legal T 4 T 4 schedule

Extra Requirements • Transactions’ entire logic must be submitted in one piece • Transactions’ write-sets must be deducible prior to their execution

Concurrency Control Layer • Take a totally ordered batch of txns as input • Create a new version for each write • Versions created in sequence order

Concurrency Control Layer • Partition data across multiple threads T 200 a b h f a b d e c f g h i CC 0 CC 2 CC 1

Concurrency Control Layer • Partition data across multiple threads • For every write, create a new version T 200 a b h f a b d e c f g h i CC 0 CC 2 CC 1

Concurrency Control Layer • Partition data across multiple threads a value 0 • For every write, create a new e version g end: inf begin: 0 T 200 a b h f a b d e c f g h i CC 0 CC 2 CC 1

Concurrency Control Layer • Partition data across multiple threads T 200 a a b h f • For every write, create a new e version g begin: 200 end: inf T 200 prev a b h f value 0 a b d e c f begin: 0 end: 200 g h i CC 0 CC 2 CC 1

Concurrency Control Layer • Partition data across multiple threads T 200 a a b h f • For every write, create a new e version g begin: 200 end: inf T 200 prev Version contains txn a b h f reference value 0 a b d No value yet e c f begin: 0 end: 200 g h i CC 0 CC 2 CC 1

Execution Layer • Begins executing a batch after concurrency control T 200 a completes a b h f e g begin: 200 end: inf • Perform txn logic, write out prev data value 0 begin: 0 end: 200

Execution Layer • Begins executing a batch after concurrency control T 200 a completes a b h f e g begin: 200 end: inf • Perform txn logic, write out prev data value 0 Replace txn reference with actual data begin: 0 end: 200

Execution Layer • Begins executing a batch after concurrency control a value 1 completes e g begin: 200 end: inf • Perform txn logic, write out prev data value 0 Replace txn reference with actual data begin: 0 end: 200

Implications of Design Concurrency control fixes T 200 a txn snapshots prior to their a b h f e execution g begin: 200 end: inf prev value 0 Execution only produces values begin: 0 end: 200 No logical locking/validation

What have we gained? • Strong concurrency guarantees • Reads never block writes • Write-write conflicts never lead to aborts • Significant reduction in contention • No contended counters • Contention-free concurrency control

Baselines • Hekaton • State-of-the-art MVCC protocol • No garbage collection, simple array indices • Snapshot Isolation • Not serializable • Based on Hekaton • OCC • Silo – Decentralized timestamps, latch-free validation • Two-Phase Locking • No global latches, deadlock free

Evaluation • Effect of read-write concurrency • YCSB-like: 2RMWs + 8 Reads • High contention

Read-Write Concurrency 2.0 M Bohm SI Hekaton 2PL 1.5 M Throughput (txns/sec) OCC 2x 1.0 M 0.5 M 0.0 M 0 4 8 12 16 20 24 28 32 36 40 44 Number of Threads

Conclusions • State-of-the-art databases are unable to reduce read-write conflicts despite using multi-versioning • Bohm: Separate concurrency control from execution • Bohm makes strong concurrency guarantees • Reads never block writes • Write-write conflicts never lead to aborts • Bohm eliminates contention due to concurrency control

Thanks! JMFALEIRO.COM JOSE.FALEIRO@YALE.EDU

Limitations of Contended Counters 4.0 M Bohm 2PL 3.5 M OCC SI 3.0 M Throughput (txns/sec) Hekaton 2.5 M 3x 2.0 M 1.5 M 1.0 M 0.5 M 0.0 M 0 4 8 12 16 20 24 28 32 36 40 44 Number of Threads

Varying Contention 3.0 M Increasing contention 2.5 M Throughput (txns/sec) 2.0 M 1.5 M 1.0 M OCC Bohm 2PL 0.5 M SI Hekaton 0.0 M 0 0.1 0.2 0.3 0.4 0.5 0.6 0.7 0.8 0.9 1 Theta

Long Running Read-only Txns Bohm SI Hekaton 100 K OCC Throughput (txns/sec) 2PL 10 K 1 K 1 25 50 75 100 Percentage of Read-only Transactions