Slide 1

Slide 1 text

Papers We Love SF: Bayou Peter Bailis @pbailis UC Berkeley 17 December 2014

Slide 2

Slide 2 text

Who am I? Ph.D. candidate, 4th year student at Berkeley Study high performance distributed databases » When do we need coordination? » What happens if we don’t coordinate? Graduating 2015! http://bailis.org/

Slide 3

Slide 3 text

No content

Slide 4

Slide 4 text

Why Bayou? “NoSQL” before “NoSQL” Learn from our predecessors Rethink application, system boundaries Lucid discussion of systems challenges

Slide 5

Slide 5 text

Talk Outline Background and system architecture Conflict detection and resolution APIs “Correctness” and ordering Lessons for all of us

Slide 6

Slide 6 text

Talk Outline Background and system architecture Conflict detection and resolution APIs “Correctness” and ordering Lessons for all of us

Slide 7

Slide 7 text

No content

Slide 8

Slide 8 text

Bayou Goals Storage system for mobile devices:

Slide 9

Slide 9 text

Bayou Goals Storage system for mobile devices: Handle frequent disconnections

Slide 10

Slide 10 text

No content

Slide 11

Slide 11 text

No content

Slide 12

Slide 12 text

No content

Slide 13

Slide 13 text

Bayou Goals Storage system for mobile devices: Handle frequent disconnections

Slide 14

Slide 14 text

Bayou Goals Storage system for mobile devices: Handle frequent disconnections Reason about distribution explicitly

Slide 15

Slide 15 text

No content

Slide 16

Slide 16 text

Bayou Goals Storage system for mobile devices: Handle frequent disconnections Reason about distribution explicitly

Slide 17

Slide 17 text

Bayou Goals Storage system for mobile devices: Handle frequent disconnections Reason about distribution explicitly Facilitate conflict detection and resolution

Slide 18

Slide 18 text

How do we build a system that allows update- anywhere but allows users to easily build correct applications?

Slide 19

Slide 19 text

No content

Slide 20

Slide 20 text

Basic Architecture

Slide 21

Slide 21 text

Basic Architecture Optimistically replicated distributed database

Slide 22

Slide 22 text

No content

Slide 23

Slide 23 text

Basic Architecture Optimistically replicated distributed database Update-anywhere; CAP “AP” » Guarantees availability » Low latency and scalability! Use anti-entropy to exchange updates » Pick your favorite

Slide 24

Slide 24 text

No content

Slide 25

Slide 25 text

Talk Outline Background and system architecture Conflict detection and resolution APIs “Correctness” and ordering Lessons for all of us

Slide 26

Slide 26 text

Talk Outline Background and system architecture Conflict detection and resolution APIs “Correctness” and ordering Lessons for all of us

Slide 27

Slide 27 text

Main problem: “conflicts” What happens if two clients simultaneously update the same piece of data?

Slide 28

Slide 28 text

Example: Peter wants to book Fastly HQ on 12/17 at 7PM Ines wants to book Fastly HQ on 12/17 at 7PM

Slide 29

Slide 29 text

Example: Peter wants to book Fastly HQ on 12/17 at 7PM Ines wants to book Fastly HQ on 12/17 at 7PM Peter and Ines are connected to different servers

Slide 30

Slide 30 text

Example: Peter wants to book Fastly HQ on 12/17 at 7PM Ines wants to book Fastly HQ on 12/17 at 7PM Peter and Ines are connected to different servers What will happen?

Slide 31

Slide 31 text

Example: Peter wants to book Fastly HQ on 12/17 at 7PM Ines wants to book Fastly HQ on 12/17 at 7PM Peter and Ines are connected to different servers What will happen? Example:

Slide 32

Slide 32 text

Example: Peter wants to book Fastly HQ on 12/17 at 7PM Ines wants to book Fastly HQ on 12/17 at 7PM Peter and Ines are connected to different servers What will happen? Example: Mike wants to give Peter $100 Carol wants to give Peter $100

Slide 33

Slide 33 text

Example: Peter wants to book Fastly HQ on 12/17 at 7PM Ines wants to book Fastly HQ on 12/17 at 7PM Peter and Ines are connected to different servers What will happen? Example: Mike wants to give Peter $100 Carol wants to give Peter $100 Mike and Carol are connected to different servers

