Eventual Consistency Explained for Techies
Preamble: Have a look at my previous article titled “Eventually Consistency Explained for non-Techies”
Eventual and Weak Consistency
SimpleDB is eventually consistent. Eventual consistency is a version of weak consistency — you may not see the latest writes committed to the system.
Imagine that you have a system of N nodes. Of these, W nodes are involved in any write sent to the system and R nodes are contacted on any read from the system. Strong consistency can be achieved if R+W > N. In other words, if the read sets and write sets overlap, the read can discover the most recent write to the system.
Hence, in order to achieve consistent reads, there are 2 sides to this equation. You can either increase W or increase R to achieve the overlap. There are hence 2 extreme cases:
- Fastest Reads: R=1, W=N
- To read the latest write, only 1 node is contacted. However, writes need to be confirmed at all nodes before they are ACKed back to the client. Write performance suffers.
- Fastest Writes: R=N, W=1
- Only one node is ever involved in a write. All nodes are contacted for the read and a quorum needs to be reached among all nodes. Read performance suffers.
In an eventually consistent system, R+W < N. Read sets and Write sets are not guaranteed to overlap. Reads will not see the latest write in these cases. However, a gossip-style, lazy data propagation mechanism replicates writes to all nodes. Eventually all nodes will be consistent. In cases where there are conflicting versions for a datum, the system will choose one.
-
rooksfury posted this
cornersoftheworld
boredandroid