News for hackers. Stuff that matters.

A comment on Errors in Database Systems, Eventual Consistency, and the CAP Theorem. Parent comment

Re:Errors in Database Systems, Eventual Consistency, and the... by mmalone on Wednesday April 07, 2010 @03:18PM (#1248183)
Your first point is not true. In the absence of partitions, all "eventually consistent" data stores that I know of will give you strong consistency. The eventual consistency bit only comes into play if a problem occurs. (It's probably also worth noting that many RDBMS replication strategies won't give you strong consistency at all - even in ideal circumstances.)

I suppose you could retry if a write fails (e.g., can't reach a quorum), but you could theoretically end up retrying forever (and 10 seconds or so is forever as far as an interactive user is concerned)... eventually you need to either fail or write inconsistently. So we're just delaying the inevitable.

Also if you're accepting quorum writes to the "major partition" you still have to repair the "minor partition" when it comes back online. There's no traditional DB that implements the sort of read-repair/hinted-handoff/anti-entropy mechanics that Cassandra, Voldemort, and the various proprietary big data stores use.

[ Parent | on HN ]
Re:Errors in Database Systems, Eventual Consistency, and the... by cx01 on Wednesday April 07, 2010 @03:21PM (#1248190)
The case that I have to retry indefinitely will only occur when the partition is permanent. And in that case an eventually consistent system will not help either, because clients will not see the writes (as long as the partition exists), so the eventual consistent system doesn't offer me any advantage.
[ Parent | on HN ]
Re:Errors in Database Systems, Eventual Consistency, and the... by mmalone on Wednesday April 07, 2010 @04:06PM (#1248296)
My point was that for an interactive application it doesn't take a very long time for user experience to degrade substantially.

And we've glossed over my points about newer databases exposing these knobs to clients. It's possible to do exactly what you're describing using Cassandra, for example (er, you might have to do some consistency level tweaking to make writes fail if you can't get a quorum of authoritative nodes, but it wouldn't be hard - and I'm not even sure if that's necessary). It's not possible to do it with MySQL or PostgreSQL without building some intelligent partitioning layer on top. And that layer will probably make it impossible to do joins and add relationship constraints, so you lose any benefits these systems bring to the table.

[ Parent | on HN ]