Hacker Newsnew | past | comments | ask | show | jobs | submitlogin
Eventual Consistency (couchdb.org)
19 points by _zhqs on June 10, 2010 | hide | past | favorite | 3 comments


I think the CAP theorem has been overapplied in a lot of cases. All it says is that the three forces are in tension, and that as you get more of one you have to trade away some of the others.

But that's pretty obvious. It's true in any optimization problem. There are a spectrum of technologies available, and all fall somewhere on what for the sake of argument let's call the CAP horizon. Why is it the case that you have to trade of one of C, A, or P when transitioning from one of these technologies to another?

The reason is obvious. Any technology that is _not_ on the CAP horizon must either improve or die. No one would use a technology that is simultaneously less C, A, and P than some other technology that's available.

So it's not true that you can only gain in one of the three by giving up some of the others. It's only true that of the products available that you might actually select from, all exhibit the tradeoff because if there was no tradeoff then one of the products would die.

There should probably be a fourth variable. Pr for "price." See Microsoft and Oracle make databases that are simultaneously as C and A, and more P than certain distributed solutions in MySql. But there you have to give up some Pr in order to get that extra P.

This kind of statement (X, Y, or Z, pick two) is an interesting, thought provoking way to state the tradeoffs in an industry. But it's more of an economic statement than a technical one. There are probably solutions yet to be discovered that will push all three variables higher in a single solution than anything we've discovered so far. But if and when such a solution is discovered, people will still be saying, C, A, P, pick two, and they will be right because the tradeoff will still be in effect with other products of the time.


The solution is to avoid one-size-fits-all. Some things need to be consistent and immediately available, e.g payment processing or privacy settings, even if you have 100 million users. For those use a relational database with only a few tables. For huge data sets, like billions of social interconnections, use a noSQL solution that scales to dozens of server locations. Eventual consistency is good enough, even some never consistent.


Problem with CouchDB is that there is no eventual consistency if a document depends on another. They should rename it "inevitable inconsistency".




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: