3 ms·

Attacking CAP seems to be a recent theme - Stonebraker did this a few weeks back (http://cacm.acm.org/blogs/blog-cacm/83396-errors-in-database-systems-eventual-

Attacking CAP seems to be a recent theme - Stonebraker did this a few weeks back (http://cacm.acm.org/blogs/blog-cacm/83396-errors-in-database-systems-eventual-consistency-and-the-cap-theorem/fulltext http://cacm.acm.org/blogs/blog-cacm/83396-errors-in-database...) Abadi's take seemed more interesting to me since it isn't rubbishing CAP as such, but noting that C, A & P are not symmetrical and also that there is a fourth consideration - latency - that most discussions of this topic do not take into account even though it is clearly a design factor in some existing NoSQL databases.

roder 16y ago
Latency is also a multipart problem, right? The software can always attempt to improve it's response time, but it can't change the latency on the wire.
seymourz 16y ago
This is because that Latency is strongly relevant to Consistency.
strlen 16y ago
I think latency is the un-written, default assumption in all of these cases. High-latency, strongly consistent, shared nothing distributed relational databases are over two decades old (starting with Stonebraker's "a case for shared nothing"). Problem is that they're unusable for OLTP workloads (without non-commodity hardware appliances, using SSDs and connected over Infiband e.g., Exadata) even if you don't "CAP" into account. Latency isn't a "tunable" variable in the same sense as C and P, in that there's multiple ways to lower latency. With eventual consistency you can use smaller quorums to lower the latency for either reads, writes or both. You can also use strong consistency, to avoid having to do quorums at read times but at higher latency writes. Higher latency writes may be acceptable, at least with 2PC. I am not sure many systems use Paxos for replicating a transaction log on every write due to the costs: I believe Scalaris may be, but I can't find the information right now.

roder 16y ago

Latency is also a multipart problem, right? The software can always attempt to improve it's response time, but it can't change the latency on the wire.

seymourz 16y ago

This is because that Latency is strongly relevant to Consistency.

strlen 16y ago

I think latency is the un-written, default assumption in all of these cases. High-latency, strongly consistent, shared nothing distributed relational databases are over two decades old (starting with Stonebraker's "a case for shared nothing"). Problem is that they're unusable for OLTP workloads (without non-commodity hardware appliances, using SSDs and connected over Infiband e.g., Exadata) even if you don't "CAP" into account. Latency isn't a "tunable" variable in the same sense as C and P, in that there's multiple ways to lower latency. With eventual consistency you can use smaller quorums to lower the latency for either reads, writes or both. You can also use strong consistency, to avoid having to do quorums at read times but at higher latency writes. Higher latency writes may be acceptable, at least with 2PC. I am not sure many systems use Paxos for replicating a transaction log on every write due to the costs: I believe Scalaris may be, but I can't find the information right now.