Replicated*DataConsistency*...
Transcript of Replicated*DataConsistency*...
![Page 1: Replicated*DataConsistency* Explained*Through*Baseball*db.cs.duke.edu/courses/spring15/cps210/slides/consistency.pdf · Key-value stores • Many mega-services are built on key-value](https://reader034.fdocuments.us/reader034/viewer/2022050109/5f46e68851a258045a7cd593/html5/thumbnails/1.jpg)
Replicated Data Consistency Explained Through Baseball
slides by Landon Cox
with some others from elsewhere prepended and appended (cultural history lesson)
![Page 2: Replicated*DataConsistency* Explained*Through*Baseball*db.cs.duke.edu/courses/spring15/cps210/slides/consistency.pdf · Key-value stores • Many mega-services are built on key-value](https://reader034.fdocuments.us/reader034/viewer/2022050109/5f46e68851a258045a7cd593/html5/thumbnails/2.jpg)
Preview/overview • K-V stores are a common data tier for mega-services. • They evolved during the Web era, starting with DDS. • Today they often feature geographic replication.
– Multiple replicas in different data centers. – Geo-replication offers better scale and reliability/availability.
• But updates are slower to propagate, and network partitions may interfere. – A read might not see the “latest” write.
• So we have to think carefully about what consistency properties we need: “BASE” might be “good enough”. – FLP and CAP tell us that there are fundamental limits on what
we can guarantee….but many recent innovations in this space.
![Page 3: Replicated*DataConsistency* Explained*Through*Baseball*db.cs.duke.edu/courses/spring15/cps210/slides/consistency.pdf · Key-value stores • Many mega-services are built on key-value](https://reader034.fdocuments.us/reader034/viewer/2022050109/5f46e68851a258045a7cd593/html5/thumbnails/3.jpg)
Key-value stores • Many mega-services are built on key-value stores.
– Store variable-length content objects: think “tiny files” (value) – Each object is named by a “key”, usually fixed-size. – Key is also called a token: not to be confused with a crypto key!
Although it may be a content hash (SHAx or MD5). – Simple put/get interface with no offsets or transactions (yet). – Goes back to literature on Distributed Data Structures [Gribble
2000] and Distributed Hash Tables (DHTs).
Over the next couple of years, Amazon transformed internally into a service-oriented architecture. They learned a tremendous amount… - pager escalation gets way harder….build a lot of scaffolding and metrics and reporting. - every single one of your peer teams suddenly becomes a potential DOS attacker. Nobody can make any real forward progress until very serious quotas and throttling are put in place in every single service. - monitoring and QA are the same thing. You'd never think so until you try doing a big SOA. But when your service says "oh yes, I'm fine", it may well be the case that the only thing still functioning in the server is the little component that knows how to say "I'm fine, roger roger, over and out" in a cheery droid voice. In order to tell whether the service is actually responding, you have to make individual calls. The problem continues recursively until your monitoring is doing comprehensive semantics checking of your entire range of services and data, at which point it's indistinguishable from automated QA. So they're a continuum. - if you have hundreds of services, and your code MUST communicate with other groups' code via these services, then you won't be able to find any of them without a service-discovery mechanism. And you can't have that without a service registration mechanism, which itself is another service. So Amazon has a universal service registry where you can find out reflectively (programmatically) about every service, what its APIs are, and also whether it is currently up, and where. - debugging problems with someone else's code gets a LOT harder, and is basically impossible unless there is a universal standard way to run every service in a debuggable sandbox. That's just a very small sample. There are dozens, maybe hundreds of individual learnings like these that Amazon had to discover organically. There were a lot of wacky ones around externalizing services, but not as many as you might think. Organizing into services taught teams not to trust each other in most of the same ways they're not supposed to trust external developers. This effort was still underway when I left to join Google in mid-2005, but it was pretty far advanced. From the time Bezos issued his edict through the time I left, Amazon had transformed culturally into a company that thinks about everything in a services-first fashion. It is now fundamental to how they approach all designs, including internal designs for stuff that might never see the light of day externally.
[image from Sean Rhea, opendht.org, 2004]
![Page 4: Replicated*DataConsistency* Explained*Through*Baseball*db.cs.duke.edu/courses/spring15/cps210/slides/consistency.pdf · Key-value stores • Many mega-services are built on key-value](https://reader034.fdocuments.us/reader034/viewer/2022050109/5f46e68851a258045a7cd593/html5/thumbnails/4.jpg)
ACID vs. BASE
Jim Gray ACM Turing Award 1998
Eric Brewer ACM SIGOPS
Mark Weiser Award 2009
![Page 5: Replicated*DataConsistency* Explained*Through*Baseball*db.cs.duke.edu/courses/spring15/cps210/slides/consistency.pdf · Key-value stores • Many mega-services are built on key-value](https://reader034.fdocuments.us/reader034/viewer/2022050109/5f46e68851a258045a7cd593/html5/thumbnails/5.jpg)
HPTS Keynote, October 2001
ACID vs. BASE ACID
Strong consistency Isolation Focus on “commit” Nested transactions Availability? Conservative (pessimistic) Difficult evolution
(e.g. schema) “small” Invariant Boundary The “inside”
BASE Weak consistency
– stale data OK
Availability first Best effort Approximate answers OK Aggressive (optimistic) “Simpler” and faster Easier evolution (XML) “wide” Invariant Boundary Outside consistency boundary
but it’s a spectrum
![Page 6: Replicated*DataConsistency* Explained*Through*Baseball*db.cs.duke.edu/courses/spring15/cps210/slides/consistency.pdf · Key-value stores • Many mega-services are built on key-value](https://reader034.fdocuments.us/reader034/viewer/2022050109/5f46e68851a258045a7cd593/html5/thumbnails/6.jpg)
Prior to joining Amazon, he worked as a researcher at Cornell University.
Dr. Werner Vogels is Vice President & Chief Technology Officer at Amazon.com.
![Page 7: Replicated*DataConsistency* Explained*Through*Baseball*db.cs.duke.edu/courses/spring15/cps210/slides/consistency.pdf · Key-value stores • Many mega-services are built on key-value](https://reader034.fdocuments.us/reader034/viewer/2022050109/5f46e68851a258045a7cd593/html5/thumbnails/7.jpg)
Vogels on consistency
Strong consistency: “After the update completes, any subsequent access will return the updated value.”
Consistency “has to do with how observers see these updates”.
The scenario A updates a “data object” in a “storage system”.
Eventual consistency: “If no new updates are made to the object, eventually all accesses will return the last updated value.”
![Page 8: Replicated*DataConsistency* Explained*Through*Baseball*db.cs.duke.edu/courses/spring15/cps210/slides/consistency.pdf · Key-value stores • Many mega-services are built on key-value](https://reader034.fdocuments.us/reader034/viewer/2022050109/5f46e68851a258045a7cd593/html5/thumbnails/8.jpg)
PNUTS: Yahoo!’s Hosted Data Serving Platform
Brian F. Cooper, Raghu Ramakrishnan, Utkarsh Srivastava,
Adam Silberstein, Philip Bohannon, Hans-Arno Jacobsen, Nick Puz, Daniel Weaver and Ramana Yerneni
Yahoo! Research
![Page 9: Replicated*DataConsistency* Explained*Through*Baseball*db.cs.duke.edu/courses/spring15/cps210/slides/consistency.pdf · Key-value stores • Many mega-services are built on key-value](https://reader034.fdocuments.us/reader034/viewer/2022050109/5f46e68851a258045a7cd593/html5/thumbnails/9.jpg)
9
Example: social network updates
Brian
Sonja Jimi Brandon Kurt
What are my friends up to? Sonja:
Brandon:
![Page 10: Replicated*DataConsistency* Explained*Through*Baseball*db.cs.duke.edu/courses/spring15/cps210/slides/consistency.pdf · Key-value stores • Many mega-services are built on key-value](https://reader034.fdocuments.us/reader034/viewer/2022050109/5f46e68851a258045a7cd593/html5/thumbnails/10.jpg)
10
Example: social network updates
16 Mike <ph..
6 Jimi <ph.. 8 Mary <re.. 12 Sonja <ph.. 15 Brandon <po..
17 Bob <re.. <photo> <title>Flower</title> <url>www.flickr.com</url> </photo>
![Page 11: Replicated*DataConsistency* Explained*Through*Baseball*db.cs.duke.edu/courses/spring15/cps210/slides/consistency.pdf · Key-value stores • Many mega-services are built on key-value](https://reader034.fdocuments.us/reader034/viewer/2022050109/5f46e68851a258045a7cd593/html5/thumbnails/11.jpg)
11
Asynchronous replication
![Page 12: Replicated*DataConsistency* Explained*Through*Baseball*db.cs.duke.edu/courses/spring15/cps210/slides/consistency.pdf · Key-value stores • Many mega-services are built on key-value](https://reader034.fdocuments.us/reader034/viewer/2022050109/5f46e68851a258045a7cd593/html5/thumbnails/12.jpg)
12
Consistency model
n Goal: make it easier for applications to reason about updates and cope with asynchrony
n What happens to a record with primary key “Brian”?
Time
Record inserted
Update Update Update Update Update Delete
Time v. 1 v. 2 v. 3 v. 4 v. 5 v. 7 Generation 1
v. 6 v. 8
Update Update
![Page 13: Replicated*DataConsistency* Explained*Through*Baseball*db.cs.duke.edu/courses/spring15/cps210/slides/consistency.pdf · Key-value stores • Many mega-services are built on key-value](https://reader034.fdocuments.us/reader034/viewer/2022050109/5f46e68851a258045a7cd593/html5/thumbnails/13.jpg)
13
Consistency model
Time v. 1 v. 2 v. 3 v. 4 v. 5 v. 7 Generation 1
v. 6 v. 8
Current version
Stale version Stale version
Read
![Page 14: Replicated*DataConsistency* Explained*Through*Baseball*db.cs.duke.edu/courses/spring15/cps210/slides/consistency.pdf · Key-value stores • Many mega-services are built on key-value](https://reader034.fdocuments.us/reader034/viewer/2022050109/5f46e68851a258045a7cd593/html5/thumbnails/14.jpg)
14
Consistency model
Time v. 1 v. 2 v. 3 v. 4 v. 5 v. 7 Generation 1
v. 6 v. 8
Read up-to-date
Current version
Stale version Stale version
![Page 15: Replicated*DataConsistency* Explained*Through*Baseball*db.cs.duke.edu/courses/spring15/cps210/slides/consistency.pdf · Key-value stores • Many mega-services are built on key-value](https://reader034.fdocuments.us/reader034/viewer/2022050109/5f46e68851a258045a7cd593/html5/thumbnails/15.jpg)
15
Consistency model
Time v. 1 v. 2 v. 3 v. 4 v. 5 v. 7 Generation 1
v. 6 v. 8
Read ≥ v.6
Current version
Stale version Stale version
Read-critical(required version):
![Page 16: Replicated*DataConsistency* Explained*Through*Baseball*db.cs.duke.edu/courses/spring15/cps210/slides/consistency.pdf · Key-value stores • Many mega-services are built on key-value](https://reader034.fdocuments.us/reader034/viewer/2022050109/5f46e68851a258045a7cd593/html5/thumbnails/16.jpg)
16
Consistency model
Time v. 1 v. 2 v. 3 v. 4 v. 5 v. 7 Generation 1
v. 6 v. 8
Write if = v.7
ERROR
Current version
Stale version Stale version
Test-and-set-write(required version)
![Page 17: Replicated*DataConsistency* Explained*Through*Baseball*db.cs.duke.edu/courses/spring15/cps210/slides/consistency.pdf · Key-value stores • Many mega-services are built on key-value](https://reader034.fdocuments.us/reader034/viewer/2022050109/5f46e68851a258045a7cd593/html5/thumbnails/17.jpg)
Wya; Lloyd* Michael J. Freedman* Michael Kaminsky† David G. Andersen‡
*Princeton, †Intel Labs, ‡CMU
Don’t Se;le for Eventual: Scalable Causal Consistency for Wide-‐Area Storage with COPS
![Page 18: Replicated*DataConsistency* Explained*Through*Baseball*db.cs.duke.edu/courses/spring15/cps210/slides/consistency.pdf · Key-value stores • Many mega-services are built on key-value](https://reader034.fdocuments.us/reader034/viewer/2022050109/5f46e68851a258045a7cd593/html5/thumbnails/18.jpg)
Wide-‐Area Storage
Stores: Status Updates Likes Comments Photos Friends List
Stores: Tweets Favorites Following List
Stores: Posts +1s Comments Photos Circles
![Page 19: Replicated*DataConsistency* Explained*Through*Baseball*db.cs.duke.edu/courses/spring15/cps210/slides/consistency.pdf · Key-value stores • Many mega-services are built on key-value](https://reader034.fdocuments.us/reader034/viewer/2022050109/5f46e68851a258045a7cd593/html5/thumbnails/19.jpg)
Wide-‐Area Storage Serves Requests Quickly
![Page 20: Replicated*DataConsistency* Explained*Through*Baseball*db.cs.duke.edu/courses/spring15/cps210/slides/consistency.pdf · Key-value stores • Many mega-services are built on key-value](https://reader034.fdocuments.us/reader034/viewer/2022050109/5f46e68851a258045a7cd593/html5/thumbnails/20.jpg)
Inside the Datacenter
Web Tier Storage Tier
A-‐F
G-‐L
M-‐R
S-‐Z
Web Tier Storage Tier
A-‐F
G-‐L
M-‐R
S-‐Z
Remote DC
![Page 21: Replicated*DataConsistency* Explained*Through*Baseball*db.cs.duke.edu/courses/spring15/cps210/slides/consistency.pdf · Key-value stores • Many mega-services are built on key-value](https://reader034.fdocuments.us/reader034/viewer/2022050109/5f46e68851a258045a7cd593/html5/thumbnails/21.jpg)
Desired ProperZes: ALPS
• Availability
• Low Latency
• ParZZon Tolerance
• Scalability
“Always On”
![Page 22: Replicated*DataConsistency* Explained*Through*Baseball*db.cs.duke.edu/courses/spring15/cps210/slides/consistency.pdf · Key-value stores • Many mega-services are built on key-value](https://reader034.fdocuments.us/reader034/viewer/2022050109/5f46e68851a258045a7cd593/html5/thumbnails/22.jpg)
Scalability Increase capacity and throughput in each datacenter
A-‐Z A-‐Z A-‐L
M-‐Z
A-‐L
M-‐Z
A-‐F
G-‐L
M-‐R
S-‐Z
A-‐F
G-‐L
M-‐R
S-‐Z
A-‐C
D-‐F
G-‐J
K-‐L
M-‐O
P-‐S
T-‐V
W-‐Z
A-‐C
D-‐F
G-‐J
K-‐L
M-‐O
P-‐S
T-‐V
W-‐Z
![Page 23: Replicated*DataConsistency* Explained*Through*Baseball*db.cs.duke.edu/courses/spring15/cps210/slides/consistency.pdf · Key-value stores • Many mega-services are built on key-value](https://reader034.fdocuments.us/reader034/viewer/2022050109/5f46e68851a258045a7cd593/html5/thumbnails/23.jpg)
Desired Property: Consistency
• Restricts order/Zming of operaZons • Stronger consistency:
– Makes programming easier – Makes user experience be;er
![Page 24: Replicated*DataConsistency* Explained*Through*Baseball*db.cs.duke.edu/courses/spring15/cps210/slides/consistency.pdf · Key-value stores • Many mega-services are built on key-value](https://reader034.fdocuments.us/reader034/viewer/2022050109/5f46e68851a258045a7cd593/html5/thumbnails/24.jpg)
Consistency with ALPS
Strong
SequenZal
Causal
Eventual
Impossible [Brewer00, GilbertLynch02] Impossible [LiptonSandberg88, AdyaWelch94]
COPS
Amazon LinkedIn Facebook/Apache Dynamo Voldemort Cassandra
![Page 25: Replicated*DataConsistency* Explained*Through*Baseball*db.cs.duke.edu/courses/spring15/cps210/slides/consistency.pdf · Key-value stores • Many mega-services are built on key-value](https://reader034.fdocuments.us/reader034/viewer/2022050109/5f46e68851a258045a7cd593/html5/thumbnails/25.jpg)
System A L P S Consistency
Sca;er ✖ ✖ ✖ ✔ ✔ Strong Walter ✖ ✖ ✖ ? PSI + Txn
COPS ✔ ✔ ✔ ✔ Causal+ Bayou ✔ ✔ ✔ ✖ Causal+
PNUTS ✔ ✔ ? ✔ Per-‐Key Seq. Dynamo ✔ ✔ ✔ ✔ ✖ Eventual
![Page 26: Replicated*DataConsistency* Explained*Through*Baseball*db.cs.duke.edu/courses/spring15/cps210/slides/consistency.pdf · Key-value stores • Many mega-services are built on key-value](https://reader034.fdocuments.us/reader034/viewer/2022050109/5f46e68851a258045a7cd593/html5/thumbnails/26.jpg)
Replicated-‐data consistency
• A set of invariants on each read operaEon • Which writes are guaranteed to be reflected? • What write orders are guaranteed?
• Consistency is an applicaEon-‐level concern • When consistency is too weak, applicaZons break • Example: aucZon site must not tell two people they won
• What are consequences of too-‐strong consistency? • Worse performance (for reads and writes) • Worse availability (for reads and writes)
![Page 27: Replicated*DataConsistency* Explained*Through*Baseball*db.cs.duke.edu/courses/spring15/cps210/slides/consistency.pdf · Key-value stores • Many mega-services are built on key-value](https://reader034.fdocuments.us/reader034/viewer/2022050109/5f46e68851a258045a7cd593/html5/thumbnails/27.jpg)
• The following are slides on the Doug Terry paper by Landon Cox.
• We went through these preJy fast in class, but you should understand these models and why we might use them.
![Page 28: Replicated*DataConsistency* Explained*Through*Baseball*db.cs.duke.edu/courses/spring15/cps210/slides/consistency.pdf · Key-value stores • Many mega-services are built on key-value](https://reader034.fdocuments.us/reader034/viewer/2022050109/5f46e68851a258045a7cd593/html5/thumbnails/28.jpg)
AssumpZons for our discussion
1. Clients perform reads and writes 2. Data is replicated among a set of servers 3. Writes are serialized (logically, one writer)
1. Performed in the same order at all servers 2. Write order consistent with write-‐request order
4. Reads result of one or more past writes
![Page 29: Replicated*DataConsistency* Explained*Through*Baseball*db.cs.duke.edu/courses/spring15/cps210/slides/consistency.pdf · Key-value stores • Many mega-services are built on key-value](https://reader034.fdocuments.us/reader034/viewer/2022050109/5f46e68851a258045a7cd593/html5/thumbnails/29.jpg)
Consistency models 1. Strong consistency
• Reader sees effect of all prior writes 2. Eventual consistency
• Reader sees effect of subset of prior writes 3. Consistent prefix
• Reader sees effect of iniZal sequence of writes 4. Bounded staleness
• Reader sees effect of all “old” writes 5. Monotonic reads
• Reader sees effect of increasing subset of writes 6. Read my writes
• Reader sees effect of all writes performed by reader
![Page 30: Replicated*DataConsistency* Explained*Through*Baseball*db.cs.duke.edu/courses/spring15/cps210/slides/consistency.pdf · Key-value stores • Many mega-services are built on key-value](https://reader034.fdocuments.us/reader034/viewer/2022050109/5f46e68851a258045a7cd593/html5/thumbnails/30.jpg)
Sedng: baseball game Write (“visitors”, 0); Write (“home”, 0); for inning = 1..9 outs = 0; while outs < 3 visiting player bats; for each run scored score = Read (“visitors”); Write (“visitors”, score + 1); outs = 0; while outs < 3 home player bats; for each run scored score = Read (“home”); Write (“home”, score + 1); end game;
Primary game thread. Only thread that issues writes.
![Page 31: Replicated*DataConsistency* Explained*Through*Baseball*db.cs.duke.edu/courses/spring15/cps210/slides/consistency.pdf · Key-value stores • Many mega-services are built on key-value](https://reader034.fdocuments.us/reader034/viewer/2022050109/5f46e68851a258045a7cd593/html5/thumbnails/31.jpg)
H H H V V V
Reader Writer (also reads)
Reader
R R
W R W
Visitors’ score Home score
R R
S1 S2 S3 S4 S5 S6
![Page 32: Replicated*DataConsistency* Explained*Through*Baseball*db.cs.duke.edu/courses/spring15/cps210/slides/consistency.pdf · Key-value stores • Many mega-services are built on key-value](https://reader034.fdocuments.us/reader034/viewer/2022050109/5f46e68851a258045a7cd593/html5/thumbnails/32.jpg)
Example 1: score keeper
score = Read (“visitors”); Write (“visitors”, score + 1); … score = Read (“home”); Write (“home”, score + 1);
![Page 33: Replicated*DataConsistency* Explained*Through*Baseball*db.cs.duke.edu/courses/spring15/cps210/slides/consistency.pdf · Key-value stores • Many mega-services are built on key-value](https://reader034.fdocuments.us/reader034/viewer/2022050109/5f46e68851a258045a7cd593/html5/thumbnails/33.jpg)
Example 1: score keeper
What invariant is the score keeper
maintaining on the game’s score?
Both values increase monotonically
Write (“home”, 1); Write (“visitors”, 1); Write (“home”, 2); Write (“home”, 3); Write (“visitors”, 2); Write (“home”, 4); Write (“home”, 5);
Visitors = 2 Home = 5
![Page 34: Replicated*DataConsistency* Explained*Through*Baseball*db.cs.duke.edu/courses/spring15/cps210/slides/consistency.pdf · Key-value stores • Many mega-services are built on key-value](https://reader034.fdocuments.us/reader034/viewer/2022050109/5f46e68851a258045a7cd593/html5/thumbnails/34.jpg)
Example 1: score keeper
What invariant must the store provide so the score keeper can ensure monotonically increasing scores?
Reads must show effect of all prior
writes (strong consistency)
Write (“home”, 1); Write (“visitors”, 1); Write (“home”, 2); Write (“home”, 3); Write (“visitors”, 2); Write (“home”, 4); Write (“home”, 5);
Visitors = 2 Home = 5
![Page 35: Replicated*DataConsistency* Explained*Through*Baseball*db.cs.duke.edu/courses/spring15/cps210/slides/consistency.pdf · Key-value stores • Many mega-services are built on key-value](https://reader034.fdocuments.us/reader034/viewer/2022050109/5f46e68851a258045a7cd593/html5/thumbnails/35.jpg)
Example 1: score keeper
Write (“home”, 1); Write (“visitors”, 1); Write (“home”, 2); Write (“home”, 3); Write (“visitors”, 2); Write (“home”, 4); Write (“home”, 5);
Visitors = 2 Home = 5
Under strong consistency, what possible scores can
the score keeper read a]er this write completes?
2-‐5
![Page 36: Replicated*DataConsistency* Explained*Through*Baseball*db.cs.duke.edu/courses/spring15/cps210/slides/consistency.pdf · Key-value stores • Many mega-services are built on key-value](https://reader034.fdocuments.us/reader034/viewer/2022050109/5f46e68851a258045a7cd593/html5/thumbnails/36.jpg)
Example 1: score keeper
Write (“home”, 1); Write (“visitors”, 1); Write (“home”, 2); Write (“home”, 3); Write (“visitors”, 2); Write (“home”, 4); Write (“home”, 5);
Visitors = 2 Home = 5
Under read-‐my-‐writes, what possible scores can the score keeper read a]er this write completes?
2-‐5
![Page 37: Replicated*DataConsistency* Explained*Through*Baseball*db.cs.duke.edu/courses/spring15/cps210/slides/consistency.pdf · Key-value stores • Many mega-services are built on key-value](https://reader034.fdocuments.us/reader034/viewer/2022050109/5f46e68851a258045a7cd593/html5/thumbnails/37.jpg)
H H H V V V
Writer (also reads)
Reader
W W
Visitors’ score Home score
W
Writer (also reads)
S1 S2 S3 S4 S5 S6
![Page 38: Replicated*DataConsistency* Explained*Through*Baseball*db.cs.duke.edu/courses/spring15/cps210/slides/consistency.pdf · Key-value stores • Many mega-services are built on key-value](https://reader034.fdocuments.us/reader034/viewer/2022050109/5f46e68851a258045a7cd593/html5/thumbnails/38.jpg)
H’ H H V’ V V’
Writer (also reads)
Reader
Visitors’ score Home score
R
Under strong consistency, who
must S3 have spoken to (directly or
indirectly) to saEsfy read request?
S2, S5
Writer (also reads)
S1 S2 S3 S4 S5 S6
![Page 39: Replicated*DataConsistency* Explained*Through*Baseball*db.cs.duke.edu/courses/spring15/cps210/slides/consistency.pdf · Key-value stores • Many mega-services are built on key-value](https://reader034.fdocuments.us/reader034/viewer/2022050109/5f46e68851a258045a7cd593/html5/thumbnails/39.jpg)
H’ H H V’ V V’
Writer (also reads)
Reader
Visitors’ score Home score
When does S3 have to talk to S2 and S5? Before writes return
or before read returns?
ImplementaEon can be flexible. Guarantee is that inform-‐flow occurs before read
completes. Writer (also reads)
S1 S2 S3 S4 S5 S6
R
![Page 40: Replicated*DataConsistency* Explained*Through*Baseball*db.cs.duke.edu/courses/spring15/cps210/slides/consistency.pdf · Key-value stores • Many mega-services are built on key-value](https://reader034.fdocuments.us/reader034/viewer/2022050109/5f46e68851a258045a7cd593/html5/thumbnails/40.jpg)
H’ H H V’ V V’
Writer (also reads)
Reader
Visitors’ score Home score
Under read-‐my-‐writes, who must S3
have spoken to (directly or indirectly)
to saEsfy read request?
S5
Writer (also reads)
S1 S2 S3 S4 S5 S6
R
![Page 41: Replicated*DataConsistency* Explained*Through*Baseball*db.cs.duke.edu/courses/spring15/cps210/slides/consistency.pdf · Key-value stores • Many mega-services are built on key-value](https://reader034.fdocuments.us/reader034/viewer/2022050109/5f46e68851a258045a7cd593/html5/thumbnails/41.jpg)
H’ H H V’ V V’
Writer (also reads)
Reader
Visitors’ score Home score S1 S2 S3 S4 S5 S6
Reader
For baseball, why is read-‐my-‐writes
equivalent to strong consistency, even
though it is “weaker”?
ApplicaEon only has one writer. Not true in
general.
R
![Page 42: Replicated*DataConsistency* Explained*Through*Baseball*db.cs.duke.edu/courses/spring15/cps210/slides/consistency.pdf · Key-value stores • Many mega-services are built on key-value](https://reader034.fdocuments.us/reader034/viewer/2022050109/5f46e68851a258045a7cd593/html5/thumbnails/42.jpg)
Example 1: score keeper
Common theme: (1) Consider applicaEon invariants (2) Reason about what store must
ensure to support applicaEon invariants
Write (“home”, 1); Write (“visitors”, 1); Write (“home”, 2); Write (“home”, 3); Write (“visitors”, 2); Write (“home”, 4); Write (“home”, 5);
Visitors = 2 Home = 5
![Page 43: Replicated*DataConsistency* Explained*Through*Baseball*db.cs.duke.edu/courses/spring15/cps210/slides/consistency.pdf · Key-value stores • Many mega-services are built on key-value](https://reader034.fdocuments.us/reader034/viewer/2022050109/5f46e68851a258045a7cd593/html5/thumbnails/43.jpg)
Example 2: umpire
if first half of 9th inning complete then vScore = Read (“visitors”); hScore = Read (“home”); if vScore < hScore end game;
Idea: home team doesn’t need another chance to bat if they are already ahead
going into final half inning
![Page 44: Replicated*DataConsistency* Explained*Through*Baseball*db.cs.duke.edu/courses/spring15/cps210/slides/consistency.pdf · Key-value stores • Many mega-services are built on key-value](https://reader034.fdocuments.us/reader034/viewer/2022050109/5f46e68851a258045a7cd593/html5/thumbnails/44.jpg)
Example 2: umpire
if first half of 9th inning complete then vScore = Read (“visitors”); hScore = Read (“home”); if vScore < hScore end game;
What invariant must the umpire uphold?
Game should end if home team leads going into final half
inning.
![Page 45: Replicated*DataConsistency* Explained*Through*Baseball*db.cs.duke.edu/courses/spring15/cps210/slides/consistency.pdf · Key-value stores • Many mega-services are built on key-value](https://reader034.fdocuments.us/reader034/viewer/2022050109/5f46e68851a258045a7cd593/html5/thumbnails/45.jpg)
Example 2: umpire
if first half of 9th inning complete then vScore = Read (“visitors”); hScore = Read (“home”); if vScore < hScore end game;
What subset of writes must be visible to the umpire to ensure
game ends appropriately?
Reads must show effect of all prior
writes (strong consistency)
![Page 46: Replicated*DataConsistency* Explained*Through*Baseball*db.cs.duke.edu/courses/spring15/cps210/slides/consistency.pdf · Key-value stores • Many mega-services are built on key-value](https://reader034.fdocuments.us/reader034/viewer/2022050109/5f46e68851a258045a7cd593/html5/thumbnails/46.jpg)
Example 2: umpire
if first half of 9th inning complete then vScore = Read (“visitors”); hScore = Read (“home”); if vScore < hScore end game; Would read-‐my-‐
writes work as it did for the score keeper?
No, since the umpire doesn’t issue any
writes
![Page 47: Replicated*DataConsistency* Explained*Through*Baseball*db.cs.duke.edu/courses/spring15/cps210/slides/consistency.pdf · Key-value stores • Many mega-services are built on key-value](https://reader034.fdocuments.us/reader034/viewer/2022050109/5f46e68851a258045a7cd593/html5/thumbnails/47.jpg)
Example 3: radio reporter
do { vScore = Read (“visitors”); hScore = Read (“home”); report vScore, hScore; sleep (30 minutes); }
Idea: periodically read score and broadcast it to listeners
![Page 48: Replicated*DataConsistency* Explained*Through*Baseball*db.cs.duke.edu/courses/spring15/cps210/slides/consistency.pdf · Key-value stores • Many mega-services are built on key-value](https://reader034.fdocuments.us/reader034/viewer/2022050109/5f46e68851a258045a7cd593/html5/thumbnails/48.jpg)
Example 3: radio reporter
do { vScore = Read (“visitors”); hScore = Read (“home”); report vScore, hScore; sleep (30 minutes); }
What invariants must the radio reporter
uphold?
Should only report scores that actually occurred, and score should monotonically
increase
![Page 49: Replicated*DataConsistency* Explained*Through*Baseball*db.cs.duke.edu/courses/spring15/cps210/slides/consistency.pdf · Key-value stores • Many mega-services are built on key-value](https://reader034.fdocuments.us/reader034/viewer/2022050109/5f46e68851a258045a7cd593/html5/thumbnails/49.jpg)
Example 3: radio reporter
do { vScore = Read (“visitors”); hScore = Read (“home”); report vScore, hScore; sleep (30 minutes); }
Do we need strong consistency?
No, since listeners can accept slightly old
scores.
![Page 50: Replicated*DataConsistency* Explained*Through*Baseball*db.cs.duke.edu/courses/spring15/cps210/slides/consistency.pdf · Key-value stores • Many mega-services are built on key-value](https://reader034.fdocuments.us/reader034/viewer/2022050109/5f46e68851a258045a7cd593/html5/thumbnails/50.jpg)
Example 3: radio reporter
do { vScore = Read (“visitors”); hScore = Read (“home”); report vScore, hScore; sleep (30 minutes); }
Can we get away with eventual consistency (some subset of writes
is visible)?
No, eventual consistency can return
scores that never occurred.
![Page 51: Replicated*DataConsistency* Explained*Through*Baseball*db.cs.duke.edu/courses/spring15/cps210/slides/consistency.pdf · Key-value stores • Many mega-services are built on key-value](https://reader034.fdocuments.us/reader034/viewer/2022050109/5f46e68851a258045a7cd593/html5/thumbnails/51.jpg)
Example 3: radio reporter
Write (“home”, 1); Write (“visitors”, 1); Write (“home”, 2); Write (“home”, 3); Write (“visitors”, 2); Write (“home”, 4); Write (“home”, 5);
Visitors = 2 Home = 5
Under eventual consistency, what
possible scores could the radio reporter read a]er this write
completes?
0-‐0, 0-‐1, 0-‐2, 0-‐4, 0-‐5, 1-‐0, … 2-‐4, 2-‐5
![Page 52: Replicated*DataConsistency* Explained*Through*Baseball*db.cs.duke.edu/courses/spring15/cps210/slides/consistency.pdf · Key-value stores • Many mega-services are built on key-value](https://reader034.fdocuments.us/reader034/viewer/2022050109/5f46e68851a258045a7cd593/html5/thumbnails/52.jpg)
H H H V V V
Score keeper
Radio reporte
r
W1 W3
Visitors’ score Home score
W2
S1 S2 S3 S4 S5 S6
Reader
![Page 53: Replicated*DataConsistency* Explained*Through*Baseball*db.cs.duke.edu/courses/spring15/cps210/slides/consistency.pdf · Key-value stores • Many mega-services are built on key-value](https://reader034.fdocuments.us/reader034/viewer/2022050109/5f46e68851a258045a7cd593/html5/thumbnails/53.jpg)
H=2 H=1 H=0 V=0 V=0 V=1
Score keeper
Radio reporte
r
Visitors’ score Home score S1 S2 S3 S4 S5 S6
Reader
How could reporter read a score of 1-‐0?
![Page 54: Replicated*DataConsistency* Explained*Through*Baseball*db.cs.duke.edu/courses/spring15/cps210/slides/consistency.pdf · Key-value stores • Many mega-services are built on key-value](https://reader034.fdocuments.us/reader034/viewer/2022050109/5f46e68851a258045a7cd593/html5/thumbnails/54.jpg)
H=2 H=1 H=0 V=0 V=0 V=1
Score keeper
Radio reporte
r
Visitors’ score Home score S1 S2 S3 S4 S5 S6
Reader
R R
1-‐0
![Page 55: Replicated*DataConsistency* Explained*Through*Baseball*db.cs.duke.edu/courses/spring15/cps210/slides/consistency.pdf · Key-value stores • Many mega-services are built on key-value](https://reader034.fdocuments.us/reader034/viewer/2022050109/5f46e68851a258045a7cd593/html5/thumbnails/55.jpg)
Example 3: radio reporter
do { vScore = Read (“visitors”); hScore = Read (“home”); report vScore, hScore; sleep (30 minutes); }
How about only consistent prefix (some sequence of writes is visible)?
No. Would give us scores that occurred, but not monotonically
increasing.
![Page 56: Replicated*DataConsistency* Explained*Through*Baseball*db.cs.duke.edu/courses/spring15/cps210/slides/consistency.pdf · Key-value stores • Many mega-services are built on key-value](https://reader034.fdocuments.us/reader034/viewer/2022050109/5f46e68851a258045a7cd593/html5/thumbnails/56.jpg)
H H H V V V
Score keeper
Radio reporte
r
W1 W3
Visitors’ score Home score
W2
S1 S2 S3 S4 S5 S6
Reader
![Page 57: Replicated*DataConsistency* Explained*Through*Baseball*db.cs.duke.edu/courses/spring15/cps210/slides/consistency.pdf · Key-value stores • Many mega-services are built on key-value](https://reader034.fdocuments.us/reader034/viewer/2022050109/5f46e68851a258045a7cd593/html5/thumbnails/57.jpg)
H=2 H=1 H=0 V=0 V=0 V=1
Score keeper
Radio reporte
r
Visitors’ score Home score S1 S2 S3 S4 S5 S6
Reader
R R What prefix of writes
is visible?
W1
0-‐1
![Page 58: Replicated*DataConsistency* Explained*Through*Baseball*db.cs.duke.edu/courses/spring15/cps210/slides/consistency.pdf · Key-value stores • Many mega-services are built on key-value](https://reader034.fdocuments.us/reader034/viewer/2022050109/5f46e68851a258045a7cd593/html5/thumbnails/58.jpg)
H=2 H=1 H=0 V=0 V=0 V=1
Score keeper
Radio reporte
r
Visitors’ score Home score S1 S2 S3 S4 S5 S6
Reader
R
R
What prefix of writes is visible?
(iniEal state)
0-‐1
0-‐0
![Page 59: Replicated*DataConsistency* Explained*Through*Baseball*db.cs.duke.edu/courses/spring15/cps210/slides/consistency.pdf · Key-value stores • Many mega-services are built on key-value](https://reader034.fdocuments.us/reader034/viewer/2022050109/5f46e68851a258045a7cd593/html5/thumbnails/59.jpg)
H=2 H=1 H=0 V=0 V=0 V=1
Score keeper
Radio reporte
r
Visitors’ score Home score S1 S2 S3 S4 S5 S6
Reader
R
R What addiEonal guarantee do we
need?
Also need monotonic reads (see increasing subset of writes)
0-‐1
0-‐0
![Page 60: Replicated*DataConsistency* Explained*Through*Baseball*db.cs.duke.edu/courses/spring15/cps210/slides/consistency.pdf · Key-value stores • Many mega-services are built on key-value](https://reader034.fdocuments.us/reader034/viewer/2022050109/5f46e68851a258045a7cd593/html5/thumbnails/60.jpg)
Monotonic reads • Also called “session consistency”
• Reads are grouped under a “session” • What extra state/logic is needed for monotonic reads?
• System has to know which reads are related • Related reads have to be assigned a sequence (i.e., a total order)
• What extra state/logic is needed for read-‐my-‐writes? • System has to know which reads/writes are related • Related reads/writes have to be assigned a total order
• Does read-‐my-‐writes guarantee monotonic reads? • (get into groups for five minutes to discuss)
![Page 61: Replicated*DataConsistency* Explained*Through*Baseball*db.cs.duke.edu/courses/spring15/cps210/slides/consistency.pdf · Key-value stores • Many mega-services are built on key-value](https://reader034.fdocuments.us/reader034/viewer/2022050109/5f46e68851a258045a7cd593/html5/thumbnails/61.jpg)
Example 3: radio reporter
do { vScore = Read (“visitors”); hScore = Read (“home”); report vScore, hScore; sleep (30 minutes); }
Can we get away with bounded staleness
(see all “old” writes)?
If we also have consistent prefix, and as long as bound is
< 30 minutes.
![Page 62: Replicated*DataConsistency* Explained*Through*Baseball*db.cs.duke.edu/courses/spring15/cps210/slides/consistency.pdf · Key-value stores • Many mega-services are built on key-value](https://reader034.fdocuments.us/reader034/viewer/2022050109/5f46e68851a258045a7cd593/html5/thumbnails/62.jpg)
Example 3: radio reporter
T0 Read (“home”); T1 Read (“visitors”); T2 sleep (30 minutes); T3 Read (“home”); T4 Read (“visitors”); T5 sleep (30 minutes); T6 Read (“visitors”); T7 Read (“home”); T8 sleep (30 minutes); …
Under bounded staleness (bound = 15
minutes, no consistent prefix), what writes must these reads reflect?
Any write that occurred before T3 – 15 minutes
![Page 63: Replicated*DataConsistency* Explained*Through*Baseball*db.cs.duke.edu/courses/spring15/cps210/slides/consistency.pdf · Key-value stores • Many mega-services are built on key-value](https://reader034.fdocuments.us/reader034/viewer/2022050109/5f46e68851a258045a7cd593/html5/thumbnails/63.jpg)
Example 3: radio reporter
T0 Read (“home”); T1 Read (“visitors”); T2 sleep (30 minutes); T3 Read (“home”); T4 Read (“visitors”); T5 sleep (30 minutes); T6 Read (“visitors”); T7 Read (“home”); T8 sleep (30 minutes); …
Why isn’t unbounded staleness by itself
sufficient?
Score must reflect writes that occurred
before T3 – (15 minutes), could also reflect more recent writes
![Page 64: Replicated*DataConsistency* Explained*Through*Baseball*db.cs.duke.edu/courses/spring15/cps210/slides/consistency.pdf · Key-value stores • Many mega-services are built on key-value](https://reader034.fdocuments.us/reader034/viewer/2022050109/5f46e68851a258045a7cd593/html5/thumbnails/64.jpg)
H=0 H=0 H=0 V=0 V=0 V=0
Score keeper
Radio reporte
r
Visitors’ score Home score S1 S2 S3 S4 S5 S6
Reader
R R
0-‐0
Sleep 30 minutes
![Page 65: Replicated*DataConsistency* Explained*Through*Baseball*db.cs.duke.edu/courses/spring15/cps210/slides/consistency.pdf · Key-value stores • Many mega-services are built on key-value](https://reader034.fdocuments.us/reader034/viewer/2022050109/5f46e68851a258045a7cd593/html5/thumbnails/65.jpg)
H=0 H=0 H=0 V=0 V=0 V=0
Score keeper
Radio reporte
r
W1 W3
Visitors’ score Home score
W2
S1 S2 S3 S4 S5 S6
Reader 0-‐0
Wake up in 10
minutes
![Page 66: Replicated*DataConsistency* Explained*Through*Baseball*db.cs.duke.edu/courses/spring15/cps210/slides/consistency.pdf · Key-value stores • Many mega-services are built on key-value](https://reader034.fdocuments.us/reader034/viewer/2022050109/5f46e68851a258045a7cd593/html5/thumbnails/66.jpg)
H=2 H=1 H=0 V=0 V=0 V=1
Score keeper
Radio reporte
r
Visitors’ score Home score S1 S2 S3 S4 S5 S6
Reader
Under bounded staleness, what writes can a reporter see?
W1, W2, and W3
0-‐0
Wake up!
![Page 67: Replicated*DataConsistency* Explained*Through*Baseball*db.cs.duke.edu/courses/spring15/cps210/slides/consistency.pdf · Key-value stores • Many mega-services are built on key-value](https://reader034.fdocuments.us/reader034/viewer/2022050109/5f46e68851a258045a7cd593/html5/thumbnails/67.jpg)
H=2 H=1 H=0 V=0 V=0 V=1
Score keeper
Radio reporte
r
Visitors’ score Home score S1 S2 S3 S4 S5 S6
Reader
R
R
0-‐1
0-‐2
![Page 68: Replicated*DataConsistency* Explained*Through*Baseball*db.cs.duke.edu/courses/spring15/cps210/slides/consistency.pdf · Key-value stores • Many mega-services are built on key-value](https://reader034.fdocuments.us/reader034/viewer/2022050109/5f46e68851a258045a7cd593/html5/thumbnails/68.jpg)
H=2 H=1 H=0 V=0 V=0 V=1
Score keeper
Radio reporte
r
Visitors’ score Home score S1 S2 S3 S4 S5 S6
Reader
R
What addiEonal guarantee do we
need?
Also need monotonic reads (see increasing subset of writes)
0-‐1
0-‐2
R
![Page 69: Replicated*DataConsistency* Explained*Through*Baseball*db.cs.duke.edu/courses/spring15/cps210/slides/consistency.pdf · Key-value stores • Many mega-services are built on key-value](https://reader034.fdocuments.us/reader034/viewer/2022050109/5f46e68851a258045a7cd593/html5/thumbnails/69.jpg)
Example 4: game-‐recap writer
while not end of game { drink beer; smoke cigar; } do out to dinner; vScore = Read (“visitors”); hScore = Read (“home”); write recap;
Idea: write about game several hours a]er it has ended
![Page 70: Replicated*DataConsistency* Explained*Through*Baseball*db.cs.duke.edu/courses/spring15/cps210/slides/consistency.pdf · Key-value stores • Many mega-services are built on key-value](https://reader034.fdocuments.us/reader034/viewer/2022050109/5f46e68851a258045a7cd593/html5/thumbnails/70.jpg)
Example 4: game-‐recap writer
while not end of game { drink beer; smoke cigar; } do out to dinner; vScore = Read (“visitors”); hScore = Read (“home”); write recap;
What invariant must the recapper uphold?
Reads must reflect all writes.
![Page 71: Replicated*DataConsistency* Explained*Through*Baseball*db.cs.duke.edu/courses/spring15/cps210/slides/consistency.pdf · Key-value stores • Many mega-services are built on key-value](https://reader034.fdocuments.us/reader034/viewer/2022050109/5f46e68851a258045a7cd593/html5/thumbnails/71.jpg)
Example 4: game-‐recap writer
while not end of game { drink beer; smoke cigar; } do out to dinner; vScore = Read (“visitors”); hScore = Read (“home”); write recap;
What consistency guarantees could she
use?
Strong consistency or bounded staleness w/ bound < Eme to eat
dinner
![Page 72: Replicated*DataConsistency* Explained*Through*Baseball*db.cs.duke.edu/courses/spring15/cps210/slides/consistency.pdf · Key-value stores • Many mega-services are built on key-value](https://reader034.fdocuments.us/reader034/viewer/2022050109/5f46e68851a258045a7cd593/html5/thumbnails/72.jpg)
Example 4: game-‐recap writer
while not end of game { drink beer; smoke cigar; } do out to dinner; vScore = Read (“visitors”); hScore = Read (“home”); write recap;
What about eventual consistency?
Probably OK most of the Eme. Bounded to ensure you always get
right output.
![Page 73: Replicated*DataConsistency* Explained*Through*Baseball*db.cs.duke.edu/courses/spring15/cps210/slides/consistency.pdf · Key-value stores • Many mega-services are built on key-value](https://reader034.fdocuments.us/reader034/viewer/2022050109/5f46e68851a258045a7cd593/html5/thumbnails/73.jpg)
Example 5: team staZsZcian
wait for end of game; hScore = Read (“home”); stat = Read (“season-runs”); Write (“season-runs”, stat + hScore);
What invariants must staEsEcian uphold?
Season-‐runs increases monotonically by
amount home team scored at the end of
the game
![Page 74: Replicated*DataConsistency* Explained*Through*Baseball*db.cs.duke.edu/courses/spring15/cps210/slides/consistency.pdf · Key-value stores • Many mega-services are built on key-value](https://reader034.fdocuments.us/reader034/viewer/2022050109/5f46e68851a258045a7cd593/html5/thumbnails/74.jpg)
Example 5: team staZsZcian
wait for end of game; hScore = Read (“home”); stat = Read (“season-runs”); Write (“season-runs”, stat + hScore);
What consistency is appropriate for this
read?
Could use strong consistency, bounded
staleness (with appropriate bound), maybe eventual consistency
![Page 75: Replicated*DataConsistency* Explained*Through*Baseball*db.cs.duke.edu/courses/spring15/cps210/slides/consistency.pdf · Key-value stores • Many mega-services are built on key-value](https://reader034.fdocuments.us/reader034/viewer/2022050109/5f46e68851a258045a7cd593/html5/thumbnails/75.jpg)
Example 5: team staZsZcian
wait for end of game; hScore = Read (“home”); stat = Read (“season-runs”); Write (“season-runs”, stat + hScore);
What consistency is appropriate for this
read?
Could use strong consistency, bounded staleness, or read-‐my-‐writes if staEsEcian is
only writer
![Page 76: Replicated*DataConsistency* Explained*Through*Baseball*db.cs.duke.edu/courses/spring15/cps210/slides/consistency.pdf · Key-value stores • Many mega-services are built on key-value](https://reader034.fdocuments.us/reader034/viewer/2022050109/5f46e68851a258045a7cd593/html5/thumbnails/76.jpg)
• Geo-‐replicated stores face fundamental limits common to all distributed systems.
• FLP result: consensus is impossible in asynchronous distributed systems. • Distributed systems may “partly fail”, and the network may block or delay network traffic arbitrarily.
• In parZcular, a network parZZon may cause a “split brain” in which parts of the system funcZon without an ability to contact other parts of the system (see material on leases).
• Example of consensus: what was the last value wri;en for X? • Popular form of FLP: “Brewer’s conjecture” also known as
“CAP theorem”. • We can build systems that are CA, CP, or AP, but we cannot have all three properZes at once, ever.
• To a large extent these limits drive the consistency models.
• (Following slides by Chase)
![Page 77: Replicated*DataConsistency* Explained*Through*Baseball*db.cs.duke.edu/courses/spring15/cps210/slides/consistency.pdf · Key-value stores • Many mega-services are built on key-value](https://reader034.fdocuments.us/reader034/viewer/2022050109/5f46e68851a258045a7cd593/html5/thumbnails/77.jpg)
C-A-P choose
two
C
A P
consistency
Availability Partition-resilience
CA: available, and consistent, unless there is a partition.
AP: a reachable replica provides service even in a partition, but may be inconsistent.
CP: always consistent, even in a partition, but a reachable replica may deny service if it is unable to agree with the others (e.g., quorum).
Dr. Eric Brewer
“CAP theorem”
![Page 78: Replicated*DataConsistency* Explained*Through*Baseball*db.cs.duke.edu/courses/spring15/cps210/slides/consistency.pdf · Key-value stores • Many mega-services are built on key-value](https://reader034.fdocuments.us/reader034/viewer/2022050109/5f46e68851a258045a7cd593/html5/thumbnails/78.jpg)
Fischer-Lynch-Patterson (1985) • No consensus can be guaranteed in an
asynchronous system in the presence of failures. • Intuition: a “failed” process may just be slow, and
can rise from the dead at exactly the wrong time. • Consensus may occur recognizably, rarely or often.
Network partition Split brain
![Page 79: Replicated*DataConsistency* Explained*Through*Baseball*db.cs.duke.edu/courses/spring15/cps210/slides/consistency.pdf · Key-value stores • Many mega-services are built on key-value](https://reader034.fdocuments.us/reader034/viewer/2022050109/5f46e68851a258045a7cd593/html5/thumbnails/79.jpg)
Getting precise about CAP #1
• What does consistency mean? • Consistency à Ability to implement an atomic data
object served by multiple nodes. • Requires linearizability of ops on the object. – Total order for all operations, consistent with causal
order, observed by all nodes – Also called one-copy serializability (1SR): object
behaves as if there is only one copy, with operations executing in sequence.
– Also called atomic consistency (“atomic”) Brewer’s Conjecture and the Feasibility of Consistent, Available, Partition-Tolerant Web Services. Seth Gilbert, Nancy Lynch. MIT manuscript.
![Page 80: Replicated*DataConsistency* Explained*Through*Baseball*db.cs.duke.edu/courses/spring15/cps210/slides/consistency.pdf · Key-value stores • Many mega-services are built on key-value](https://reader034.fdocuments.us/reader034/viewer/2022050109/5f46e68851a258045a7cd593/html5/thumbnails/80.jpg)
Getting precise about CAP #2
• Availability à Every request received by a node must result in a response. – Every algorithm used by the service must
terminate. • Network partition à Network loses or delays
arbitrary runs of messages between arbitrary pairs of nodes. – Asynchronous network model assumed – Service consists of at least two nodes
Brewer’s Conjecture and the Feasibility of Consistent, Available, Partition-Tolerant Web Services. Seth Gilbert, Nancy Lynch. MIT manuscript.
![Page 81: Replicated*DataConsistency* Explained*Through*Baseball*db.cs.duke.edu/courses/spring15/cps210/slides/consistency.pdf · Key-value stores • Many mega-services are built on key-value](https://reader034.fdocuments.us/reader034/viewer/2022050109/5f46e68851a258045a7cd593/html5/thumbnails/81.jpg)
Getting precise about CAP #3
• Theorem. It is impossible to implement an atomic data object that is available in all executions. – Proof. Partition the network. A write on one side
is not seen by a read on the other side, but the read must return a response.
• Corollary. Applies even if messages are delayed arbitrarily, but no message is lost. – Proof. The service cannot tell the difference.
Brewer’s Conjecture and the Feasibility of Consistent, Available, Partition-Tolerant Web Services. Seth Gilbert, Nancy Lynch. MIT manuscript.
![Page 82: Replicated*DataConsistency* Explained*Through*Baseball*db.cs.duke.edu/courses/spring15/cps210/slides/consistency.pdf · Key-value stores • Many mega-services are built on key-value](https://reader034.fdocuments.us/reader034/viewer/2022050109/5f46e68851a258045a7cd593/html5/thumbnails/82.jpg)
Getting precise about CAP #4
• Atomic and partition-tolerant – Trivial: ignore all requests. – Or: pick a primary to execute all requests
• Atomic and available. – Multi-node case not discussed. – But use the primary approach. – Need a terminating algorithm to select the
primary. Does not require a quorum if no partition can occur. Left as an exercise.
Brewer’s Conjecture and the Feasibility of Consistent, Available, Partition-Tolerant Web Services. Seth Gilbert, Nancy Lynch. MIT manuscript.
![Page 83: Replicated*DataConsistency* Explained*Through*Baseball*db.cs.duke.edu/courses/spring15/cps210/slides/consistency.pdf · Key-value stores • Many mega-services are built on key-value](https://reader034.fdocuments.us/reader034/viewer/2022050109/5f46e68851a258045a7cd593/html5/thumbnails/83.jpg)
Getting precise about CAP #5
• Available and partition-tolerant – Trivial: ignore writes; return initial value for reads. – Or: make a best effort to propagate writes among
the replicas; reads return any value at hand.
Brewer’s Conjecture and the Feasibility of Consistent, Available, Partition-Tolerant Web Services. Seth Gilbert, Nancy Lynch. MIT manuscript.
![Page 84: Replicated*DataConsistency* Explained*Through*Baseball*db.cs.duke.edu/courses/spring15/cps210/slides/consistency.pdf · Key-value stores • Many mega-services are built on key-value](https://reader034.fdocuments.us/reader034/viewer/2022050109/5f46e68851a258045a7cd593/html5/thumbnails/84.jpg)
Quorum
• How to build a replicated store that is atomic (consistent) always, and available unless there is a partition? – Read and write operations complete only if they are
acknowledged by some minimum number (a quorum) of replicas.
– Set the quorum size so that any read set is guaranteed to overlap with any write set.
– This property is sufficient to ensure that any read “sees” the value of the “latest” write.
– So it ensures consistency, but it must deny service if “too many” replicas fail or become unreachable.
![Page 85: Replicated*DataConsistency* Explained*Through*Baseball*db.cs.duke.edu/courses/spring15/cps210/slides/consistency.pdf · Key-value stores • Many mega-services are built on key-value](https://reader034.fdocuments.us/reader034/viewer/2022050109/5f46e68851a258045a7cd593/html5/thumbnails/85.jpg)
Quorum consistency
[Keith Marzullo]
rv=wv=f n=2f+1
![Page 86: Replicated*DataConsistency* Explained*Through*Baseball*db.cs.duke.edu/courses/spring15/cps210/slides/consistency.pdf · Key-value stores • Many mega-services are built on key-value](https://reader034.fdocuments.us/reader034/viewer/2022050109/5f46e68851a258045a7cd593/html5/thumbnails/86.jpg)
Weighted quorum voting
[Keith Marzullo]
Any write quorum must intersect every other quorum.
rv+wv=n+1