Your SlideShare is downloading. ×
Thoughts on consistency models
Thoughts on consistency models
Thoughts on consistency models
Thoughts on consistency models
Thoughts on consistency models
Thoughts on consistency models
Thoughts on consistency models
Thoughts on consistency models
Thoughts on consistency models
Thoughts on consistency models
Thoughts on consistency models
Thoughts on consistency models
Thoughts on consistency models
Thoughts on consistency models
Thoughts on consistency models
Thoughts on consistency models
Thoughts on consistency models
Thoughts on consistency models
Thoughts on consistency models
Upcoming SlideShare
Loading in...5
×

Thanks for flagging this SlideShare!

Oops! An error has occurred.

×
Saving this for later? Get the SlideShare app to save on your phone or tablet. Read anywhere, anytime – even offline.
Text the download link to your phone
Standard text messaging rates apply

Thoughts on consistency models

1,446

Published on

Some thought on the cap theorem, tradeoffs etc. as presented to the melbourne mongodb user group.

Some thought on the cap theorem, tradeoffs etc. as presented to the melbourne mongodb user group.

Published in: Technology
0 Comments
1 Like
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total Views
1,446
On Slideshare
0
From Embeds
0
Number of Embeds
0
Actions
Shares
0
Downloads
14
Comments
0
Likes
1
Embeds 0
No embeds

Report content
Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
No notes for slide

Transcript

  • 1. cap
  • 2. cap theorem• Eric Brewer (ex-Inktomi)• Proved by Lynch and Gilbert
  • 3. cap theoremIt is impossible in the asynchrounous network model to implement a read/write object that garantuees the following properties: - Availability - Atomic consistency in fair transactions Or: If the network is broken, your database won’t work
  • 4. AP vs CP• Real choices are • Available - Partition • Consistent - Partion
  • 5. AP• Multiple Nodes participate in writes• System will be Eventually Consistent • Storage System guarantees if there are no new updates, all reads will eventually return the same, last updated valueExamples:- DNS- ASync replication- MongoDB with Slave-OK- Memcache
  • 6. eventual consistency Master Slave Slave Client ClientAsuming update 1,2,3,4,5Client will expect 1,2,2,2,3,4,5,5,5
  • 7. eventual consistency Master Slave Slave Client ClientHowever, we could get this: 1,2,2,4,2,5
  • 8. eventual consistency• Monotonic read consistency• Pin client to certain slave / app server • Failover still fails
  • 9. multi masterDynamo modelR - number of servers to read fromW - number of servers to get response fromN - Replication FactorR + W > N has nice properties
  • 10. multi masterExample 1 Example 2R + W <= N R +W > NR=1 R=2 R =1W=1 W=1 W=2N=5 N=2 N=2Possibly Stale Data ‘Consistent’ DataHigher Availability
  • 11. R +W > N If R + W > N you can’t both have fast local reads and writes
  • 12. network partitions
  • 13. trivial network partition
  • 14. network write possibilities• deny all writes • read fully consistent data• allow writes on one side • allow reads on other side (stale)• allow writes on both sides • give up consistency
  • 15. multiple writer strategies • Last one wins • vector clocks • Insert • insert often means: • if (!exist(x)) set(x) • exist is hard to implement in eventually consistent systems
  • 16. deleteop1: set joe, age 40op2: delete joeop3: set joe, 41- consider switching 2 and 3- tombstone: remember delete and apply last opwins
  • 17. multiple writer strategies• programmatic merge • store ops instead of state • replay operations • did I get the last one ?• Commutative operations • conflict free • anything that’s foldable
  • 18. CP• Sometimes we need global state• Unique - constraints• User registration• ACL changes
  • 19. Finallyuptime(CP + average developer)>=uptime(AP + average developer)Where uptime is the system is up and non-buggy

×