4 ms·

The thing that really struck me is that it has been proven only in 2002 - and it is by now a fundamental idea in (my) CS education about Databases and Distribut

by ff_ 11y ago

The thing that really struck me is that it has been proven only in 2002 - and it is by now a fundamental idea in (my) CS education about Databases and Distributed Systems: I'm used to considering its implications when thinking about a problem. So I wonder: how did you did it before then?

lsd5you 11y ago
I would say because ultimately it is just a shorthand/buzzword/brand. The theorom itself is kind of tautological, but it provides a simple starting point for talking about trade-offs. Unfortunately and inevitably things are a bit more complicated than a model simplified to 3 words so it has also generated its fair share of confusion.
- ownagefool 11y ago
  I don't think you can blame the theorom for the confusion. It's the trade-offs that are murky and complicated, CAP just tells us that there's a need to care about the dirty details. Anyway being able to use CAP to beat down the developer who wants to use the new webscale shiny that doesn't even begin to discuss or document tradeoffs is a net win in my opinion.
al2o3cr 11y ago
Before then, people built distributed systems and (sometimes) assumed they didn't have failure modes. Now, people build distributed systems and assume they don't have failure modes AND THEN post about how they've "refuted the CAP theorem". :)
ownagefool 11y ago
The same as anything really. You try and write a system, you realise that logically it was harder than you first assumed, you note there are failure scenarios that you're aware of. You mitigate and ship. Later as the bug reports come tumbling in you realise there were failure scenarios that you weren't aware of, usually because you were relying on something that you cant actually rely on. The fact that this is formalised is great because it means people who don't talk about when their systems don't work aren't giving you the whole picture.
shin_lao 11y ago
The proof is questionable. Read here: http://markburgess.org/blog_cap.html http://markburgess.org/blog_cap.html
pron 11y ago
Two things. 1. The notion of "high availability" wasn't used much before "web scale" applications. 2. As others have said, the CAP theorem is kind of tautological and does more to confuse about what's possible than to clarify. For example, the CAP theorem implies that even eventual consistency is impossible in the case of partitions. If partitions can be of infinite length then no kind of consistency is possible; if partitions are finite, then all kinds of consistency are possible (with "availability" meaning very high latency, though). In short, the CAP theorem itself doesn't contribute much information to the analysis of distribution problems. I recommend reading this nice overview of the issues with CAP: http://arxiv.org/abs/1509.05393 http://arxiv.org/abs/1509.05393
- notacoward 11y ago
  "High availability" was used very often long before "web scale" anything came along. It was in the very name of HACMP/6000, which I worked on in 1992, and wasn't new then. The problem is that "availability" in that world meant something very different than "availability" as it's defined in CAP - system availability vs. node availability. That has caused almost as much confusion as the difference in meaning between "consistency" in CAP and "consistency" in ACID.

by ff_ 11y ago

lsd5you 11y ago

I would say because ultimately it is just a shorthand/buzzword/brand. The theorom itself is kind of tautological, but it provides a simple starting point for talking about trade-offs. Unfortunately and inevitably things are a bit more complicated than a model simplified to 3 words so it has also generated its fair share of confusion.

ownagefool 11y ago
I don't think you can blame the theorom for the confusion. It's the trade-offs that are murky and complicated, CAP just tells us that there's a need to care about the dirty details. Anyway being able to use CAP to beat down the developer who wants to use the new webscale shiny that doesn't even begin to discuss or document tradeoffs is a net win in my opinion.

al2o3cr 11y ago

Before then, people built distributed systems and (sometimes) assumed they didn't have failure modes. Now, people build distributed systems and assume they don't have failure modes AND THEN post about how they've "refuted the CAP theorem". :)

ownagefool 11y ago

The same as anything really. You try and write a system, you realise that logically it was harder than you first assumed, you note there are failure scenarios that you're aware of. You mitigate and ship. Later as the bug reports come tumbling in you realise there were failure scenarios that you weren't aware of, usually because you were relying on something that you cant actually rely on. The fact that this is formalised is great because it means people who don't talk about when their systems don't work aren't giving you the whole picture.

shin_lao 11y ago

The proof is questionable. Read here: http://markburgess.org/blog_cap.html http://markburgess.org/blog_cap.html

pron 11y ago

Two things. 1. The notion of "high availability" wasn't used much before "web scale" applications. 2. As others have said, the CAP theorem is kind of tautological and does more to confuse about what's possible than to clarify. For example, the CAP theorem implies that even eventual consistency is impossible in the case of partitions. If partitions can be of infinite length then no kind of consistency is possible; if partitions are finite, then all kinds of consistency are possible (with "availability" meaning very high latency, though). In short, the CAP theorem itself doesn't contribute much information to the analysis of distribution problems. I recommend reading this nice overview of the issues with CAP: http://arxiv.org/abs/1509.05393 http://arxiv.org/abs/1509.05393

notacoward 11y ago
"High availability" was used very often long before "web scale" anything came along. It was in the very name of HACMP/6000, which I worked on in 1992, and wasn't new then. The problem is that "availability" in that world meant something very different than "availability" as it's defined in CAP - system availability vs. node availability. That has caused almost as much confusion as the difference in meaning between "consistency" in CAP and "consistency" in ACID.