Slide 34

Slide 34 text

Example: Peter wants to book Fastly HQ on 12/17 at 7PM Ines wants to book Fastly HQ on 12/17 at 7PM Peter and Ines are connected to different servers What will happen? Example: Mike wants to give Peter $100 Carol wants to give Peter $100 Mike and Carol are connected to different servers What will happen?

Slide 35

Slide 35 text

Main problem: “conflicts” What happens if two clients simultaneously update the same piece of data?

Slide 36

Slide 36 text

Main problem: “conflicts” It depends on the application! What happens if two clients simultaneously update the same piece of data?

Slide 37

Slide 37 text

Main problem: “conflicts” It depends on the application! Traditional DB (“serializability”): always* matters! What happens if two clients simultaneously update the same piece of data?

Slide 38

Slide 38 text

Main problem: “conflicts” It depends on the application! Traditional DB (“serializability”): always* matters! Bayou: let the application help us out! What happens if two clients simultaneously update the same piece of data?

Slide 39

Slide 39 text

Main problem: “conflicts” Bayou writes have three components:

Slide 40

Slide 40 text

Main problem: “conflicts” Bayou writes have three components: » An update function: the actual write

Slide 41

Slide 41 text

Main problem: “conflicts” Bayou writes have three components: » An update function: the actual write » A dependency check: conflict detection

Slide 42

Slide 42 text

Main problem: “conflicts” Bayou writes have three components: » An update function: the actual write » A dependency check: conflict detection » A merge function: conflict compensation

Slide 43

Slide 43 text

Main problem: “conflicts” Bayou writes have three components: » An update function: the actual write » A dependency check: conflict detection » A merge function: conflict compensation If dependency check passes: apply update function Else: apply merge function

Slide 44

Slide 44 text

Example: Booking tonight’s meetup:

Slide 45

Slide 45 text

Example: Booking tonight’s meetup: » Update function: insert 12/17/14, “Fastly HQ”, Ines

Slide 46

Slide 46 text

Example: Booking tonight’s meetup: » Update function: insert 12/17/14, “Fastly HQ”, Ines » Dependency check: Is the requested time and location available?

Slide 47

Slide 47 text

Example: Booking tonight’s meetup: » Update function: insert 12/17/14, “Fastly HQ”, Ines » Dependency check: Is the requested time and location available? » Merge function: try to find another time based on provided alternates

Slide 48

Slide 48 text

No content

Slide 49

Slide 49 text

No content

Slide 50

Slide 50 text

No content

Slide 51

Slide 51 text

No content

Slide 52

Slide 52 text

Inside the server: Date Location User Time 12/16 Fastly HQ Fred 2:30-5PM 12/18 Fastly HQ Artur 10AM-12PM 12/17 FastlyHQ Inez 6:30-9PM

Slide 53

Slide 53 text

Inside the server: Date Location User Time 12/16 Fastly HQ Fred 2:30-5PM 12/18 Fastly HQ Artur 10AM-12PM 12/17 FastlyHQ Inez 6:30-9PM

Slide 54

Slide 54 text

Inside the server: Date Location User Time 12/16 Fastly HQ Fred 2:30-5PM 12/18 Fastly HQ Artur 10AM-12PM 12/17 FastlyHQ Inez 6:30-9PM Update function: insert 12/17/14, “Fastly HQ”, Ines

Slide 55

Slide 55 text

Inside the server: Date Location User Time 12/16 Fastly HQ Fred 2:30-5PM 12/18 Fastly HQ Artur 10AM-12PM 12/17 FastlyHQ Inez 6:30-9PM Update function: insert 12/17/14, “Fastly HQ”, Ines Dependency check: Is the requested time and location available?

Slide 56

Slide 56 text

Inside the server: Date Location User Time 12/16 Fastly HQ Fred 2:30-5PM 12/18 Fastly HQ Artur 10AM-12PM 12/17 FastlyHQ Inez 6:30-9PM Update function: insert 12/17/14, “Fastly HQ”, Ines Dependency check: Is the requested time and location available?

Slide 57

Slide 57 text

No content

Slide 58

Slide 58 text

No content

Slide 59

Slide 59 text

No content

Slide 60

Slide 60 text

No content

Slide 61

Slide 61 text

No content

Slide 62

Slide 62 text

