5 ms·

Normally discussion of CAP results in a heated argument due to the many different interpretations floating around. 6 hours later, not a single comment here on

by khaki54 12y ago

Normally discussion of CAP results in a heated argument due to the many different interpretations floating around. 6 hours later, not a single comment here on HN or the guy's website. Not sure if I'm impressed or disappointed considering the author makes some points that I'd never heard before, such as an eventual consistency data store not being CA, CP, or AP.

stonemetal 12y ago
Probably because there isn't much use to it, as with , such as an eventual consistency data store not being CA, CP, or AP. there is nothing to argue with. He makes the assertion but offers no reasoning to support his claim. For an existence proof of things he claims doesn't exist consider Cassandra. It is eventually consistent, and you can configure it to be each of those things he says can't happen by tuning the read, write consistency. For CA choose all, CP choose quorum, for AP choose one. QED.
- dsp1234 12y ago
  For CA choose all My understanding is that you can't "choose" CA, because partitions can never be entirely eliminated. If CA was really an option, who wouldn't pick it? So if Cassandra is actually able to do that, then can you expand a little more on how it accomplishes that?
  - henrikschroder 12y ago
    CA means you're not choosing P, which means your system does not have partition tolerance, and that's exactly what ALL does in Cassandra. If any replica is unavailable, the operation fails, and your application suffers.
    - saurik 12y ago
      This is CP: you have chosen to sacrifice availability by making operations fail when replicas cannot be contacted due to a partition. The concept of "partition tolerance" ends up heavily overlapping with the concept of "availability" to the point where trying to make tradeoffs between the two without sacrificing consistency is essentially nonsensical. As put by Coda Hale: "You Can't Sacrifice Partition Tolerence". http://codahale.com/you-cant-sacrifice-partition-tolerance/ http://codahale.com/you-cant-sacrifice-partition-tolerance/ (Sadly, Coda deferred to someone important after writing this article, someone whom I don't think bothered to think through how much more beautiful Coda's explanation of a "partition" is than the AFAICT impossible-to-discern one that supposedly was being used in the original paper :/. I frankly think the final "update" to the article should be ignored. FWIW, in the first "update", it is pointed out that Eric Brewer actually have a very positive shout-out to Coda's article.)
      - henrikschroder 12y ago
        Ah, I see, I misunderstood Availability, I assumed that returning an error would count.
      - nkeywal 11y ago
        > I frankly think the final "update" to the article should be ignored. Coda updated his post just because he was wrong on his definition of partition. Stonebraker pointed out: "You simply failover to a replica in a transactionally consistent way. Notably, at least Tandem and Vertica have been doing exactly this for years. Therefore, considering a node failure as a partition results in an obviously inappropriate CAP theorem conclusion."
  - stonemetal 12y ago
    I said we can build a setup that is not tolerant of network partitions and was CA when it was functioning. I didn't say we could build a system that had no network partitions. P is how well it tolerates network partitions, not whether or not it experiences them.
- nkeywal 11y ago
  This post looks at the application as a whole, not only the datastore. But for an eventually consistent big data store, AP is not possible. See http://blog.thislongrun.com/2015/04/cap-availability-high-availability-and_16.html http://blog.thislongrun.com/2015/04/cap-availability-high-av...
nkeywal 11y ago
Thanks for posting this to HN (I'm the post author). There are two posts: 1) the link you posted. It looks at the application as a whole, not really at the datastore alone. 2) Another one on the big data store themselves, and more generally of the different definitions of 'availability'. It's here http://blog.thislongrun.com/2015/04/cap-availability-high-availability-and_16.html http://blog.thislongrun.com/2015/04/cap-availability-high-av... I will update the posts to make this clearer. As well, it's a series and these posts are the most complex of the series :-). Many points are more detailed in the previous posts.

by khaki54 12y ago

stonemetal 12y ago

Probably because there isn't much use to it, as with , such as an eventual consistency data store not being CA, CP, or AP. there is nothing to argue with. He makes the assertion but offers no reasoning to support his claim. For an existence proof of things he claims doesn't exist consider Cassandra. It is eventually consistent, and you can configure it to be each of those things he says can't happen by tuning the read, write consistency. For CA choose all, CP choose quorum, for AP choose one. QED.

dsp1234 12y ago
For CA choose all My understanding is that you can't "choose" CA, because partitions can never be entirely eliminated. If CA was really an option, who wouldn't pick it? So if Cassandra is actually able to do that, then can you expand a little more on how it accomplishes that?
- henrikschroder 12y ago
  CA means you're not choosing P, which means your system does not have partition tolerance, and that's exactly what ALL does in Cassandra. If any replica is unavailable, the operation fails, and your application suffers.
  - saurik 12y ago
    This is CP: you have chosen to sacrifice availability by making operations fail when replicas cannot be contacted due to a partition. The concept of "partition tolerance" ends up heavily overlapping with the concept of "availability" to the point where trying to make tradeoffs between the two without sacrificing consistency is essentially nonsensical. As put by Coda Hale: "You Can't Sacrifice Partition Tolerence". http://codahale.com/you-cant-sacrifice-partition-tolerance/ http://codahale.com/you-cant-sacrifice-partition-tolerance/ (Sadly, Coda deferred to someone important after writing this article, someone whom I don't think bothered to think through how much more beautiful Coda's explanation of a "partition" is than the AFAICT impossible-to-discern one that supposedly was being used in the original paper :/. I frankly think the final "update" to the article should be ignored. FWIW, in the first "update", it is pointed out that Eric Brewer actually have a very positive shout-out to Coda's article.)
    - henrikschroder 12y ago
      Ah, I see, I misunderstood Availability, I assumed that returning an error would count.
    - nkeywal 11y ago
      > I frankly think the final "update" to the article should be ignored. Coda updated his post just because he was wrong on his definition of partition. Stonebraker pointed out: "You simply failover to a replica in a transactionally consistent way. Notably, at least Tandem and Vertica have been doing exactly this for years. Therefore, considering a node failure as a partition results in an obviously inappropriate CAP theorem conclusion."
- stonemetal 12y ago
  I said we can build a setup that is not tolerant of network partitions and was CA when it was functioning. I didn't say we could build a system that had no network partitions. P is how well it tolerates network partitions, not whether or not it experiences them.
nkeywal 11y ago
This post looks at the application as a whole, not only the datastore. But for an eventually consistent big data store, AP is not possible. See http://blog.thislongrun.com/2015/04/cap-availability-high-availability-and_16.html http://blog.thislongrun.com/2015/04/cap-availability-high-av...

nkeywal 11y ago

Thanks for posting this to HN (I'm the post author). There are two posts: 1) the link you posted. It looks at the application as a whole, not really at the datastore alone. 2) Another one on the big data store themselves, and more generally of the different definitions of 'availability'. It's here http://blog.thislongrun.com/2015/04/cap-availability-high-availability-and_16.html http://blog.thislongrun.com/2015/04/cap-availability-high-av... I will update the posts to make this clearer. As well, it's a series and these posts are the most complex of the series :-). Many points are more detailed in the previous posts.