The “Consistency, Not Accuracy” Principle
Preamble: Read my post “The CAP Theorem distilled”
In my previous post, I started talking about the “Consistency, Not Accuracy” Principle (a.k.a. The CNA Principle)
Essentially, in order to scale your web site and to keep running amidst unpredictable network and system outages, you need to have a replicated, fault-tolerant data store that accepts reads and writes in multiple locations. One replica might be in California and another might be in Virginia. If California were to fall into the great Pacific, your web site should still work and your users should be none the wiser.
However, this distributed data store design now presents the following predicament: How do you keep your replicas in Virginia and California in sync? Also, what does “in sync” actually mean?
As described in my earlier post, throughput and latency don’t scale for 2-phase commit (a.k.a. 2PC) or other forms of pessimistic synchronous replication (e.g. fault tolerant causal broadcasts). In order to have a highly-available system, some portion of writes need to be executed asynchronously. Hence some number of data inconsistencies will arise after writes commit.
Resolving these inconsistencies, a complex task, can be made simpler if we accept the CNA principle. Essentially, it is more important for the data to be consistent between these two data store replicas (i.e. Virginia and California) than for the data to reflect the most recent update to the system (i.e. be accurate).
For example, say you changed a blog entry at noon and then again at 12:01 pm. Assume that the modifications were different. According to this principle, it is possible for one of your changes to be lost. Also, the one that is lost might be the most recent edit.
A system in which accuracy is required, such as a financial application, is vastly more complex and can require causal ordering (e.g. vector clocks), read repair, quorums, etc….
Building a system that follows CNA is vastly simpler to understand and implement. If your site’s business model supports it (which it probably will), then I recommend it.
In a future post, I’ll go into my specific experience with the CNA Principle.
-
rooksfury posted this
nosql
sharadag
boredandroid