But choosing consistency over availability in all cases is not an answer, one is not a strictly superior choice over another, as he article proposes.
At one level striving for consistency in a large distributed system is fighting with the laws of physics. It has been attempted and so far Google probably has a better handle on it but it requires tight coupling with a time synchronization service.
> Choosing consistency is hardly a radical idea
_Claiming_ to choose it is not radical. Actually doing it, is. If you read the "Call me maybe" you'd see that most of supposed consistent databases fail. Granted that measures partition tolerance but at the same time usually that is not a choice to be made (according to the author Aphyr).
> Indeed even Riak, the biggest advocate of eventual consistency, is working hard to build strong consistency into Riak 2.0.
That is what I've heard. Consistency for some data is the right choice, no argument there. At the same time they are _not_ throwing away or switching away from eventual consistency.
In fact they are the database that when preserving conflicted siblings actually did better than most in "Call me maybe" series. CouchDB is another database that does this right. It preserves merge conflicts explicitly during replication. Users can chose to ignore them but it doesn't arbitrary throw data away. It is not in the series because replication and cluster topology is user defined and managed so there is no default, single distributed cluster setup.
Most of the failures of databases come from trying to sweep under the rug effects of conflicts in eventually consistency. Even Riak's last-write-wins did that. MongoDB and others failed too. That doesn't mean eventual consistency is flawed. Eventual consistency is a physical reality, and in some case it is also a viable business application pattern.
This reminds me of a paper I read in college, "The Dangers of Replication."[1] It lays out the fundamental limits on distributed updates, and it's a good one to read if you haven't seen it before.
That is a pretty good paper. 1996. What it talks about is relevant. CAP wasn't talked about and distributed databases where not the topic of casual conversations between developers.
It mentions Lotus Notes. As a piece of trivia, the creator of CouchDB (Damien Katz) originally worked on Lotus Notes (at IBM). Then created CouchDB in his spare time. I believe its design is influenced by Lotus Notes quite a bit.
It wasn't a new paper when I took the class, either. None of the papers I read for that class were new. I took the fact that it was assigned reading to mean that the professor considered it timeless.
At one level striving for consistency in a large distributed system is fighting with the laws of physics. It has been attempted and so far Google probably has a better handle on it but it requires tight coupling with a time synchronization service.
> Choosing consistency is hardly a radical idea
_Claiming_ to choose it is not radical. Actually doing it, is. If you read the "Call me maybe" you'd see that most of supposed consistent databases fail. Granted that measures partition tolerance but at the same time usually that is not a choice to be made (according to the author Aphyr).
> Indeed even Riak, the biggest advocate of eventual consistency, is working hard to build strong consistency into Riak 2.0.
That is what I've heard. Consistency for some data is the right choice, no argument there. At the same time they are _not_ throwing away or switching away from eventual consistency.
In fact they are the database that when preserving conflicted siblings actually did better than most in "Call me maybe" series. CouchDB is another database that does this right. It preserves merge conflicts explicitly during replication. Users can chose to ignore them but it doesn't arbitrary throw data away. It is not in the series because replication and cluster topology is user defined and managed so there is no default, single distributed cluster setup.
Most of the failures of databases come from trying to sweep under the rug effects of conflicts in eventually consistency. Even Riak's last-write-wins did that. MongoDB and others failed too. That doesn't mean eventual consistency is flawed. Eventual consistency is a physical reality, and in some case it is also a viable business application pattern.