Thoughts on consistency models

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

More in: Technology
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Be the first to comment
No Downloads


Total Views
On Slideshare
From Embeds
Number of Embeds



Embeds 0

No embeds

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

    No notes for slide


  • 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