this talk is about data consistency in 3d
play

This talk is about Data consistency in 3D Understanding consistency - PowerPoint PPT Presentation

This talk is about Data consistency in 3D Understanding consistency (Its the invariants, stupid) Primitive consistency mechanisms How primitives compose models How models relate / differ What they cost Understanding


  1. This talk is about… Data consistency in 3D Understanding consistency (It’s the invariants, stupid) • Primitive consistency mechanisms • How primitives compose models • How models relate / differ • What they cost Understanding invariants • Some interesting classes of invariants Marc Shapiro Masoud Saieda Ardekani Relating consistency to invariants Gustavo Petri • Which primitives guarantee which invariants Useful intuitions for app. and system designers [Consistency in 3D] 2 Shared database Geo-replicated database q: Queue q: Queue c: Counter c: Counter q: Queue { |q| ≤ c } { |q| ≤ c } c: Counter { |q| ≤ c } 5 ms – ∞ c.inc() c.inc() q.push(e) q.push(e) c.inc() Social, web, e-commerce: shared mutable data c.inc() Social, web, e-commerce: shared mutable data Scalability ⇒ replication ⇒ consistency issues Scalability ⇒ replication ⇒ consistency issues q: Queue c: Counter { |q| ≤ c } q.val() q.val() c.val() c.val() q 3 ∈ Queue? q 1 = q 2 ? |q 1 | ≤ c 4 ? [Consistency in 3D] [Consistency in 3D] 3 4

  2. Consistency Consistency opportunities and costs CAP More replicas: Availability • Better read availability, responsiveness, ⟹ Parallelism keeps the hardware busy performance, etc. ⟹ More implem. options, scalable • More work to keep replicas in sync But consistency constrains order of events: Consistent = behavior similar to sequential: • Delay delivery • Satisfies specs: does q behave like a queue? • Stale reads • Replicas agree: is q identical everywhere? • Waits, synchronisation (mutual wait) • Objects agree: is |q| ≤ c ? Keeping track of order requires metadata • Same flow of time? q1.push() before q2.push() Significant! [Consistency in 3D] [Consistency in 3D] 5 6 Costs illustrated Strict Serialisability 90% Read-only transactions; Disaster Tolerant T1 client Termination Latency of Update Transactions (ms) T1 T3 T2 70% Read-only transactions; Disaster Tolerant R1 R2 3 × R3 T1 T3 T2 Invariant Invariant Invariant P-Store-SER GMU-US Serrano-SI Jessy 2pc -NMSI 4.5 × RC Walter-PSI SDUR-SER [Consistency in 3D] [Consistency in 3D] Credit: Masoud Saeida Ardekani 7 8

  3. Eventual consistency Strong vs. weak? Low Strict Serialisability Predictable Strict Serialisability performance Op1 Snapshot Isolation Op2 R1 PRAM R2 R3 Hard to High Eventual Consistency program performance [Consistency in 3D] [Consistency in 3D] 9 10 Strong vs. weak? Strong vs. weak? Low Strict Serialisability Strict Serialisability Predictable performance Linearizability Strict Serializability (PL-SS) Fork Timed serial Regular & ∆,Γ-atomicity Eventual Full Serializability (PL-3) linearizability Sequential Prefix linearizable Weak Safe Strong fork-lin. Staleness-based Per-object eventual models Snapshot Serialis- models Update Serializability (PL-3U) Snapshot Isolation (PL-SI) Bounded Causal+ Real-time Processor Synchronized Prefix k-atomicity fork-join causal Eventual sequential models causal Bounded serializability Timed Isolation ability Weak ordering staleness causal Per-key Per-record & Causal sequential Delta timeline Release Fork models Forward Consistent View (PL-FCV) & k-regular sequential Causal Coherence Fork* Lazy release Per-object Repeatable Read (PL-2.99) Fork-join Scope causal causal PRAM Entry PBS (FIFO) Consistent View (PL-2+) Slow Location t-visibility Monotonic Snapshot PBS Fork-based memory k-staleness PRAM Reads (PL-MSR) models k-safe Writes-follow-reads Read-your-writes Monotonic Writes Monotonic Reads Eventual (WFR) (RYW) (MW) (MR) Session models Monotonic View (PL-2L) Quiescent Cursor Stability (PL-CS) Weak PL-2 Hard to High Eventual Consistency PL-1 program performance Transactional Non-transactional Adya 1999 Viotti & Vukoli ć 2016 [Consistency in 3D] [Consistency in 3D] 11 12

  4. Three classes… Three dimensions Gen1 / Linearisability Total Order Mostly orthogonal (but not all combinations …of invariant … of protocol make sense.) Strict Serialisability Serialisability CAP Gen1 Object value Total order of operations Snapshot Relative ordering Isolation PO Visibility of operations PO / Visibility Eventual Consistency State EQ Composition Causal equivalence / Q E n o i t s i o p m o C Txnl CC [Consistency in 3D] [Consistency in 3D] 13 14 Operation Sequential correctness x=3 x=4 x=4 x=4 y=–2 true y=–2 y=–2 y=–2 x+y>0 x:=3 x+y>0 y ≔ –3 ¬x+y>0 skip x:=3 y ≔ –3 skip x+y ≥ 0 x+y ≥ 0 generator : read, compute, generate effector generator : read, compute, generate effector effector : compute, write side-effect effector : compute, write side-effect Sequential execution: Sequential execution: • precondition ⟹ invariant • precondition ⟹ invariant • each effector individually safe • each effector individually safe [Consistency in 3D] [Consistency in 3D] 15 16

  5. Guarantee vs. semantics Data types Register • Update: assign with constant Guarantee: ‣ Not commutative • Class of invariants that is always true ‣ Absorbing • Regardless of application code High-level types • Assuming sequentially correct • Counter, ORset, Sequence: Application can compensate for absence effectors commute of guarantee • Stock, Account, Queue: ¬ commute • e.g. Inv={ c ≥ 0 }, app: c.inc() Composed data • + structural invariants [Consistency in 3D] [Consistency in 3D] 17 18 Replicated operation Sharded, geo-replicated ¬ read my DC 3 writes x=0 u x=1 client y=0 arbitrary origin y’=1 u PRE u ! origin x 1 :=0 replica u ? x 1 >0 y 1 +=1 x 1 u PRE y 1 DC 1 replica z 1 u ! x 2 :=0 u PRE y 2 +=1 sharded, x 2 replica DC 2 parallel v ! y 2 u ! v ? z 2 z 2 %2=0 u: state ⤻ (retval, (state ⤻ state)) Read one, write all (ROWA) Deferred-update replication (DUR) concurrent updates [Consistency in 3D] [Consistency in 3D] 19 20

  6. EQ: transactional Type EQ invariants composition • A = B Airplane reservation • x.friendOf (y) ⟺ y.friendOf (x) • Allocate a seat to me • x + y = constant • Pay for the flight • South ⨄ Boat ⨄ North Two EQ relations: = { sheep, dog, wolf } • paid = have_seat Joint update to two objects • my $$ + airline $$ = constant Atomicity (all-or-nothing) property of transactions Ad-hoc grouping Protocol: single update message (This txn also needs TO + snapshot) • Asynchronous [Consistency in 3D] [Consistency in 3D] 21 22 EQ/Composition axis EQ/Composition axis Transaction groups operations Transaction groups operations All-or-nothing effects: All-or-nothing effects: • Deliver effectors indivisibly • Deliver effectors indivisibly Linearisability 0 = Independent 0 = Independent PRAM operations operations ‣ packaged together ‣ packaged together • + same TOE • + same TOE All-or-nothing All-or-nothing ‣ ≈ 2-phase commit ‣ ≈ 2-phase commit RC effects effects Snapshot reads: Snapshot reads: Serialisability • all generators read from Snapshot Isolation • all generators read from + snapshot + snapshot Trans. Causal same set of effectors same set of effectors ‣ maintain versions ‣ maintain versions • + same TO, VIS guarantees • + same TO, VIS guarantees ‣ coordination ‣ coordination [Consistency in 3D] [Consistency in 3D] 23 24

  7. Type PO invariants EQ/Composition axis Transaction groups operations • employee.manager.salary ≥ employee.salary All-or-nothing effects: • S1; S2; S3 ≣ S1 ⟸ S2 ⟸ S3 • Deliver effectors indivisibly Linearisability 0 = Independent • dog ∈ S ⟸ sheep ∈ S ∧ wolf ∈ S PRAM operations ‣ packaged together • Referential integrity • + same TOE • “inode references disk block” All-or-nothing ‣ ≈ 2-phase commit RC effects • ACL (u, p) ⟸ access (u, p) Snapshot reads: Serialisability Snapshot Isolation • all generators read from Demarcation Protocol: + snapshot Trans. Causal same set of effectors 1. increase LHS by c ‣ maintain versions 2. increase RHS by c' ≤ c ⟹ ordered delivery • + same TO, VIS guarantees ‣ coordination No synchronisation: Available [Consistency in 3D] [Consistency in 3D] 25 26 PO: transitive / causal PO: transitive / causal visibility visibility x = 100; y = 100 x = 100; y = 100 Inv = { x ≥ y } Inv = { x ≥ y } x ! x ! Ex 1: Ex 1: • P1: x += 100 • P1: x += 100 y ! y ! • P2: if x > y then y += (x–y)/2 • P2: if x > y then y += (x–y)/2 x ! x ! • P3: x ≥ y ? • P3: x ≥ y ? y ! y ! x ! x ! x ! • Transitive visibility vis* ⊆ vis • Transitive visibility vis* ⊆ vis client is part of DB Ex 2: Ex 2: x ! d ! • P1: x += 100; d ≔ 100 • P1: x += 100; d ≔ 100 y ! • P2: if d > 0 then y += d/2 • P2: if d > 0 then y += d/2 • P3: x ≥ y ? • P3: x ≥ y ? d ! Causal visibility ( vis; po)* ⊆ vis Causal visibility ( vis; po)* ⊆ vis x ! y ! x ! [Consistency in 3D] [Consistency in 3D] 27 28

Recommend


More recommend