3 ms·

I think everyone accepts that the CAP theorem (as proved) is true. The issue is what conclusion you draw. The theorem just says you can't be perfect on all th

I think everyone accepts that the CAP theorem (as proved) is true. The issue is what conclusion you draw. The theorem just says you can't be perfect on all three axes. Some people conclude that we must throw everything away, and e.g. use a key-value store. To my mind, that's a bit like learning about random bit-flips, and giving up programming.

mononcqc 13y ago
Here are a few examples: http://nathanmarz.com/blog/how-to-beat-the-cap-theorem.html http://nathanmarz.com/blog/how-to-beat-the-cap-theorem.html http://dominictarr.com/post/44516618714/working-around-the-cap-theorem-with-rumours-db http://dominictarr.com/post/44516618714/working-around-the-c... http://scale-out-blog.blogspot.ca/2012/04/disproving-cap-theorem.html http://scale-out-blog.blogspot.ca/2012/04/disproving-cap-the... Not everyone accepts the CAP theorem yet, or some have an understanding of it that is flawed enough that they think they can beat it.
- justinsb 13y ago
  One of those was posted on April 1st :-) Nathan's post is very interesting - thanks for posting that. He has taken on board the implications of CAP, and built a system (Storm) that is genuinely different. I wish more people did that. If you're going to use CAP to justify building a database but having it be less capable, that's just marketing. If you're going to look at CAP and think "OK, we can't get to 100%, but how can we get closer", then that's great. For blog marketing reasons, you might describe that as "beating the CAP theorem"; but it's actually finding new solutions within the constraints.
  - mononcqc 13y ago
    Good catch for April fools! I shouldn't have included that one, obviously. For the nathan post, reading the comments reveal that he ends up acknowledging CAP is true, which would make him fall into the "( ) nice try, but blatantly false advertising" box of the list. CAP theorem can be used as an excuse to provide weak systems that don't do much (unfortunately), but it doesn't mean it's what it is meant to validate as an idea, fortunately. As I mentioned in another comment, it's more or less a very basic set of rules (axioms?) to consider when building distributed systems.

mononcqc 13y ago

Here are a few examples: http://nathanmarz.com/blog/how-to-beat-the-cap-theorem.html http://nathanmarz.com/blog/how-to-beat-the-cap-theorem.html http://dominictarr.com/post/44516618714/working-around-the-cap-theorem-with-rumours-db http://dominictarr.com/post/44516618714/working-around-the-c... http://scale-out-blog.blogspot.ca/2012/04/disproving-cap-theorem.html http://scale-out-blog.blogspot.ca/2012/04/disproving-cap-the... Not everyone accepts the CAP theorem yet, or some have an understanding of it that is flawed enough that they think they can beat it.

justinsb 13y ago
One of those was posted on April 1st :-) Nathan's post is very interesting - thanks for posting that. He has taken on board the implications of CAP, and built a system (Storm) that is genuinely different. I wish more people did that. If you're going to use CAP to justify building a database but having it be less capable, that's just marketing. If you're going to look at CAP and think "OK, we can't get to 100%, but how can we get closer", then that's great. For blog marketing reasons, you might describe that as "beating the CAP theorem"; but it's actually finding new solutions within the constraints.
- mononcqc 13y ago
  Good catch for April fools! I shouldn't have included that one, obviously. For the nathan post, reading the comments reveal that he ends up acknowledging CAP is true, which would make him fall into the "( ) nice try, but blatantly false advertising" box of the list. CAP theorem can be used as an excuse to provide weak systems that don't do much (unfortunately), but it doesn't mean it's what it is meant to validate as an idea, fortunately. As I mentioned in another comment, it's more or less a very basic set of rules (axioms?) to consider when building distributed systems.