Just-Right Consistency. Centralised data store. trois bases. As available as possible As consistent as necessary Correct by design

Transcription

1 Just-Right Consistency As available as possible As consistent as necessary Correct by design Marc Shapiro, UMC-LI6 & Inria Annette Bieniusa, U. Kaiserslautern Nuno reguiça, U. Nova Lisboa Christopher Meiklejohn, Northwestern U. Valter Balegas, U. Nova Lisboa trois bases Centralised data store Clients read and write primary copy [ 3 4

2 Geo-replicated DB Network artition + fault-tolerance + low latency read Updates? Read available replica Updates? 5 6 Eventual Consistency Strong Consistency Google Spanner Asynch. updates Available under artition Concurrency anomalies Hell for developers! 7 Synch. updates Consistent under artition Simple programming model Slow, expensive Not available under partition 8

3 Available + correct? Just-Right Consistency Insight: Maintain invariants reserve sequential patterns Merge concurrent updates Synchronise only when strictly necessary for application can't synch, can send correct! best possible availability and performance 9 Maintain (possibly unknown) application invariants Baseline: 1-copy, one op. at a time Invariant-maintaining patterns Ordered updates causal consistency Grouped updates atomic recondition-before-update Stable concurrent OK Not stable concurrency control Acompatible CAsensitive 10 FMK Fælles Medicinkort FMK Fælles Medicinkort atient create ( ) R X atient: Mr harmacy: Causatin: boxes

4 Invariant-maintaining patterns ordered updates atient grouped updates Geo-distributed FMK 1 create ( ) R X atient: Mr harmacy: Causatin: boxes Geo-distr.: invariants? EC does not maintain! precondition C is overkill! precondition 1 ordered updates create ( ) R X atient grouped updates atient: Mr harmacy: Causatin: boxes 1 Operation model generator e g effector e Replicated data: read one, update all Operation: generator = pure, read-only effector = lambda, update-only deferred-update transaction effector effector 15 16

5 Data model: registers? add-med(1) cnt 1 cnt cnt = 0 cnt = A data model: CRDTs add-med(1) cnt += 1 cnt += cnt = 0 cnt = 3 cnt = 0 cnt cnt 1 cnt = 1 cnt = 0 cnt += cnt += 1 cnt = 3 add-med() add-med() Concurrent, asynchronous updates Standard register model: assignments C A concurrent updates merged CRDT: register, counter, set, map, sequence Extends sequential type Encapsulates convergent merge Conflict-free replicated data types Sequential: register, set, map, graph CRDTs Backwards-compatible in sequential execution Concurrency semantics Local reads, mergeable writes Guaranteed convergence 17 Concurrent, asynchronous updates Standard register model: assignments C A concurrent updates merged CRDT: register, counter, set, map, sequence Extends sequential type Encapsulates convergent merge Ordered-updates pattern ordered updates 1 create ( ) R X atient 18 atient: Mr harmacy: Causatin: boxes

6 with CC animation Ordered: A-Compatible create-p before add-pp Ordered-updates invariant pattern: atient record points to valid prescription x valid x points to y y valid admin-login-enabled nondefault-password Make RHS true; then LHS true Transmit in the right order! A-compatible: Causal Consistency with animations 1=RHS! =LHS! Grouped: A-Compat. Atomic update 1! >1 Grouped-update pattern create ( ) R X atient grouped updates atient: Mr harmacy: Causatin: boxes 1 recondition-beforeupdate pattern atient create-p updates doctor, patient & cy record Transmit grouped updates together write-atomic + Read from common set of txns snapshot property = All-or-Nothing (A of ACID) A-compatible patient!! Snapshot patient!? patient?? precondition create ( ) R X atient: Mr harmacy: Causatin: boxes 1 3 4

7 -B-U is CA-sensitive pp(, 1) cnt 1 process-p (, nb) { if cnt nb // precondition at source cnt = nb // at every replica } // recond-before-update pp(, 1) cnt 1 cnt += 3 add-med (, 3) cnt += 3 = process-p (, nb) { if cnt nb // precondition at source cnt = nb // at every replica } // recondition stable w.r.t. concurrent add-med Concurrency OK! recond-before-update pp(, 1) cnt 1 process-p (, nb) { if cnt nb // precondition at source cnt = nb // at every replica } // recond-before-update pp(, 1) cnt 1 cnt = pp(, ) cnt 1 cnt = CISE Static Analysis process-p (, nb) { if cnt nb // precondition at source cnt = nb // at every replica } // recondition not stable w.r.t. concurrent process-p Forbid concurrency? Synchro, C. Or remove invariant? A, degraded semantics 6 7 8

8 CISE analysis JRC: Summary Application = operations + invariants 1. Does each individual op maintain invariant?. Do concurrent updates u v converge? 3. Is precondition of u stable w.r.t. concurrent v? roof: Invariant 3: Change specification (invariant) or Synchronise Designer decision, per pair (u, v) Ex: medication count= inc inc, inc dec, dec dec Tailor consistency to (possibly unknown) application invariants Baseline: 1-copy, one op. at a time Three invariant-maintaining patterns Ordered updates causal consistency Joint updates atomic recondition check Stable concurrent OK Not stable concurrency control 9 30 AntidoteDB.eu AntidoteDB.org CRDT data model Register, counter, set, map, sequence Extend sequential semantics A compatible Transactional Causal Consistency (TCC) Strongest A-compatible model Joint Updates / Transactional artial Order / Causal Consistency Open source, well engineered Community of users Rich interface with concurrent abstract data types (CRDTs) Geo-replication Low latency, Available under artition Erlang / Riak Core Growing community Active development Secondary Indexes, configurable back-ends and protocols, partial replication, clients in many languages, SQL interface, etc. 31 3

9 Sharded, parallel Architecture Copenhagen Total order ClockSI Get started with.org Causal order A: 10 B: 15 C: Aarhus Antidote and Just-Right Consistency JRC methodology for provably ensuring As Available as ossible, Consistent Enough TCC ordered, grouped updates recond-before-update: Bounded Ctr, CISE AntidoteDB: CRDTs.e Causal Consistency Transactions Bounded Counter Acompatible mostly A 33 C when necessary CISE verification & co-design (+ related tools) 35 More work to do Invariant-maintenance patterns: ordered updates, grouped updates, precond-before-update Complete? More evidence needed Scale to the edge: causal consistency expensive Active research area artial replication Avoidance through static analysis? Transaction semantics write-atomic easy read-atomic, causal: costly 34 36

10 Creative Commons Attribution-ShareAlike 4.0 Intl. License You are free to: Share copy and redistribute the material in any medium or format Adapt remix, transform, and build upon the material for any purpose, even commercially, under the following terms: Attribution You must give appropriate credit, provide a link to the license, and indicate if changes were made. You may do so in any reasonable manner, but not in any way that suggests the licensor endorses you or your use. ShareAlike If you remix, transform, or build upon the material, you must distribute your contributions under the same license as the original. 37