nkeywal

> This is precisely CP.

Hum. I would prefer to call 'precisely CP' a system that shutdown one of the partition, not one that cannot restart after a partition. Even if formally you can use both (i.e. CP/AP)

> VoltDB changed the way our product behaved in version 3.0 to aggressively kill nodes if there is any potential for split brains. We originally intended this feature for the cloud only,

Quite interesting.

You could also shut down definitively, for example if the system is corrupted and cannot restart after a partition. There is no inconsistent history in this case, just complete unavailability (you could also claim being CP).

You can also be partly available and partly inconsistent (2PC with heuristic resolution). Here you're not AP nor CP.

Partition intolerance (CA) is a specification. It's saying any network partition is a serious issue for the system, and that may break one or more invariants (ex: atomicity in a sql database).

> isn't the entire optimization redundant anyway? With ZooKeeper the ephemeral znode is linked to a session, and if you restart the process it will have a different session. So you also need to manage the znode deletion explicitly in this case. It's possible of course, I have a little preference for the 'ultimate line in the script' as it does not rely on the restart but both options are likely good.

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-av...

> 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."

(cross-porting from the blog)

> Second [...] In that case, why use 2PC at all? Heuristic decisions are in the XA standard since its first version (1991). YMMV, but they are very often used (to say the least) in 2PC production systems. See for example how Mark Little describes them: http://planet.jboss.org/post/2pc_or_3pc. Not really presented as an optional thing. It shows traditional databases are not that 'CP at all cost' when it comes to managing failure.

> Your conclusion is correct [...] the resulting algorithm is not C or A Yeah... I see 2PC as not partition-tolerant as a partition breaks acid-atomicity. Once partition intolerance is accepted, CA fits well: 2PC is consistent & available until there is a partition. Saying '2PC is not consistent and not available but is partition tolerant' is not false technically but it's a much less accurate description.

> Third [...] datacenters full of commodity servers [...] > redundant NICs and cables, located next to each other > [...] It isn't hard to believe that you could build a system, like that, > in which you could add algorithms that were CA

I just totally agree with you here. CAP as a categorization tool is used for all types of distributed systems, but there is a huge difference between an application built on commodity hardware running in a multi-dc config and a 2 nodes system running on redundant hardware in a single rack. Typically, 2PC is historically used on very specific applications: few nodes, a limited number of operations between the nodes, expensive redundant hardware all over the place, limited scaling out needs (if any). Not your typical big data system.

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-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.

There is a kind of opposition between 'CAP as a theorem' and 'CAP as a tool to think about distributed systems'. The theorem does not leave much room for something else than black and white. But in the (great) paper you mention, there is a lot about "what is the future for distributed systems", it's more CAP-as-a-tool.

In the post (and in the blog) I stick to the theorem. It's not 'right' or 'wrong', it's a choice. I made this choice because a lot of people are deciding their trade-offs with CAP-as-a-theorem, while actually CAP-as-a-theorem cannot be applied to the problem they're working on.

I can agree with these facts. I just give them a different weight than you do: I don't like the incertitude of the 'serialization failures': it depends on a workload that can be difficult to predict, especially if you're a software vendor. YMMV :-) Thanks for the constructive feedback.

Well, I've never used postgres, but from the documentation v9.4 it does not look that different from the others db engine: 'Read Committed is the default isolation'; 'applications using this level must be prepared to retry transactions due to serialization failures' (plus the one you mentioned already: 'Serializable transaction isolation level has not yet been added to Hot Standby replication targets')

Not exactly what I like to call 'simply works' ;-)

But I didn't want to say that a NoSQL database is always better than an traditional one. Just that Isolation is complex on traditional systems when dealing with volumes & concurrency. And, typically, transactions between tables or even rows are difficult/impossible for a distributed database, as these rows can be on different nodes (the 'multi-key operations' you mentioned)

'Atomic Consistency' is used in the CAP proof. YMMV, but I've seen it more used than 'linearizability' (it's easier to pronounce...). Agreed, there is no confusion when you use linearizability.

Yes, I agree. It's not 'eventually consistent' but it's nearly available-in-CAP.

There are some elements on the CAP definition traps in the first post: http://thislongrun.blogspot.com/2015/03/comparing-eventually.... I also plan to do another post on this subject.

Thanks for the feedback. > if the developer is not up to understanding the locking model of a traditional DB I'd be pretty surprised if they were up to working with an eventually consistent system I agree. As well, most 'NoSQL' systems don't throw everything. Typically, some of them are strongly consistent. The ones based on Dynamo claim to have 'tunable consistency', i.e. the choice between strong & weak consistency is up to the user.

We have a lot of "acid simply works" and "NoSQL is available". The blog is basically about saying things are not that simple, and it includes this "isolation in acid isn't that simple".