Submitted <a href="http://news.ycombinator.com/item?id=1191075" rel="nofollow">http://news.ycombinator.com/item?id=1191075</a> because a lot of people in this thread could use an explanation of what CAP actually means. :)
This doesn't look entirely right to me.<p>Some comments:<p>Some RDBMS actual perform background asynchronous replication. If you're doing your reads from slaved replicas, you've got an "eventually consistent" system ("A{possibly, P}"). If you're only doing reads from the master node, you're no longer highly available. If you're "promoting" slaves in the case of a master failing, you're _AT_ best back to the case of eventual consistency (if the master comes back and the replication backlog is replayed correctly) or you might not be consistent at all. To echo others, let's call this "potential consistency".<p>Eventual consistency isn't something Amazon decided to make up, we've dealt with eventually consistent systems on a daily basis long before (DNS, usenet, some distributed file systems, etc...).<p>BigTable and co. are not "CP" and much more true to the "CA" definition than say MySQL replication or Postgres + Slony. They use protocols like Paxos with leases (BigTable) and Zab (used by ZooKeeper based systems). These are modified 3PC protocols: unlike 2PC protocols, they still guarantee fault tolerance ("A") even if the coordinator node fails; unlike pure 3PC protocols they offer certain guarantees of liveliness (e.g., through the use of leases) and even some degree of partition tolerance. Still, Google had to build Spanner on top of BigTable to provide partition tolerance / true multi-datacenter operation.
Given that it's been proven that there is a tradeoff between C, A, and P, this triangle is a good idea, one of those ideas that is obvious as soon as you see it (but not before).<p>It's fascinating how much disagreement there is in the comments, here and in the OP, about where to place the various systems. We know that a system can't occupy more than one edge, yet apparently it's non-trivial in several cases to decide which. I wonder why? Are people are defining terms differently? Are some of the systems themselves poorly specified?
I'm not familiar with some of the solutions, but some of them got me wondering:<p>- Why is Tokyo Cabinet on the AP line? It's not distributed in any way by itself. It's protected by a single write lock, so it's definitely consistent. If they mean Tokyo Tyrant which provides a simple way of replication (even master-master replication), then...<p>- Why is MySQL <i>only</i> on AC line? If you do master-master setup with it, it could be on the AP line too. (and probably any relational db that does replication / clustering)
You can tune Riak to have whichever your qualities you need with its NRW values. N is the number of replicas of your data which can be specified per-bucket. R is the number of nodes that have to successfully respond to a read operation before it's considered to succeed overall, and W is the number of nodes that must respond to a write. R and W are specified with each read and write operation which is quite flexible.<p>If you want consistency you push R and W closer to N. If you need availability and partition tolerance then you lower R and W. You get to choose the mix of CAP that you need, for each bucket and each request.<p>I'm a Riak noob but this is my understanding of the system so far.
Oracle Coherence (formerly Tangosol) can be configured to be more or less anywhere you like on this triangle, including persisting everything to disk. Makes me sad that it's so expensive, and it chats a lot if you replicate fast-changing data across too many nodes, but man it sure is nice to have around.
I could be wrong but it seems like MongoDB isn't really partition tolerant since it relies on replication or sharding (just like an RDMS). I think it is more of an AC (with a caveat on the C)
Not entirely sure why Postgres, MySQL are in a NoSQL guide -- maybe the title should be different? Interesting chart to look at, though.<p>FWIW: yourtinnitus.com is down right now.