Twitter Conversation about CAP

I am capturing a brief Twitter conversation about the CAP Theorem here. I’ll try to follow up with a longer post about the misconceptions that seem to float around about the CAP Theorem.

This diagram is interesting but somehow strikes me as a bit misguided: #NoSQL
3:25 PM Mar 14th via web

I agree that the systems listed under “AP” lack strong consistency. But the division between the “CA” and “CP” systems seems wrong #NoSQL
3:27 PM Mar 14th via web

Those systems have individually varying points where availability breaks down under network partitioning (and other kinds of faults). #NoSQL
3:31 PM Mar 14th via web

And my impression is that the NoSQL (“CP”) systems are generally more fault tolerant than the RDBMS (“CA”) systems. #NoSQL
3:32 PM Mar 14th via web

But the diagram creates the mistaken impression that RDBMS are “more available” than NoSQL, which is simply not the case AFIACT #NoSQL
3:34 PM Mar 14th via web

@chad_walters Just a few letters mixed up a bit. BigTable and HBase were CA, not CP last time I checked.
3:29 PM Mar 14th via TweetDeck in reply to chad_walters

@clehene My point is that I don’t think “CA” and “CP” are sensible classifications, at least as I read the formal CAP proof. #NoSQL
3:38 PM Mar 14th via web in reply to clehene

@chad_walters @clehene Every time I say BigTable is CP or CA, I’m told I’m wrong and the other is the truth. #headdesk
3:40 PM Mar 14th via Echofon

@LusciousPear @chad_walters I guess people like taxonomies. It’s just hard to classify things when labels are rather philosophical. #nosql
3:41 PM Mar 14th via TweetDeck in reply to LusciousPear

@LusciousPear Right. I don’t think it is the right distinction. Unlike “fast/cheap/good”, CAP does not mean “pick two”. #NoSQL
3:43 PM Mar 14th via web in reply to LusciousPear

@clehene The CAP theorem has a formal proof: /cc @LusciousPear #NoSQL3:48 PM Mar 14th via web in reply to clehene

@chad_walters @clehene Right. CAP is more like knobs to turn, not blocks to build from.
3:48 PM Mar 14th via Echofon in reply to chad_walters

@LusciousPear Well I see strong consistency as the main choice point. Beyond that you have varying degrees of fault tolerance. /cc @clehene
3:52 PM Mar 14th via web in reply to LusciousPear

@LusciousPear CAP says that weakly consistent systems can maintain A (under the formal definition…) in the face of P /cc @clehene 3:54 PM Mar 14th via web in reply to LusciousPear

@chad_walters @LusciousPear I will soon come out with some reflections about that, just need to polish things a bit 🙂
3:55 PM Mar 14th via TweetDeck

@LusciousPear But is the formal definition of A really the most interesting aspect of fault tolerance? I’m not convinced. /cc @clehene
3:56 PM Mar 14th via web in reply to LusciousPear

@LusciousPear I’m much more interested in practical fault tolerance than in theoretical fault tolerance /cc @clehene
4:03 PM Mar 14th via web

@chad_walters I’m 100% with you. I think certain contexts of A are overrated, and I’d rather have something practical than “elegant”
4:11 PM Mar 14th via Seesmic in reply to chad_walters


2 Responses to “Twitter Conversation about CAP”

  1. 1 Ali Sohani March 17, 2010 at 3:59 am

    Chad, Thanks for compiling them up in a single blog post.

    I believe the notion of Fault-Tolerance lies between both the availability and partition tolerance. Best systems that show case them are definitely AP systems, which are actually distributed and decentralized systems providing us an eventual consistency.

    You are definitely write that diagram does imply somewhat that CA, systems are more available vs CP, but they do so relying on a fact that the high end systems used to serve them without cost of partitioning makes system more available vs. a grid of low-end servers aka a distributed way.

    Summarizing, I second Bradford (@LusciousPear), that consistency is your the main choice, while partitioning and availability are both knobs contributing towards different level/ kind of faults tolerance. Best to treat them like knobs, and NoSQL systems like Dynamo, Cassandra and Riak, allow us to do that. Depending on your context of application and requirement of service you can tune those knobs and have best of all three.

    • 2 chadwa March 17, 2010 at 9:07 am

      First, thanks for your comments and for prompting me to revive the blog.

      I agree that consistency is the main choice point (in fact I think I was the one who said that).

      The notion of having an architecture that allows you to flexibly play with the dials is an appealing one, but it should be recognized that that flexibility comes with a cost.

      You can dial something like Cassandra for consistency but I believe that will cost you pretty heavily in performance, something that is very important for NoSQL systems but that is not captured in CAP at all. So having dials is great, but you need to understand how turning those dials will affect other characteristics you may care about in each architecture.

      If you decide that you can get away without consistency at all, then the systems you mention are reasonable choices.

      My main complaint about the discussion of the CAP Theorem is that many people do not realize that “A” and “P” do not mean exactly what people think they mean (also pointed out by Jeff Darcy’s post ). A “CA” system is not intrinsically more available than a “CP” system, at least not given the layman’s understanding of the term “availability”.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

%d bloggers like this: