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

▶
rethinking serializable multi version concurrency control
SMART_READER_LITE
LIVE PREVIEW

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

Aug 20, 2023 136 likes •570 views

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

slide-1
SLIDE 1

Rethinking Serializable Multi-version Concurrency Control

Jose Faleiro and Daniel Abadi Yale University

slide-2
SLIDE 2

X0 Tr – Read X

Single-version system Multi-version system

Tw – Write X X0 Tr – Read X Tw – Write X

Theory: Single- vs Multi-version Systems

slide-3
SLIDE 3

Theory: Single- vs Multi-version Systems

X0 Tr – Read X

Single-version system Multi-version system

Tw – Write X X0 Tr – Read X Tw – Write X

Tr and Tw cannot simultaneously execute

slide-4
SLIDE 4

Theory: Single- vs Multi-version Systems

X0 Tr – Read X

Single-version system Multi-version system

Tw – Write X X0 Tr – Read X Tw – Write X X1

Tr and Tw cannot simultaneously execute Tr and Tw can both simultaneously make progress

slide-5
SLIDE 5

X0 Tr – Read X

Single-version system Multi-version system

Tw – Write X X0 Tr – Read X Tw – Write X

Theory: Single- vs Multi-version Systems

X1

Tr and Tw cannot simultaneously execute Tr and Tw can both simultaneously make progress

Multi-versioning obviously buys more concurrency, right?

slide-6
SLIDE 6

Practice: Multi-version Systems

T0:

if savings + checking >= 100 savings -= 100 Savings: 100 Checking: 50

T1:

if savings + checking >= 75 checking -= 75 Constraint: savings + checking >= 0

slide-7
SLIDE 7

Practice: Multi-version Systems

T0:

if savings + checking >= 100 savings -= 100 Savings: 100 Checking: 50

T1:

if savings + checking >= 75 checking -= 75 Constraint: savings + checking >= 0 Savings: 0

T0 commits

slide-8
SLIDE 8

Practice: Multi-version Systems

T0:

if savings + checking >= 100 savings -= 100 Savings: 100 Checking: 50

T1:

if savings + checking >= 75 checking -= 75 Constraint: savings + checking >= 0

T0 commits

Savings: 0 Checking: -25

T1 commits

slide-9
SLIDE 9

Practice: Multi-version Systems

T0:

if savings + checking >= 100 savings -= 100 Savings: 100 Checking: 50

T1:

if savings + checking >= 75 checking -= 75 Constraint: savings + checking >= 0 Savings: 0 Checking: -25

T0 commits T1 commits

slide-10
SLIDE 10

Practice: Multi-version Systems

T0:

if savings + checking >= 100 savings -= 100 Savings: 100 Checking: 50

T1:

if savings + checking >= 75 checking -= 75 Constraint: savings + checking >= 0 Savings: 0 Checking: -25

T0 commits T1 commits

“Solution”: Use conservative isolation techniques similar to single-version systems

slide-11
SLIDE 11

Practice: Multi-version Systems

T0:

savings += 100 begin: end: Savings: 25 begin: 0 end: 10 Savings: 75 begin: 10 end: inf

Monotonic timestamp generator

slide-12
SLIDE 12

Practice: Multi-version Systems

T0:

savings += 100 begin: end: Savings: 25 begin: 0 end: 10 Savings: 75 begin: 10 end: inf

Monotonic timestamp generator

slide-13
SLIDE 13

Practice: Multi-version Systems

T0:

savings += 100 begin: 12 end: Savings: 25 begin: 0 end: 10 Savings: 75 begin: 10 end: inf

Monotonic timestamp generator Determines snapshot visible to txn

slide-14
SLIDE 14

Practice: Multi-version Systems

T0:

savings += 100 begin: 12 end: Savings: 25 begin: 0 end: 10 Savings: 75 begin: 10 end: inf

Monotonic timestamp generator

slide-15
SLIDE 15

Practice: Multi-version Systems

T0:

savings += 100 begin: 12 end: 18 Savings: 25 begin: 0 end: 10 Savings: 75 begin: 10 end: 18

Monotonic timestamp generator

Savings: 175 begin: 18 end: inf

Determines visibility of txn’s writes

slide-16
SLIDE 16

Practice: Multi-version Systems

T0:

