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

Download Presentation
Download Policy: The content available on the website is offered to you 'AS IS' for your personal information and use only. It cannot be commercialized, licensed, or distributed on other websites without prior consent from the author. To download a presentation, simply click this link. If you encounter any difficulties during the download process, it's possible that the publisher has removed the file from their server.

Recommend


More recommend