Cap is Only Part of the Story, we need PACELC

inelpandzic.com

28 points·blopeur··2 comments

This is framed as a new characterization of the properties of database servers, but isn't just about whether the client waits for acknowledgment from the cluster?

It seems completely unrelated to the server's consensus algorithm. Any client for any of those systems can proceed before the transaction is committed, it is faster but means that your transaction might disappear if the wrong node crashes.

How does the author end up with an empty column for "PC/EL" in their table and not realize that "choosing [low] latency" (by not waiting for acknowledgment) is no longer guaranteed consistent?

It's not about whether clients wait for acks, but rather whether participants of the consensus (instances of the database servers, basically) wait for consensus prior to commiting.

If the client doesn't wait until the transaction is commited, a a client cannot 'proceed', as the transaction is not observable in any node. Giving this guarantee of consistency requires consensus among the nodes, and consensus introduces coordination, which introduces latency. That's the basic argument for PACELC.

It is also totally possible, but rare in practice, to design a PC/EL system. The cannonical example by Prof. Abadi is PNUTS: https://dbmsmusings.blogspot.com/2010/04/problems-with-cap-a...

Reply on news.ycombinator.com