No content

Slide 63

Slide 63 text

No content

Slide 64

Slide 64 text

No content

Slide 65

Slide 65 text

No content

Slide 66

Slide 66 text

Another example: Money transfer:

Slide 67

Slide 67 text

Another example: Money transfer: » Update function: transfer $100 from Jan to Mary

Slide 68

Slide 68 text

Another example: Money transfer: » Update function: transfer $100 from Jan to Mary » Dependency check: does Jan have $100 in her account?

Slide 69

Slide 69 text

Another example: Money transfer: » Update function: transfer $100 from Jan to Mary » Dependency check: does Jan have $100 in her account? » Merge function: log an error

Slide 70

Slide 70 text

User Balance Jan $110 Marsha $10 Peter $42 » Update function: transfer $100 from Jan to Marsha » Dependency check: does Jan have $100 in her account? » Merge function: log an error Errors

Slide 71

Slide 71 text

» Update function: transfer $100 from Jan to Marsha » Dependency check: does Jan have $100 in her account? » Merge function: log an error » Update function: transfer $100 from Jan to Peter » Dependency check: does Jan have $100 in her account? » Merge function: log an error User Balance Jan $10 Marsha $110 Peter $42 Errors

Slide 72

Slide 72 text

» Update function: transfer $100 from Jan to Marsha » Dependency check: does Jan have $100 in her account? » Merge function: log an error » Update function: transfer $100 from Jan to Peter » Dependency check: does Jan have $100 in her account? » Merge function: log an error Errors Jan->Peter failed! User Balance Jan $10 Marsha $110 Peter $42

Slide 73

Slide 73 text

No content

Slide 74

Slide 74 text

No content

Slide 75

Slide 75 text

No content

Slide 76

Slide 76 text

No content

Slide 77

Slide 77 text

No content

Slide 78

Slide 78 text

No content

Slide 79

Slide 79 text

No content

Slide 80

Slide 80 text

No content

Slide 81

Slide 81 text

No content

Slide 82

Slide 82 text

No content

Slide 83

Slide 83 text

No content

Slide 84

Slide 84 text

No content

Slide 85

Slide 85 text

No content

Slide 86

Slide 86 text

Write stability How do we ensure that all servers eventually agree?

Slide 87

Slide 87 text

Write stability How do we ensure that all servers eventually agree? Decide on a “stable” prefix of writes:

Slide 88

Slide 88 text

Write stability How do we ensure that all servers eventually agree? Decide on a “stable” prefix of writes: » Strawman: order writes by timestamp

Slide 89

Slide 89 text

Write stability How do we ensure that all servers eventually agree? Decide on a “stable” prefix of writes: » Strawman: order writes by timestamp • Drawbacks?

Slide 90

Slide 90 text

» Update function: transfer $100 from Jan to Marsha » Dependency check: does Jan have $100 in her account? » Merge function: log an error User Balance Jan $10 Marsha $110 Peter $42 Errors Timestamp 10

Slide 91

Slide 91 text

» Update function: transfer $100 from Jan to Marsha » Dependency check: does Jan have $100 in her account? » Merge function: log an error » Update function: transfer $100 from Jan to Peter » Dependency check: does Jan have $100 in her account? » Merge function: log an error User Balance Jan $10 Marsha $110 Peter $42 Errors Timestamp 10

Slide 92

Slide 92 text

» Update function: transfer $100 from Jan to Marsha » Dependency check: does Jan have $100 in her account? » Merge function: log an error » Update function: transfer $100 from Jan to Peter » Dependency check: does Jan have $100 in her account? » Merge function: log an error User Balance Jan $10 Marsha $110 Peter $42 Errors Timestamp 10 Timestamp 2

Slide 93

Slide 93 text

User Balance Jan $110 Marsha $10 Peter $42 Errors

Slide 94

Slide 94 text

User Balance Jan $110 Marsha $10 Peter $42 Errors » Update function: transfer $100 from Jan to Peter » Dependency check: does Jan have $100 in her account? » Merge function: log an error Timestamp 2

Slide 95

Slide 95 text

User Balance Jan $10 Marsha $10 Peter $142 » Update function: transfer $100 from Jan to Peter » Dependency check: does Jan have $100 in her account? » Merge function: log an error Timestamp 2 Errors Jan->Marsha failed!

