Thoughts on consistency models
Upcoming SlideShare
Loading in...5
×
 

Thoughts on consistency models

on

  • 1,579 views

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.

Statistics

Views

Total Views
1,579
Views on SlideShare
1,579
Embed Views
0

Actions

Likes
1
Downloads
12
Comments
0

0 Embeds 0

No embeds

Accessibility

Categories

Upload Details

Uploaded via as Adobe PDF

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

Thoughts on consistency models Thoughts on consistency models Presentation Transcript

  • 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 following properties: - Availability - Atomic consistency in fair transactions Or: If the network is broken, your database won’t work
  • 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 new updates, all reads will eventually return the same, last updated valueExamples:- DNS- ASync replication- MongoDB with Slave-OK- Memcache
  • eventual consistency Master Slave Slave Client ClientAsuming update 1,2,3,4,5Client will expect 1,2,2,2,3,4,5,5,5
  • eventual consistency Master Slave Slave Client ClientHowever, we could get this: 1,2,2,4,2,5
  • 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 FactorR + W > N has nice properties
  • 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
  • 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 on other side (stale)• allow writes on both sides • give up consistency
  • 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
  • deleteop1: set joe, age 40op2: delete joeop3: set joe, 41- consider switching 2 and 3- tombstone: remember delete and apply last opwins
  • 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
  • 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