savings += 100 begin: 12 end: 18 Savings: 25 begin: 0 end: 10 Savings: 75 begin: 10 end: 18

Monotonic timestamp generator

Savings: 175 begin: 18 end: inf

Global counter Scalability bottleneck!

slide-17
SLIDE 17

Practice: Multi-version Systems

T0:

savings += 100 begin: 12 end: 18

Monotonic timestamp generator

Savings: 25 begin: 0 end: 10 Savings: 75 begin: 10 end: 18 Savings: 175 begin: 18 end: inf

Version management

  • verhead
slide-18
SLIDE 18

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
slide-19
SLIDE 19

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

Fundamental issue with concurrency control protocols Severe performance degradation on multi-core main-memory systems

slide-20
SLIDE 20

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
slide-21
SLIDE 21

Our Approach: Bohm

  • Separate concurrency control from transaction

execution

  • Concurrency control determines transaction order and

version visibility

  • Execution performs logic given concurrency control
  • rdering
slide-22
SLIDE 22

Bohm Overview

T0 T1 T2 T3 T4 T0 T1 T2 T4 T3

Concurrency Control Execution Determine legal schedule Perform logic

slide-23
SLIDE 23

Extra Requirements

  • Transactions’ entire logic must be submitted in one

piece

  • Transactions’ write-sets must be deducible prior to

their execution

slide-24
SLIDE 24

Concurrency Control Layer

  • Take a totally ordered batch of txns as input
  • Create a new version for each write
  • Versions created in sequence order
slide-25
SLIDE 25

Concurrency Control Layer

a b h f

T200

  • Partition data across multiple

threads

a e g

CC0

b c h

CC1

d f i

CC2

slide-26
SLIDE 26

Concurrency Control Layer

a b h f

T200

  • Partition data across multiple

threads

  • For every write, create a new

version

a e g

CC0

b c h

CC1

d f i

CC2

slide-27
SLIDE 27

Concurrency Control Layer

a b h f

T200

  • Partition data across multiple

threads

  • For every write, create a new

version

a e g

CC0

b c h

CC1

d f i

CC2

a e g begin: 0 end: inf

value0

slide-28
SLIDE 28

Concurrency Control Layer

a b h f

T200

  • Partition data across multiple

threads

  • For every write, create a new

version

a e g

CC0

b c h

CC1

d f i

CC2

a e g begin: 0 end: 200 prev a b h f

T200

begin: 200 end: inf

value0

slide-29
SLIDE 29

Concurrency Control Layer

a b h f

T200

  • Partition data across multiple

threads

  • For every write, create a new

version

a e g

CC0

b c h

CC1

d f i

CC2

a e g begin: 0 end: 200 prev a b h f

T200

begin: 200 end: inf

value0 Version contains txn reference No value yet

slide-30
SLIDE 30

Execution Layer

  • Begins executing a batch

after concurrency control completes

  • Perform txn logic, write out

data

a e g begin: 0 end: 200 prev a b h f

T200

begin: 200 end: inf

value0

slide-31
SLIDE 31

Execution Layer

  • Begins executing a batch

after concurrency control completes

  • Perform txn logic, write out

data

a e g begin: 0 end: 200 prev a b h f

T200

begin: 200 end: inf

value0 Replace txn reference with actual data

slide-32
SLIDE 32

Execution Layer

a e g begin: 0 end: 200 prev begin: 200 end: inf

value0 value1

  • Begins executing a batch

after concurrency control completes

  • Perform txn logic, write out

data Replace txn reference with actual data

slide-33
SLIDE 33

Implications of Design

a e g begin: 0 end: 200 prev a b h f

T200

begin: 200 end: inf

value0 Concurrency control fixes txn snapshots prior to their execution Execution only produces values No logical locking/validation

slide-34
SLIDE 34

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
slide-35
SLIDE 35

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
slide-36
SLIDE 36

Evaluation

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

Read-Write Concurrency

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

2x

slide-38
SLIDE 38

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
slide-39
SLIDE 39

Thanks!

JMFALEIRO.COM JOSE.FALEIRO@YALE.EDU

slide-40
SLIDE 40

Limitations of Contended Counters

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

3x

slide-41
SLIDE 41

Varying Contention

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

Increasing contention

slide-42
SLIDE 42

Long Running Read-only Txns

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