Slide 96

Slide 96 text

User Balance Jan $10 Marsha $10 Peter $142 » Update function: transfer $100 from Jan to Peter » Dependency check: does Jan have $100 in her account? » Merge function: log an error Timestamp 2 » Update function: transfer $100 from Jan to Marsha » Dependency check: does Jan have $100 in her account? » Merge function: log an error Timestamp 10 Errors Jan->Marsha failed!

Slide 97

Slide 97 text

11

Slide 98

Slide 98 text

11 22

Slide 99

Slide 99 text

11 22 28

Slide 100

Slide 100 text

11 22 28 34

Slide 101

Slide 101 text

11 22 28 34 13

Slide 102

Slide 102 text

11 22 28 34 13

Slide 103

Slide 103 text

11 22 28 34 13

Slide 104

Slide 104 text

11 22 28 34 13 NEED TO RE-EXECUTE!

Slide 105

Slide 105 text

11 22 28 34 13 NEED TO RE-EXECUTE! Also, makes GC hard

Slide 106

Slide 106 text

Write stability How do we ensure that all servers eventually agree? Decide on a “stable” prefix of writes: » Strawman: order writes by timestamp » Bayou: uses master to determine ordering

Slide 107

Slide 107 text

MASTER

Slide 108

Slide 108 text

MASTER

Slide 109

Slide 109 text

MASTER TENTATIVE COMMITTED T C T C T C

Slide 110

Slide 110 text

MASTER TENTATIVE COMMITTED T C T C T C

Slide 111

Slide 111 text

MASTER TENTATIVE COMMITTED T C T C T C

Slide 112

Slide 112 text

MASTER TENTATIVE COMMITTED T C T C T C

Slide 113

Slide 113 text

MASTER TENTATIVE COMMITTED T C T C T C

Slide 114

Slide 114 text

MASTER TENTATIVE COMMITTED T C T C T C

Slide 115

Slide 115 text

MASTER TENTATIVE COMMITTED T C T C T C

Slide 116

Slide 116 text

MASTER TENTATIVE COMMITTED T C T C T C

Slide 117

Slide 117 text

MASTER TENTATIVE COMMITTED T C T C T C

Slide 118

Slide 118 text

MASTER TENTATIVE COMMITTED T C T C T C

Slide 119

Slide 119 text

MASTER TENTATIVE COMMITTED T C T C T C

Slide 120

Slide 120 text

MASTER TENTATIVE COMMITTED T C T C T C

Slide 121

Slide 121 text

MASTER TENTATIVE COMMITTED T C T C T C

Slide 122

Slide 122 text

Write stability How do we ensure that all servers eventually agree? Decide on a “stable” prefix of writes: » Strawman: order writes by timestamp • Drawbacks? » Bayou: uses master to determine ordering • Benefits? Note: don’t require commutative updates!

Slide 123

Slide 123 text

Read API Can read from: » Stable storage: only committed writes » Tentative storage: all writes seen so far

Slide 124

Slide 124 text

Read API Can read from: » Stable storage: only committed writes » Tentative storage: all writes seen so far Why read from tentative storage at all?

Slide 125

Slide 125 text

No content

Slide 126

Slide 126 text

No content

Slide 127

Slide 127 text

Talk Outline Background and system architecture Conflict detection and resolution APIs “Correctness” and ordering Lessons for all of us

Slide 128

Slide 128 text

Talk Outline Background and system architecture Conflict detection and resolution APIs “Correctness” and ordering Lessons for all of us

Slide 129

Slide 129 text

Bayou’s Secret Sauce Push app logic into updates:

Slide 130

Slide 130 text

Bayou’s Secret Sauce Push app logic into updates: » Read and write are insufficiently expressive!

Slide 131

Slide 131 text

» Update function: transfer $100 from Jan to Peter » Dependency check: does Jan have $100 in her account? » Merge function: log an error » Update function: transfer $100 from Jan to Mary » Dependency check: does Jan have $100 in her account? » Merge function: log an error

Slide 132

Slide 132 text

» Update function: transfer $100 from Jan to Peter » Dependency check: does Jan have $100 in her account? » Merge function: log an error » Update function: transfer $100 from Jan to Mary » Dependency check: does Jan have $100 in her account? » Merge function: log an error WRITE: Jan = 10; Peter = 42 WRITE: Jan = 10; Mary = 110

