Daniel Abadi on NoSQL design tradeoffs
In a thought-provoking post, Daniel Abadi points out NoSQL-related terminological problems similar to the ones I just railed against, and argues
To me, CAP should really be PACELC — if there is a partition (P) how does the system tradeoff between availability and consistency (A and C); else (E) when the system is running as normal in the absence of partitions, how does the system tradeoff between latency (L) and consistency (C)?
and goes on to say
For example, Amazon’s Dynamo (and related systems like Cassandra and SimpleDB) are PA/EL in PACELC — upon a partition, they give up consistency for availability; and under normal operation they give up consistency for lower latency. Giving up C in both parts of PACELC makes the design simpler — once the application is configured to be able to handle inconsistencies, it makes sense to give up consistency for both availability and lower latency.
However, I think Daniel’s improved formulation is still misleading, in at least two ways:
- Daniel implicitly assumes any given NoSQL system makes a fixed set of tradeoffs, when actually — as he in fact notes in his post — some of them offer tradeoffs that are quite tunable.
- I think Daniel is at best oversimplifying when he appears to assert that best-case network latency is an important design criterion for all that many NoSQL systems. Naively, anything that acknowledges reads or writes requires two hops. Two-phase commit (2PC) requires three hops. 33% latency reductions are not the kinds of goals that drive dramatic DBMS redesigns, even though tenths of seconds — i.e. 100s of milliseconds — matter in the kinds of environments where NoSQL is sprouting up.
Comments
2 Responses to “Daniel Abadi on NoSQL design tradeoffs”
Leave a Reply
[…] Daniel Abadi’s views on NoSQL design tradeoffs Categories: Amazon and its cloud, NoSQL, OLTP, Parallelization, Theory and architecture Subscribe to our complete feed! […]
The only part of your criticism I take issue with is the 33% number. Going from >=1 messages over a wide area network to 0 messages over a wide area network (i.e. all replication is done asynchronously instead of in the critical path for a transaction) is a big deal (it can improve latency by a factor of 2X to 10X). This is actually a major design decision for companies like Amazon and Yahoo that need to allow writes from any part of the world. But doing replication asynchronously means lower consistency even when there are no failures or partitions (the ELC part of PACELC).