cap
cap theorem• Eric Brewer (ex-Inktomi)• Proved by Lynch and Gilbert
cap theoremIt is impossible in the asynchrounous network    model to implement a read/write object    that garantuees the ...
AP vs CP• Real choices are • Available - Partition • Consistent - Partion
AP• Multiple Nodes participate in writes• System will be Eventually Consistent • Storage System guarantees if there are no...
eventual consistency                        Master               Slave              Slave               Client            ...
eventual consistency                       Master              Slave             Slave              Client            Clie...
eventual consistency• Monotonic read consistency• Pin client to certain slave / app server • Failover still fails
multi masterDynamo modelR - number of servers to read fromW - number of servers to get response fromN - Replication Factor...
multi masterExample 1             Example 2R + W <= N            R +W > NR=1                   R=2         R =1W=1        ...
R +W > N      If R + W > N you can’t both     have fast local reads and writes
network partitions
trivial network    partition
network write        possibilities• deny all writes • read fully consistent data• allow writes on one side • allow reads o...
multiple writer strategies •   Last one wins     •   vector clocks •   Insert     •   insert often means:         •   if (...
deleteop1: set joe, age 40op2: delete joeop3: set joe, 41- consider switching 2 and 3- tombstone: remember delete and appl...
multiple writer strategies•   programmatic merge    •   store ops instead of state    •   replay operations        •   did...
CP• Sometimes we need global state• Unique - constraints• User registration• ACL changes
Finallyuptime(CP + average developer)>=uptime(AP + average developer)Where uptime is the system is up and non-buggy
Upcoming SlideShare
Loading in …5
×

Thoughts on consistency models

1,574
-1

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,574
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
  1. A particular slide catching your eye?

    Clipping is a handy way to collect important slides you want to go back to later.

×