Slide 133

Slide 133 text

» Update function: transfer $100 from Jan to Peter » Dependency check: does Jan have $100 in her account? » Merge function: log an error » Update function: transfer $100 from Jan to Mary » Dependency check: does Jan have $100 in her account? » Merge function: log an error WRITE: Jan = 10; Peter = 42 WRITE: Jan = 10; Mary = 110 » decrement Jan by $100; increment Peter by 100 » decrement Jan by $100; increment Mary by 100

Slide 134

Slide 134 text

Bayou’s Secret Sauce Push app logic into updates: » Read and write are insufficiently expressive!

Slide 135

Slide 135 text

Bayou’s Secret Sauce Push app logic into updates: » Read and write are insufficiently expressive! Capture transaction intent:

Slide 136

Slide 136 text

Bayou’s Secret Sauce Push app logic into updates: » Read and write are insufficiently expressive! Capture transaction intent: » Dependency checks encode preconditions » e.g., guarded atomic actions

Slide 137

Slide 137 text

What does Bayou guarantee? Eventually all updates are applied in the same order on all servers

Slide 138

Slide 138 text

What does Bayou guarantee? Eventually all updates are applied in the same order on all servers » Kind of like serializable/ACID transactions!

Slide 139

Slide 139 text

What does Bayou guarantee? Eventually all updates are applied in the same order on all servers » Kind of like serializable/ACID transactions! » Dependency checks enforce invariants

Slide 140

Slide 140 text

What does Bayou guarantee? Eventually all updates are applied in the same order on all servers » Kind of like serializable/ACID transactions! » Dependency checks enforce invariants » Did we just “beat CAP”?

Slide 141

Slide 141 text

What does Bayou guarantee? Eventually all updates are applied in the same order on all servers » Kind of like serializable/ACID transactions! » Dependency checks enforce invariants » Did we just “beat CAP”? Key: eventually means we have to wait

Slide 142

Slide 142 text

H-Store, VoltDB, Granola, Calvin, Atomic Broadcast Idea sketch: pre-schedule transactions, then execute them sequentially on respective servers

Slide 143

Slide 143 text

H-Store, VoltDB, Granola, Calvin, Atomic Broadcast Idea sketch: pre-schedule transactions, then execute them sequentially on respective servers Totally ordered outcomes on each replica

Slide 144

Slide 144 text

H-Store, VoltDB, Granola, Calvin, Atomic Broadcast Idea sketch: pre-schedule transactions, then execute them sequentially on respective servers Totally ordered outcomes on each replica …but ordering determined up front!

Slide 145

Slide 145 text

No content

Slide 146

Slide 146 text

Bayou 㱺 “ACID”

Slide 147

Slide 147 text

Bayou 㱺 “ACID” 1.) Given transaction T, issue write W:

Slide 148

Slide 148 text

Bayou 㱺 “ACID” 1.) Given transaction T, issue write W: » Update function: // do nothing

Slide 149

Slide 149 text

Bayou 㱺 “ACID” 1.) Given transaction T, issue write W: » Update function: // do nothing » Dependency check: false

Slide 150

Slide 150 text

Bayou 㱺 “ACID” 1.) Given transaction T, issue write W: » Update function: // do nothing » Dependency check: false » Merge function: execute T

Slide 151

Slide 151 text

Bayou 㱺 “ACID” 1.) Given transaction T, issue write W: » Update function: // do nothing » Dependency check: false » Merge function: execute T 2.) Wait for write W to commit.

Slide 152

Slide 152 text

Bayou 㱺 “ACID” 1.) Given transaction T, issue write W: » Update function: // do nothing » Dependency check: false » Merge function: execute T 2.) Wait for write W to commit. 3.) Notify success.

Slide 153

Slide 153 text

No content

Slide 154

Slide 154 text

What does Bayou guarantee? Eventually all writes are applied in the same order on all servers » Kind of like serializable/ACID transactions! » Dependency checks enforce invariants » Did we just “beat CAP”? Key: eventually means we have to wait

Slide 155

Slide 155 text

“#is meeting room scheduling program is intended for use after a group of people have already decided that they want to meet in a certain room and have determined a set of acceptable times for the meeting. It does not help them to determine a mutually agreeable place and time for the meeting, it only allows them to reserve the room.”

