Thoughts on consistency models

1,704 views
1,606 views

Published on

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,704
On SlideShare
0
From Embeds
0
Number of Embeds
0
Actions
Shares
0
Downloads
15
Comments
0
Likes
1
Embeds 0
No embeds

No notes for slide

Thoughts on consistency models

  1. 1. cap
  2. 2. cap theorem• Eric Brewer (ex-Inktomi)• Proved by Lynch and Gilbert
  3. 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. 4. AP vs CP• Real choices are • Available - Partition • Consistent - Partion
  5. 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. 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. 7. eventual consistency Master Slave Slave Client ClientHowever, we could get this: 1,2,2,4,2,5
  8. 8. eventual consistency• Monotonic read consistency• Pin client to certain slave / app server • Failover still fails
  9. 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. 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. 11. R +W > N If R + W > N you can’t both have fast local reads and writes
  12. 12. network partitions
  13. 13. trivial network partition
  14. 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. 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. 16. deleteop1: set joe, age 40op2: delete joeop3: set joe, 41- consider switching 2 and 3- tombstone: remember delete and apply last opwins
  17. 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. 18. CP• Sometimes we need global state• Unique - constraints• User registration• ACL changes
  19. 19. Finallyuptime(CP + average developer)>=uptime(AP + average developer)Where uptime is the system is up and non-buggy

×