nkeywal

6 ms·

1.
by nkeywal 11y ago
> 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 cha
2.
by nkeywal 11y ago
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
3.
Forfeiting Partition Tolerance in Distributed Systems(blog.thislongrun.com)
10 points by nkeywal 11y ago|4 comments
4.
If CAP were realtime: adding timing requirements to definition of availability(blog.thislongrun.com)
34 points by nkeywal 11y ago|0 comments
5.
by nkeywal 11y ago
> 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 i
6.
CAP Theorem: if all you have is a timeout, everything looks like a partition(blog.thislongrun.com)
52 points by nkeywal 11y ago|3 comments
7.
Eventual Consistency and Durability(blog.thislongrun.com)
1 points by nkeywal 11y ago|0 comments
8.
by 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-av...
9.
by 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 transac
10.
by nkeywal 11y ago
(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. Se
11.
by 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
12.
CAP, Availability and Big Data databases in a world of partitions(blog.thislongrun.com)
3 points by nkeywal 11y ago|0 comments
13.
The unclear CP vs. CA case in CAP(thislongrun.blogspot.com)
13 points by nkeywal 12y ago|0 comments
14.
by nkeywal 12y ago
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
15.
by nkeywal 12y ago
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'r
16.
by nkeywal 12y ago
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 ret
17.
by nkeywal 12y ago
'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.
18.
by nkeywal 12y ago
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/co
19.
by nkeywal 12y ago
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
20.
The confusing CAP and ACID wording(thislongrun.blogspot.com)
71 points by nkeywal 12y ago|27 comments