Tweet
Tweet

Slide 1

Slide 1 text

Just-Right Consistency Closing the CAP Gap Christopher S. Meiklejohn (@cmeik) J on the Beach 2017, Málaga, Spain

Slide 2

Slide 2 text

Outline: Closing the CAP Gap • Just-Right Consistency
 Available as possible, and consistent when necessary 2

Slide 3

Slide 3 text

Outline: Closing the CAP Gap • Just-Right Consistency
 Available as possible, and consistent when necessary • AntidoteDB
 The first database that provides transactions with strong semantics, targeted at the JRC approach 2

Slide 4

Slide 4 text

Outline: Closing the CAP Gap • Just-Right Consistency
 Available as possible, and consistent when necessary • AntidoteDB
 The first database that provides transactions with strong semantics, targeted at the JRC approach • Moving forward
 Antidote’s path forward from research to company and product 2

Slide 5

Slide 5 text

Motivation Cloud Databases 3

Slide 6

Slide 6 text

[Photo: http://vignette3.wikia.nocookie.net/the-titans-rp-and-information/images/f/f5/Blank-World-map2.gif/revision/latest/scale-to-width-down/1280?cb=20141016203452]

Slide 7

Slide 7 text

A Centralized database. [Photo: http://vignette3.wikia.nocookie.net/the-titans-rp-and-information/images/f/f5/Blank-World-map2.gif/revision/latest/scale-to-width-down/1280?cb=20141016203452]

Slide 8

Slide 8 text

A Clients read and write against the primary copy. [Photo: http://vignette3.wikia.nocookie.net/the-titans-rp-and-information/images/f/f5/Blank-World-map2.gif/revision/latest/scale-to-width-down/1280?cb=20141016203452]

Slide 9

Slide 9 text

A B C Geo-replicated for both fault-tolerance and high-availability. [Photo: http://vignette3.wikia.nocookie.net/the-titans-rp-and-information/images/f/f5/Blank-World-map2.gif/revision/latest/scale-to-width-down/1280?cb=20141016203452]

Slide 10

Slide 10 text

A B C Clients read and write locally for low-latency. [Photo: http://vignette3.wikia.nocookie.net/the-titans-rp-and-information/images/f/f5/Blank-World-map2.gif/revision/latest/scale-to-width-down/1280?cb=20141016203452]

Slide 11

Slide 11 text

A B C What happens if C can’t communicate with other replicas? [Photo: http://vignette3.wikia.nocookie.net/the-titans-rp-and-information/images/f/f5/Blank-World-map2.gif/revision/latest/scale-to-width-down/1280?cb=20141016203452]

Slide 12

Slide 12 text

A B C Choice 1: Consistent-Under-Partition (CP) • Synchronize each operation
 Maintains “single system image” [Photo: http://vignette3.wikia.nocookie.net/the-titans-rp-and-information/images/f/f5/Blank-World-map2.gif/revision/latest/scale-to-width-down/1280?cb=20141016203452]

Slide 13

Slide 13 text

A B C Choice 1: Consistent-Under-Partition (CP) • Synchronize each operation
 Maintains “single system image” • Spanner/F1, serializability model
 Coordination is expensive; Spanner typically has to wait 100ms to commit an update transaction [Photo: http://vignette3.wikia.nocookie.net/the-titans-rp-and-information/images/f/f5/Blank-World-map2.gif/revision/latest/scale-to-width-down/1280?cb=20141016203452]

Slide 14

Slide 14 text

A B C Choice 1: Consistent-Under-Partition (CP) • Synchronize each operation
 Maintains “single system image” • Spanner/F1, serializability model
 Coordination is expensive; Spanner typically has to wait 100ms to commit an update transaction Over-conservative, but easy to program! [Photo: http://vignette3.wikia.nocookie.net/the-titans-rp-and-information/images/f/f5/Blank-World-map2.gif/revision/latest/scale-to-width-down/1280?cb=20141016203452]

Slide 15

Slide 15 text

A B C Choice 2: Available-Under-Partition (AP) • Riak, Cassandra, Dynamo
 Operations issued against local copy, and across the cluster in parallel [Photo: http://vignette3.wikia.nocookie.net/the-titans-rp-and-information/images/f/f5/Blank-World-map2.gif/revision/latest/scale-to-width-down/1280?cb=20141016203452]

Slide 16

Slide 16 text

A B C Choice 2: Available-Under-Partition (AP) • Riak, Cassandra, Dynamo
 Operations issued against local copy, and across the cluster in parallel • Local operation only, asynchronous propagation
 Stale reads and write conflicts will occur without synchronization [Photo: http://vignette3.wikia.nocookie.net/the-titans-rp-and-information/images/f/f5/Blank-World-map2.gif/revision/latest/scale-to-width-down/1280?cb=20141016203452]

Slide 17

Slide 17 text

A B C Choice 2: Available-Under-Partition (AP) • Riak, Cassandra, Dynamo
 Operations issued against local copy, and across the cluster in parallel • Local operation only, asynchronous propagation
 Stale reads and write conflicts will occur without synchronization Available, but difficult to program! [Photo: http://vignette3.wikia.nocookie.net/the-titans-rp-and-information/images/f/f5/Blank-World-map2.gif/revision/latest/scale-to-width-down/1280?cb=20141016203452]

Slide 18

Slide 18 text

A B C CAP Theorem CP AP [Photo: http://vignette3.wikia.nocookie.net/the-titans-rp-and-information/images/f/f5/Blank-World-map2.gif/revision/latest/scale-to-width-down/1280?cb=20141016203452]

Slide 19

Slide 19 text

A B C CAP Theorem High cost CP AP [Photo: http://vignette3.wikia.nocookie.net/the-titans-rp-and-information/images/f/f5/Blank-World-map2.gif/revision/latest/scale-to-width-down/1280?cb=20141016203452]

Slide 20

Slide 20 text

A B C CAP Theorem High cost Low availability CP AP [Photo: http://vignette3.wikia.nocookie.net/the-titans-rp-and-information/images/f/f5/Blank-World-map2.gif/revision/latest/scale-to-width-down/1280?cb=20141016203452]

Slide 21

Slide 21 text

A B C CAP Theorem High cost Low availability Synchronization CP AP [Photo: http://vignette3.wikia.nocookie.net/the-titans-rp-and-information/images/f/f5/Blank-World-map2.gif/revision/latest/scale-to-width-down/1280?cb=20141016203452]

Slide 22

Slide 22 text

A B C CAP Theorem High cost Low availability Synchronization Low cost CP AP [Photo: http://vignette3.wikia.nocookie.net/the-titans-rp-and-information/images/f/f5/Blank-World-map2.gif/revision/latest/scale-to-width-down/1280?cb=20141016203452]

Slide 23

Slide 23 text

A B C CAP Theorem High cost Low availability Synchronization Low cost High availability CP AP [Photo: http://vignette3.wikia.nocookie.net/the-titans-rp-and-information/images/f/f5/Blank-World-map2.gif/revision/latest/scale-to-width-down/1280?cb=20141016203452]

Slide 24

Slide 24 text

A B C CAP Theorem High cost Low availability Synchronization Low cost High availability Anomalies CP AP [Photo: http://vignette3.wikia.nocookie.net/the-titans-rp-and-information/images/f/f5/Blank-World-map2.gif/revision/latest/scale-to-width-down/1280?cb=20141016203452]

Slide 25

Slide 25 text

A B C CAP Theorem High cost Low availability Synchronization Low cost High availability Anomalies CP AP False dichotomy! [Photo: http://vignette3.wikia.nocookie.net/the-titans-rp-and-information/images/f/f5/Blank-World-map2.gif/revision/latest/scale-to-width-down/1280?cb=20141016203452]

Slide 26

Slide 26 text

A B C CAP Theorem High cost Low availability Synchronization Low cost High availability Anomalies CP AP False dichotomy! [Photo: http://vignette3.wikia.nocookie.net/the-titans-rp-and-information/images/f/f5/Blank-World-map2.gif/revision/latest/scale-to-width-down/1280?cb=20141016203452] • No “one-size-fits-all” consistency model
 Choosing either model will either be over-conservative or risk anomalies

Slide 27

Slide 27 text

A B C CAP Theorem High cost Low availability Synchronization Low cost High availability Anomalies CP AP False dichotomy! [Photo: http://vignette3.wikia.nocookie.net/the-titans-rp-and-information/images/f/f5/Blank-World-map2.gif/revision/latest/scale-to-width-down/1280?cb=20141016203452] • No “one-size-fits-all” consistency model
 Choosing either model will either be over-conservative or risk anomalies • Application-level invariants
 Instead, tailor consistency choices based on application- level invariants for each operation

Slide 28

Slide 28 text

Just Right Consistency • Preserve sequential patterns
 Applications written sequentially that are correct should maintain correctness under concurrency 13

Slide 29

Slide 29 text

Just Right Consistency • Preserve sequential patterns
 Applications written sequentially that are correct should maintain correctness under concurrency • AP-compatible invariants
 Strongest AP model; invariants that only require “one way” communications 13

Slide 30

Slide 30 text

Just Right Consistency • Preserve sequential patterns
 Applications written sequentially that are correct should maintain correctness under concurrency • AP-compatible invariants
 Strongest AP model; invariants that only require “one way” communications • CAP-sensitive invariants
 Transactions that require coordination; “two way” communication invariants 13

Slide 31

Slide 31 text

Just Right Consistency • Preserve sequential patterns
 Applications written sequentially that are correct should maintain correctness under concurrency • AP-compatible invariants
 Strongest AP model; invariants that only require “one way” communications • CAP-sensitive invariants
 Transactions that require coordination; “two way” communication invariants • Tools for analysis and verification
 Identify and verify application has sufficient synchronization to ensure application invariants 13

Slide 32

Slide 32 text

Example Fælles Medicinkort 14

Slide 33

Slide 33 text

Fælles Medicinkort • FMK [production] / FMKe [synthetic workload]
 Danish National Joint Medicine Card; operating 24x7 since 2013 for 6 million Danish citizens 15

Slide 34

Slide 34 text

Fælles Medicinkort • FMK [production] / FMKe [synthetic workload]
 Danish National Joint Medicine Card; operating 24x7 since 2013 for 6 million Danish citizens • Lifecycle management for prescriptions
 Involves patient, pharmacy, and doctor management around active prescriptions in Denmark 15

Slide 35

Slide 35 text

Fælles Medicinkort • FMK [production] / FMKe [synthetic workload]
 Danish National Joint Medicine Card; operating 24x7 since 2013 for 6 million Danish citizens • Lifecycle management for prescriptions
 Involves patient, pharmacy, and doctor management around active prescriptions in Denmark • Assumed correct in isolation
 “Correct-Individually”, C in ACID, each operation ensures application-level invariants 15

Slide 36

Slide 36 text

Fælles Medicinkort • FMK [production] / FMKe [synthetic workload]
 Danish National Joint Medicine Card; operating 24x7 since 2013 for 6 million Danish citizens • Lifecycle management for prescriptions
 Involves patient, pharmacy, and doctor management around active prescriptions in Denmark • Assumed correct in isolation
 “Correct-Individually”, C in ACID, each operation ensures application-level invariants 15 • create-prescription
 Create prescription for patient, doctor, pharmacy • update-prescription-medication
 Add or increase medication to prescription • process-prescription
 Deliver a medication by a pharmacy • get-*-prescriptions
 Query functions to return information about prescriptions

Slide 37

Slide 37 text

FMKe Invariants • Relative order [secondary indexes]
 Create a prescription and reference it by a patient 16

Slide 38

Slide 38 text

FMKe Invariants • Relative order [secondary indexes]
 Create a prescription and reference it by a patient • Joint update [atomicity]
 Create prescription, then update doctor, patient, and pharmacy 16

Slide 39

Slide 39 text

FMKe Invariants • Relative order [secondary indexes]
 Create a prescription and reference it by a patient • Joint update [atomicity]
 Create prescription, then update doctor, patient, and pharmacy • Precondition check [if, then]
 Medication should not be over delivered 16

Slide 40

Slide 40 text

Invariants AP-compatible 17

Slide 41

Slide 41 text

AP-compatible • No synchronization
 Updates occur locally without blocking, no synchronization in the critical path 18

Slide 42

Slide 42 text

AP-compatible • No synchronization
 Updates occur locally without blocking, no synchronization in the critical path • Asynchronous operation
 Updates are fast, available, and exploit concurrency 18

Slide 43

Slide 43 text

AP-compatible • No synchronization
 Updates occur locally without blocking, no synchronization in the critical path • Asynchronous operation
 Updates are fast, available, and exploit concurrency • Compatible invariants
 Relative order and joint update invariants can be preserved 18

Slide 44

Slide 44 text

AP-compatible Data Model 19

Slide 45

Slide 45 text

RA RB

Slide 46

Slide 46 text

RA RB 1 set(1)

Slide 47

Slide 47 text

RA RB 1 set(1) 3 2 set(2) set(3)

Slide 48

Slide 48 text

RA RB 1 set(1) 3 2 set(2) set(3) 2 3 Concurrent assignments don’t commute!

Slide 49

Slide 49 text

RA RB 1 set(1) 3 2 set(2) set(3) 2 3 Concurrent assignments don’t commute! Assignment requires CP.

Slide 50

Slide 50 text

24 Can we find a suitable data model for AP systems?

Slide 51

Slide 51 text

Can we make non-commutative updates commutative? 24 Can we find a suitable data model for AP systems?

Slide 52

Slide 52 text

RA RB 1 set(1) 3 2 set(2) set(3) ? ? How do we deterministically pick a value to keep?

Slide 53

Slide 53 text

RA RB 1 set(1) 3 2 set(2) set(3) ? ? How do we deterministically pick a value to keep? Do we use a timestamp? (like Cassandra, and drop a value?)

Slide 54

Slide 54 text

RA RB 1 set(1) 3 2 set(2) set(3) ? ? How do we deterministically pick a value to keep? Do we use a timestamp? (like Cassandra, and drop a value?) Timestamps make concurrent operations commute but fail to capture intent.

Slide 55

Slide 55 text

Can we be smarter about the merge function? 26

Slide 56

Slide 56 text

RA RB 1 set(1) 3 2 set(2) set(3) 3 3 max(2,3) max(2,3) Deterministic conflict resolution function.

Slide 57

Slide 57 text

RA RB 1 set(1) 3 2 set(2) set(3) 3 3 max(2,3) max(2,3) Deterministic conflict resolution function. CRDTs generalize this framework.

Slide 58

Slide 58 text

Conflict-Free 
 Replicated Data Types • Replicated abstract data types
 Extension of sequential data type that encapsulates deterministic merge function 28

Slide 59

Slide 59 text

Conflict-Free 
 Replicated Data Types • Replicated abstract data types
 Extension of sequential data type that encapsulates deterministic merge function • Many existing designs
 Sets, counters, registers, flags, maps 28

Slide 60

Slide 60 text

AP-compatible Relative Order 29

Slide 61

Slide 61 text

RA RB

Slide 62

Slide 62 text

RA RB Maintain program order implication invariant.

Slide 63

Slide 63 text

RA RB Maintain program order implication invariant. For instance, P => Q.

Slide 64

Slide 64 text

RA RB Q true(Q) Make Q true.

Slide 65

Slide 65 text

RA RB Q true(Q) P true(P) Make P true.

Slide 66

Slide 66 text

RA RB Q true(Q) P true(P) Program order implies ordering relationship.

Slide 67

Slide 67 text

RA RB Q true(Q) P true(P) Ordering is respected at other replicas.

Slide 68

Slide 68 text

RA RB Q true(Q) P true(P) Out of order propagation violates invariant!

Slide 69

Slide 69 text

RA RB Q true(Q) P true(P) P is true, Q is NOT true!

Slide 70

Slide 70 text

Let’s look at a concrete example. 37

Slide 71

Slide 71 text

RA RB

Slide 72

Slide 72 text

RA RB Q true(Q) Change default administrator password.

Slide 73

Slide 73 text

RA RB Q true(Q) P true(P) Enable administrator login.

Slide 74

Slide 74 text

RA RB Q true(Q) P true(P) Replica A is secure.

Slide 75

Slide 75 text

RA RB Q true(Q) P true(P) Replica B is secure.

Slide 76

Slide 76 text

RA RB Q true(Q) P true(P) Reordering allows default password to be used to login!

Slide 77

Slide 77 text

Causal Consistency • Respect causality
 Ensure updates are delivered in the causal order 44

Slide 78

Slide 78 text

Causal Consistency • Respect causality
 Ensure updates are delivered in the causal order • Strongest available AP model
 Always able to return some compatible version for an object 44

Slide 79

Slide 79 text

Causal Consistency • Respect causality
 Ensure updates are delivered in the causal order • Strongest available AP model
 Always able to return some compatible version for an object • Secondary indexing
 Causal consistency is sufficient for providing secondary indexing in an AP database 44

Slide 80

Slide 80 text

…relative order invariants are preserved transparently! 45 Causal consistency means…

Slide 81

Slide 81 text

AP-compatibe Joint Update 46

Slide 82

Slide 82 text

RA RB C1 Client performing reads.

Slide 83

Slide 83 text

RA RB C1 Rx create Rx Create prescription.

Slide 84

Slide 84 text

RA RB C1 Rx create Rx Dr update Dr(Rx) Add reference in doctor record.

Slide 85

Slide 85 text

RA RB C1 Rx create Rx Dr update Dr(Rx) Pt update Pt(Rx) Add reference in patient record.

Slide 86

Slide 86 text

RA RB C1 Rx create Rx Dr update Dr(Rx) Pt update Pt(Rx) Ph update Ph(Rx) Add reference in pharmacy record.

Slide 87

Slide 87 text

RA RB C1 Rx create Rx Dr update Dr(Rx) Pt update Pt(Rx) Ph update Ph(Rx) Updates are causally consistent.

Slide 88

Slide 88 text

RA RB C1 Rx create Rx Dr update Dr(Rx) Pt update Pt(Rx) Ph update Ph(Rx) Client can read inconsistent state.

Slide 89

Slide 89 text

RA RB C1 Rx create Rx Dr update Dr(Rx) Pt update Pt(Rx) Ph update Ph(Rx) Client is missing update to pharmacy.

Slide 90

Slide 90 text

Can we ensure updates are All-or-Nothing? 55

Slide 91

Slide 91 text

RA RB C1 T1 create Rx update Dr(Rx) update Pt(Rx) update Ph(Rx) Group updates into an atomic transaction.

Slide 92

Slide 92 text

RA RB C1 T1 create Rx update Dr(Rx) update Pt(Rx) update Ph(Rx) Updates reflect “All-Or-Nothing” property through snapshots.

Slide 93

Slide 93 text

RA RB C1 T1 create Rx update Dr(Rx) update Pt(Rx) update Ph(Rx) T2 Transactions are delivered in causal order.

Slide 94

Slide 94 text

RA RB C1 T1 create Rx update Dr(Rx) update Pt(Rx) update Ph(Rx) T2 Therefore, snapshots are causally consistent.

Slide 95

Slide 95 text

AP-compatible transactions provide the “A” in ACID 60

Slide 96

Slide 96 text

Transactional Causal Consistency 61 Strongest model that is available (AP)

Slide 97

Slide 97 text

Invariants CAP-sensitive 62

Slide 98

Slide 98 text

What about preventing over delivery of prescriptions? 63

Slide 99

Slide 99 text

RA(2) RB(2) ? ? RC(2) ? Three replicas each with two available medications.

Slide 100

Slide 100 text

RA(2) RB(2) 1 1 1 pp(1) RC(2) 1 Replica A checks precondition and delivers medication.

Slide 101

Slide 101 text

RA(2) RB(2) 1 1 1 pp(1) RC(2) 1 Correct outcome where one medication remains.

Slide 102

Slide 102 text

Is this safe with concurrent operations? 67

Slide 103

Slide 103 text

RA(2) RB(2) ? ? RC(2) ? Three replicas each with two available medications.

Slide 104

Slide 104 text

RA(2) RB(2) 4 4 1 pp(1) RC(2) 4 4 add(3) Replica A checks precondition and delivers medication.

Slide 105

Slide 105 text

RA(2) RB(2) 4 4 1 pp(1) RC(2) 4 4 add(3) Replica C adds three medications to the prescription.

Slide 106

Slide 106 text

RA(2) RB(2) 4 4 1 pp(1) RC(2) 4 4 add(3) Correct outcome with four remaining medications.

Slide 107

Slide 107 text

RA(2) RB(2) 4 4 1 pp(1) RC(2) 4 4 add(3) Correct outcome with four remaining medications. Precondition is stable under concurrent addition.

Slide 108

Slide 108 text

Is this safe with concurrent deliveries? 72

Slide 109

Slide 109 text

RA(2) RB(2) ? ? RC(2) ? Three replicas each with two available medications.

Slide 110

Slide 110 text

RA(2) RB(2) -1 -1 1 pp(1) RC(2) -1 0 pp(2) Replica A checks precondition and delivers medication.

Slide 111

Slide 111 text

RA(2) RB(2) -1 -1 1 pp(1) RC(2) -1 0 pp(2) Replica C concurrently checks precondition and delivers two medications.

Slide 112

Slide 112 text

RA(2) RB(2) -1 -1 1 pp(1) RC(2) -1 0 pp(2) Incorrect outcome violating non-negative invariant.

Slide 113

Slide 113 text

RA(2) RB(2) -1 -1 1 pp(1) RC(2) -1 0 pp(2) Incorrect outcome violating non-negative invariant. Precondition is NOT stable under concurrent fulfillment.

Slide 114

Slide 114 text

RA(2) RB(2) -1 -1 1 pp(1) RC(2) -1 0 pp(2) Incorrect outcome violating non-negative invariant. Precondition is NOT stable under concurrent fulfillment. • Forbid concurrency
 Prevent operations from proceeding without synchronization to enforce invariant • Allow concurrency and remove invariant
 Allow operation to proceed, knowing that the invariant may be violated under concurrent operations

Slide 115

Slide 115 text

How do we know when it’s safe? 77

Slide 116

Slide 116 text

CISE Analysis 78

Slide 117

Slide 117 text

RA RB I? I? ? Upre? RC I? ? Vpre? Analyze possible pairs of concurrent operations…

Slide 118

Slide 118 text

RA RB I? I? ? Upre? RC I? ? Vpre? …to identify operations where the invariant can be violated.

Slide 119

Slide 119 text

CISE Analysis • Individually correct
 Individual operations never violate the invariant 81

Slide 120

Slide 120 text

CISE Analysis • Individually correct
 Individual operations never violate the invariant • Convergence
 Concurrent effects commute 81

Slide 121

Slide 121 text

CISE Analysis • Individually correct
 Individual operations never violate the invariant • Convergence
 Concurrent effects commute • Precondition stability
 Preconditions are stable under every pair of concurrent operations 81

Slide 122

Slide 122 text

CISE Analysis • Individually correct
 Individual operations never violate the invariant • Convergence
 Concurrent effects commute • Precondition stability
 Preconditions are stable under every pair of concurrent operations 81 If satisfied, invariant is guaranteed with concurrency.

Slide 123

Slide 123 text

Database AntidoteDB 82

Slide 124

Slide 124 text

AntidoteDB • Open-source Erlang database
 Developed in Erlang, on top of the Riak Core distributed systems framework 83

Slide 125

Slide 125 text

AntidoteDB • Open-source Erlang database
 Developed in Erlang, on top of the Riak Core distributed systems framework • Transactional Causal Consistency
 Only industrial-grade database providing both causal consistency and all-or-nothing transactions 83

Slide 126

Slide 126 text

AntidoteDB • Open-source Erlang database
 Developed in Erlang, on top of the Riak Core distributed systems framework • Transactional Causal Consistency
 Only industrial-grade database providing both causal consistency and all-or-nothing transactions • Alpha release available
 Currently under development, but an alpha release of the product is available on GitHub 83

Slide 127

Slide 127 text

A B N1 N2 TxnMgr Materializer Log InterDC-Repl Each data center…

Slide 128

Slide 128 text

A B N1 N2 TxnMgr Materializer Log InterDC-Repl …contains multiple nodes…

Slide 129

Slide 129 text

A B N1 N2 TxnMgr Materializer Log InterDC-Repl …each operating a transaction manager, materializers, log.

Slide 130

Slide 130 text

A B N1 N2 TxnMgr Materializer Log InterDC-Repl Strong consistency inside of the data center…

Slide 131

Slide 131 text

A B N1 N2 TxnMgr Materializer Log InterDC-Repl …with a causal consistency protocol running in the wide area.

Slide 132

Slide 132 text

Data Model 89 Register • Last-Writer Wins • Multi-Value Set • Grow-Only • Add-Wins • Remove-Wins Map Counter • Unlimited • Restricted ≥ 0 Graph • Directed • Monotonic DAG • Edit graph Sequence

Slide 133

Slide 133 text

Object API 90 User1 = {michel, antidote_crdt_mvreg, user_bucket}, {ok, Time2} = antidote:update_objects(ignore, [], [{User1, assign, {["Michel", “michel@blub.org”], ClientIdentifier}}]), {ok, Result, Time2} = antidote:read_objects( ignore, [], [User1]).

Slide 134

Slide 134 text

Object API 91 User1 = {michel, antidote_crdt_mvreg, user_bucket}, {ok, Time2} = antidote:update_objects(ignore, [], [{User1, assign, {["Michel", “michel@blub.org”], ClientIdentifier}}]), {ok, Result, Time2} = antidote:read_objects( ignore, [], [User1]). Identify an object by object identifier.

Slide 135

Slide 135 text

Object API 92 User1 = {michel, antidote_crdt_mvreg, user_bucket}, {ok, Time2} = antidote:update_objects(ignore, [], [{User1, assign, {["Michel", “michel@blub.org”], ClientIdentifier}}]), {ok, Result, Time2} = antidote:read_objects( ignore, [], [User1]). Use the update API to assign a value to this register.

Slide 136

Slide 136 text

Object API 93 User1 = {michel, antidote_crdt_mvreg, user_bucket}, {ok, Time2} = antidote:update_objects(ignore, [], [{User1, assign, {["Michel", “michel@blub.org”], ClientIdentifier}}]), {ok, Result, Time2} = antidote:read_objects( ignore, [], [User1]). Read the object, providing a minimum snapshot time.

Slide 137

Slide 137 text

Object API 93 User1 = {michel, antidote_crdt_mvreg, user_bucket}, {ok, Time2} = antidote:update_objects(ignore, [], [{User1, assign, {["Michel", “michel@blub.org”], ClientIdentifier}}]), {ok, Result, Time2} = antidote:read_objects( ignore, [], [User1]). Read the object, providing a minimum snapshot time. Simple, operation-based API. (think Redis, Riak CRDTs)

Slide 138

Slide 138 text

Object API 93 User1 = {michel, antidote_crdt_mvreg, user_bucket}, {ok, Time2} = antidote:update_objects(ignore, [], [{User1, assign, {["Michel", “michel@blub.org”], ClientIdentifier}}]), {ok, Result, Time2} = antidote:read_objects( ignore, [], [User1]). Read the object, providing a minimum snapshot time. Simple, operation-based API. (think Redis, Riak CRDTs) Causal dependencies are automatically captured by execution order.

Slide 139

Slide 139 text

Transaction API 94 {ok, TxId} = antidote:start_transaction(Timestamp, []), {ok, _} = antidote:read_objects([Set], TxId), ok = antidote:update_objects([{Set, add, "Java"}], TxId), {ok, _} = antidote:commit_transaction(TxId).

Slide 140

Slide 140 text

Transaction API 95 Start a transaction with the transaction API, with a given snapshot time and return a transaction identifier. {ok, TxId} = antidote:start_transaction(Timestamp, []), {ok, _} = antidote:read_objects([Set], TxId), ok = antidote:update_objects([{Set, add, "Java"}], TxId), {ok, _} = antidote:commit_transaction(TxId).

Slide 141

Slide 141 text

{ok, TxId} = antidote:start_transaction(Timestamp, []), {ok, _} = antidote:read_objects([Set], TxId), ok = antidote:update_objects([{Set, add, "Java"}], TxId), {ok, _} = antidote:commit_transaction(TxId). Transaction API 96 Read objects using the interactive transaction API.

Slide 142

Slide 142 text

{ok, TxId} = antidote:start_transaction(Timestamp, []), {ok, _} = antidote:read_objects([Set], TxId), ok = antidote:update_objects([{Set, add, "Java"}], TxId), {ok, _} = antidote:commit_transaction(TxId). Transaction API 97 Update objects using the interactive transaction API.

Slide 143

Slide 143 text

{ok, TxId} = antidote:start_transaction(Timestamp, []), {ok, _} = antidote:read_objects([Set], TxId), ok = antidote:update_objects([{Set, add, "Java"}], TxId), {ok, _} = antidote:commit_transaction(TxId). Transaction API 98 Once finished updating, commit the transaction.

Slide 144

Slide 144 text

{ok, TxId} = antidote:start_transaction(Timestamp, []), {ok, _} = antidote:read_objects([Set], TxId), ok = antidote:update_objects([{Set, add, "Java"}], TxId), {ok, _} = antidote:commit_transaction(TxId). Transaction API 98 Once finished updating, commit the transaction. Transactions read causally consistent snapshots and updates are applied atomically.

Slide 145

Slide 145 text

Scalability 99 Kops / s 100 200 300 400 500 600 700 800 1 x 5 1 x 10 1 x 25 2 x 25 3 x 25 1 x 5 1 x 10 1 x 25 2 x 25 3 x 25 1 x 5 1 x 10 1 x 25 2 x 25 3 x 25 1 x 5 1 x 10 1 x 25 2 x 25 3 x 25 99(1) 90(10) 75(25) 50(50) read(update) ratio DCs × Servers LWW registers 100k keys/partition power law distribution

Slide 146

Slide 146 text

Cure vs. SOA 100 Kops / s 0 100 200 300 400 500 600 700 800 900 1000 1100 Eiger GR Cure EC Eiger GR Cure EC Eiger GR Cure EC Eiger GR Cure EC 99(1) 90(10) 75(25) 50(50) read(update) ratio 3 DCs × 25 Servers LWW registers

Slide 147

Slide 147 text

Cure vs. EC 101 Kops / s 100 200 300 400 500 600 700 800 900 1000 1100 1200 Cure, 1KB EC, 1KB Cure, 10KB EC, 10KB Cure, 1KB EC, 1KB Cure, 10KB EC, 10KB Cure, 1KB EC, 1KB Cure, 10KB EC, 10KB Cure, 1KB EC, 1KB Cure, 10KB EC, 10KB 99(1) 90(10) 75(25) 50(50) read(update) ratio 3 DCs x 25 Servers CRDT sets

Slide 148

Slide 148 text

Future Features • Intra-DC replication
 Antidote provides no replication within the datacenter and assumes only geo- replication at the moment 102

Slide 149

Slide 149 text

Future Features • Intra-DC replication
 Antidote provides no replication within the datacenter and assumes only geo- replication at the moment • ACID transactions
 For Antidote to provide all of JRC, it needs ACID transaction support: no research needed, only implementation 102

Slide 150

Slide 150 text

Moving Forward • Research prototype
 Originally a research prototype to build a database requiring reduced synchronization (SyncFree FP7) with Basho, Rovio, and Trifork 103

Slide 151

Slide 151 text

Moving Forward • Research prototype
 Originally a research prototype to build a database requiring reduced synchronization (SyncFree FP7) with Basho, Rovio, and Trifork • Research ahead
 LightKone (H2020) will investigate moving AntidoteDB close to the edge to provide DDN services 103

Slide 152

Slide 152 text

Moving Forward • Research prototype
 Originally a research prototype to build a database requiring reduced synchronization (SyncFree FP7) with Basho, Rovio, and Trifork • Research ahead
 LightKone (H2020) will investigate moving AntidoteDB close to the edge to provide DDN services • Industrialization
 Obtaining seed funding to start a company to industrialize AntidoteDB 103

Slide 153

Slide 153 text

Resources • https://github.com/SyncFree/antidote
 AntidoteDB 104

Slide 154

Slide 154 text

Resources • https://github.com/SyncFree/antidote
 AntidoteDB • http://syncfree.github.io/antidote/
 Documentation for AntidoteDB 104

Slide 155

Slide 155 text

Resources • https://github.com/SyncFree/antidote
 AntidoteDB • http://syncfree.github.io/antidote/
 Documentation for AntidoteDB • www.antidotedb.com
 Website 104

Slide 156

Slide 156 text

Resources • https://github.com/SyncFree/antidote
 AntidoteDB • http://syncfree.github.io/antidote/
 Documentation for AntidoteDB • www.antidotedb.com
 Website • docker pull antidotedb/antidote
 Try out Antidote! 104

Slide 157

Slide 157 text

Thanks! 105 Questions?