Client-Centric Consistency
Learned in SE464.
The CAP theorem gives us a tradeoff between consistency and delay. Inconsistency is bothersome (it causes weird bugs), but delay is usually something apps can handle. If we truly need both consistency and timeliness, we must go back to a centralized database.
For a client connected to a distributed (NoSQL) DB cluster, there are three basic client-centric guarantees worth wanting. Together they give linearizability.
Monotonic Reads
If a client reads the value of x, later reads of x by that same client will always return the same value or a more recently written value.
Read Your Writes
If a client writes a value to x, later reads of x by that same client will always return that value or a more recently written value.
Monotonic Writes
If a client writes twice to x, the first write must happen before the second.
Achieving consistency
Two ways:
- Make the client send all requests to one replica node.
- Pro: simplicity.
- Con: consistency problems arise when a node fails (client must switch, and problems return).
- If you don’t care about fault tolerance, avoiding replication gives consistency. MongoDB does not replicate data and thus has C and P but lacks Availability (CAP).
- Make the client wait until the read or write is synchronized across the system.
- Simplest: send the request to all nodes and wait.
- More efficient: use a quorum.