Slide 156

Slide 156 text

“#is meeting room scheduling program is intended for use after a group of people have already decided that they want to meet in a certain room and have determined a set of acceptable times for the meeting. It does not help them to determine a mutually agreeable place and time for the meeting, it only allows them to reserve the room.”

Slide 157

Slide 157 text

“#is meeting room scheduling program is intended for use after a group of people have already decided that they want to meet in a certain room and have determined a set of acceptable times for the meeting. It does not help them to determine a mutually agreeable place and time for the meeting, it only allows them to reserve the room.”

Slide 158

Slide 158 text

When can we avoid “waiting”?

Slide 159

Slide 159 text

When can we avoid “waiting”? Commutative logic need not be re-executed in the log! (Paper discusses this.)

Slide 160

Slide 160 text

A note on commutativity Commutative logic: decisions made in application logic are insensitive to ordering

Slide 161

Slide 161 text

A note on commutativity Commutative logic: decisions made in application logic are insensitive to ordering Commutative datatypes: operations on datatypes are insensitive to ordering #e latter are useful, but won’t ensure correctness! http://www.bailis.org/blog/data-integrity-and-problems-of-scope/

Slide 162

Slide 162 text

» Update function: transfer $100 from Jan to Peter » Dependency check: does Jan have $100 in her account? » Merge function: log an error » Update function: transfer $100 from Jan to Marsha » Dependency check: does Jan have $100 in her account? » Merge function: log an error » decrement Jan by $100; increment Peter by 100 » decrement Jan by $100; increment Marsha by 100 WRITE: Jan = 10; Peter = 42 WRITE: Jan = 10; Marsha = 110

Slide 163

Slide 163 text

A note on commutativity Commutative logic: decisions made in application logic are insensitive to ordering Commutative datatypes: operations on datatypes are insensitive to ordering #e latter are useful, but won’t ensure correctness! http://www.bailis.org/blog/data-integrity-and-problems-of-scope/

Slide 164

Slide 164 text

When can we avoid “waiting”? Commutative logic need not be re-executed in the log! (Paper discusses this.)

Slide 165

Slide 165 text

When can we avoid “waiting”? CALM !eorem: monotonic logic <=> determinism despite different orders [CIDR 2011] See also Kuper’s LVars Commutative logic need not be re-executed in the log! (Paper discusses this.)

Slide 166

Slide 166 text

When can we avoid “waiting”? CALM !eorem: monotonic logic <=> determinism despite different orders [CIDR 2011] See also Kuper’s LVars I-confluence: guarantees “safe” tentative reads with convergent and safe outcomes [VLDB 2015] Commutative logic need not be re-executed in the log! (Paper discusses this.)

Slide 167

Slide 167 text

A note on immutability

Slide 168

Slide 168 text

A note on immutability Bayou’s stable log is “immutable” » e.g., event sourcing, Lambda architecture

Slide 169

Slide 169 text

A note on immutability Bayou’s stable log is “immutable” » e.g., event sourcing, Lambda architecture But what guarantees can we make about the outcomes in the log?

Slide 170

Slide 170 text

A note on immutability Bayou’s stable log is “immutable” » e.g., event sourcing, Lambda architecture But what guarantees can we make about the outcomes in the log? » “Immutable” writes are the easy part! » Reasoning about outcomes is the challenge

Slide 171

Slide 171 text

Why have “merge” at all?

Slide 172

Slide 172 text

Why have “merge” at all? Why not just ship the stored procedures and re-execute them instead?

Slide 173

Slide 173 text

Why have “merge” at all? Why not just ship the stored procedures and re-execute them instead? » Update function: transfer $100 from Jan to Peter » Dependency check: does Jan have $100 in her account? » Merge function: log an error

Slide 174

Slide 174 text

Why have “merge” at all? Why not just ship the stored procedures and re-execute them instead? » Update function: transfer $100 from Jan to Peter » Dependency check: does Jan have $100 in her account? » Merge function: log an error If Jan has $100: transfer $100 from Jan to Peter Else: Log an error

Slide 175

Slide 175 text

a

Slide 176

Slide 176 text

ELE Edelweiss

Slide 177

Slide 177 text

