This response confuses me. There’s an appeal that they exist in a kind of useless corner of PACELC (“sometimes we’re consistent and slow, and sometimes we’re inconsistent,”) a diagram that I feel wants to bamboozle me but just makes me cringe, some Java Jargon about data grids, and a bit of backing off on availability for future versions of particular object types.
The best I can interpret from this is that the author seems to believe that a PA system requires losing writes. The blog seems to be saying “Yes, we are PA/EC, so of course these are the results you’d expect”. Which is clearly not true.
Quite fascinating that there is a Database Software which has a unique number generator which fails to generate unique numbers, locks which do not lock, queues which do not queue and atomic references which aren’t in fact atomic.
Looking at how the cockroachdb folks implemented their distributed datastore and the years it took, it is extremely hard and takes a lot of validated tests (like how foundationdb did them) to ship a production-grade fault-tolerant product.
@aphyr, hopefully the arangodb folks contact you to test/validate their raft-based datastore. Both them and cockroachdb have friendly apache2 licenses so that’s always a good sign!
Ouch, no prisoners.
Hazelcast published a response:
https://blog.hazelcast.com/jepsen-analysis-hazelcast-3-8-3/
This response confuses me. There’s an appeal that they exist in a kind of useless corner of PACELC (“sometimes we’re consistent and slow, and sometimes we’re inconsistent,”) a diagram that I feel wants to bamboozle me but just makes me cringe, some Java Jargon about data grids, and a bit of backing off on availability for future versions of particular object types.
Yep, they’re butt-hurt over someone exposing the fact that their software doesn’t do what people expect it to do.
“Before going into that[,] lets[sic] go into how common network partitions are.”
This sentence, or something like it, is a pretty sure sign that what you’re going to read in a few seconds contains some (or is entirely) bullshit.
The best I can interpret from this is that the author seems to believe that a PA system requires losing writes. The blog seems to be saying “Yes, we are PA/EC, so of course these are the results you’d expect”. Which is clearly not true.
Thank you Kyle for taking the time to do this research on your own time and publishing the results publicly.
Quite fascinating that there is a Database Software which has a unique number generator which fails to generate unique numbers, locks which do not lock, queues which do not queue and atomic references which aren’t in fact atomic.
Looking at how the cockroachdb folks implemented their distributed datastore and the years it took, it is extremely hard and takes a lot of validated tests (like how foundationdb did them) to ship a production-grade fault-tolerant product.
@aphyr, hopefully the arangodb folks contact you to test/validate their raft-based datastore. Both them and cockroachdb have friendly apache2 licenses so that’s always a good sign!
[Comment removed by author]