Problems with CAP, and Yahoo’s little known NoSQL system

Classic blog from 2010. The idea didn&#x27;t catch on however, and no one uses these terms. PNUTS is still completely closed source inside Yahoo -- this is because PNUTS depends on an internal queuing system.<p>As for YCSB, it&#x27;s commonly references and is easily available on github. It hasn&#x27;t changed much lately, and now with tools like jepsen that focus on correctness as well as performance, YCSB is no longer the preferred testing tool.

Having implemented and used multiple consistent coordination systems: Raft+ in c5 (I helped write), Single Decree Paxos via DConE at WanDISCO and timeline consistent implementations via HBase, I have to say the academics miss that the devil is in the implementation details. We all focus on high level things like CAP (although FLP is what real hard core academics care about) when system details like how you can aggregate fsyncs, system pauses (Especially with GC) and how you integrate your coordination system into the larger system play a much larger role in overall system latency. The coordination posture is a minor detail when compared to GC issues. Now I know what you are going to say, &quot;He&#x27;s not an academic&quot;. He ran a real DB company. I totally disagree. The DB community in general focuses on the wrong thing. That&#x27;s true in Hadoop, it&#x27;s true with cassandra, and I would bet that it&#x27;s true at google as well.

A classic! If you had to take away one thing from this article, it would be that the CAP theorem (while useful) doesn&#x27;t take into consideration latency, which might be more important than even more important than partition tolerance. Yes, partition tolerance is inevitable, but you have to deal with latency every single time!

The author of CAP himself said that the CAP theorem gained undue popularity. It is an interesting theorem only because it models what partition implies in terms of trade-off when they happen.<p>But partitions are rare. And when partitions happen, generally you can&#x27;t access the partitioned area so a lot of problems disappear.<p>Availability isn&#x27;t an on&#x2F;off switch, there is a wide range of how &quot;available&quot; you can be and what you can do. For example you can allow reads but disallow rights.<p>Last but not least, the most important is what happens after the partition is over and what level of guarantees you offer regarding coherence.

The way I&#x27;ve heard the CAP theorem used practically at a high level is to frame the question as follows:<p>What happens in the case of a (logical) network partition? - an AP system continues taking requests and provides eventual consistency, while a CP system waits for the partition to go away, or says come back later.

I like the author&#x27;s concept of PACELC, though it seems a bit implementation-specific.

title should say (2010)

I don&#x27;t understand what is meant by &quot;this means that the roles of the A and C in CAP are asymmetric&quot; - could someone explain this to me?