Durability? In this context, durability and consistency are effectively orthogonal » Durability: “survive F faults, need F+1 servers” » Strong consistency: usually requires “majority”

Slide 178

Slide 178 text

Durability? In this context, durability and consistency are effectively orthogonal » Durability: “survive F faults, need F+1 servers” » Strong consistency: usually requires “majority” Bayou: local updates may not survive faults » But the (arguably) more fundamental part of the system is maintaining updates

Slide 179

Slide 179 text

Bayou vs. Dynamo Fully replicated Update-one In-order per-server sequenced anti-entropy Server-side merge Global stability detection No “strong” consistency Partially replicated Update-N Merkle tree-based anti- entropy Client-side merge No notion of, API for stability Regular registers via majority quorum

Slide 180

Slide 180 text

Talk Outline Background and system architecture Conflict detection and resolution APIs “Correctness” and ordering Lessons for all of us

Slide 181

Slide 181 text

Talk Outline Background and system architecture Conflict detection and resolution APIs “Correctness” and ordering Lessons for all of us

Slide 182

Slide 182 text

Why Bayou? “NoSQL” before “NoSQL” Learn from smart predecessors Rethink application, system boundaries Lucid discussion of systems challenges

Slide 183

Slide 183 text

Bayou Goals Handle frequent disconnections » Embrace replication, update-anywhere

Slide 184

Slide 184 text

Bayou Goals Handle frequent disconnections » Embrace replication, update-anywhere Reason about distribution explicitly » Require application semantics

Slide 185

Slide 185 text

Bayou Goals Handle frequent disconnections » Embrace replication, update-anywhere Reason about distribution explicitly » Require application semantics Facilitate conflict detection and resolution » Use merge and dependency APIs

Slide 186

Slide 186 text

“Weakly consistent replication has been used previously for availability, simplicity, and scalability in a variety of systems [3, 7, 10, 12, 15, 19].”

Slide 187

Slide 187 text

“Weakly consistent replication has been used previously for availability, simplicity, and scalability in a variety of systems [3, 7, 10, 12, 15, 19].”

Slide 188

Slide 188 text

Simplicity for whom?

Slide 189

Slide 189 text

Simplicity for whom? Architects Systems programmers Operators

Slide 190

Slide 190 text

Simplicity for whom? Architects Systems programmers Operators Application writers? Users?

Slide 191

Slide 191 text

Simplicity for whom? Architects Systems programmers Operators Application writers? Users? Analogous issues in RDBMS design! http://www.bailis.org/blog/understanding-weak- isolation-is-a-serious-problem/

Slide 192

Slide 192 text

Unfortunately, not always a choice!

Slide 193

Slide 193 text

THOSE LIGHT CONES_

Slide 194

Slide 194 text

2.6 Billion Internet users in 2013 7.1 Billion humans on planet Earth Who cares about scale? Coordination? [Mary Meeker]

Slide 195

Slide 195 text

2.6 Billion Internet users in 2013 7.1 Billion humans on planet Earth Who cares about scale? Coordination? Will data keep increasing? Why? Hint: not humans. [Mary Meeker]

Slide 196

Slide 196 text

No content

Slide 197

Slide 197 text

No content

Slide 198

Slide 198 text

No content

Slide 199

Slide 199 text

No content

Slide 200

Slide 200 text

No content

Slide 201

Slide 201 text

No content

Slide 202

Slide 202 text

Xerox PARC Laser printers Computer-generated bitmap graphics #e Graphical user interface, featuring windows and icons, operated with a mouse #e WYSIWYG text editor #e precursor to PostScript Ethernet as a local-area computer network Fully formed object-oriented programming in the Smalltalk programming language and integrated development environment. Model–view–controller software architecture Bayou! [Wikipedia]

Slide 203

Slide 203 text

Xerox PARC DEC SRC MSR SVC ???

Slide 204

Slide 204 text

What can we learn? 1.) Integrating application logic is key to “correct” execution of “AP” distributed systems. R/W is bad. 2.) Lack of app-specific mechanisms in a coordination- free system is a recipe for data corruption. 3.) Merge/repair is a narrow API for developers to express their application conflicts. 4.) Alternatives like commutativity, I-confluence, and research tools like Bloom can help limit overhead.

Slide 205

Slide 205 text

!anks Fastly & Ines!