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?
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
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
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.