So, I've actually been thinking a lot about this problemset. I think that polyglot databases are the future. Most applications can deal with eventual consistency, or at least bounded stale reads [see: most interactions with Twitter, Facebook, etc..].
I think a hybrid consistency model will end up becoming the way we end up going, but not without some changes to the working definition of eventual consistency.
I think that eventually consistent systems that we'll see in the future will at a minimum have atomic, consistent (as in ACID), durable transactions. The big thing you're missing is isolation, and by that, you're also missing serializability.
(http://www.vldb.org/pvldb/vol7/p181-bailis.pdf)
Bounded staleness consistency will probably make most people happy -- as in "Give me a consistent snapshot of the database as of 1 second ago," or "Give me a consistent snapshot of the database as of this logical time" (assuming the database consumer has some sort of logical clock you're passing back and forth -- In essence, MVCC with some exposure of the timestamp.
(better explanations: http://pages.cs.wisc.edu/~cs739-1/papers/consistencybaseball...)
In addition to this, part of the problems that were outlined in the paper talked about multi-datacenter issues -- a lot of issues with banking-like apps can be solved with escrowing For example, each datacenter has 10% of the account's balance, and you can use consistent commits in the datacenter. If an interactions effects more than 10% of the account's value, it should occur across datacenters, and make a consistent commit across datacenters.
(More info: http://mdcc.cs.berkeley.edu/)
Anyways...the future is bright, but we need someone to throw a ridiculous amount of money, and time at it.
Basho's Riak DB is becoming such a hybrid. It is an traditionally an eventually consistent database, but they are adding strong consistency in the new release. [I don't work and am not affiliated with them, just follow them on Github].
And by hybrid in this case I mean some part to keyspace can be tagged as consistent while others remain as before.
I think a hybrid consistency model will end up becoming the way we end up going, but not without some changes to the working definition of eventual consistency.
I think that eventually consistent systems that we'll see in the future will at a minimum have atomic, consistent (as in ACID), durable transactions. The big thing you're missing is isolation, and by that, you're also missing serializability. (http://www.vldb.org/pvldb/vol7/p181-bailis.pdf)
Bounded staleness consistency will probably make most people happy -- as in "Give me a consistent snapshot of the database as of 1 second ago," or "Give me a consistent snapshot of the database as of this logical time" (assuming the database consumer has some sort of logical clock you're passing back and forth -- In essence, MVCC with some exposure of the timestamp. (better explanations: http://pages.cs.wisc.edu/~cs739-1/papers/consistencybaseball...)
In addition to this, part of the problems that were outlined in the paper talked about multi-datacenter issues -- a lot of issues with banking-like apps can be solved with escrowing For example, each datacenter has 10% of the account's balance, and you can use consistent commits in the datacenter. If an interactions effects more than 10% of the account's value, it should occur across datacenters, and make a consistent commit across datacenters. (More info: http://mdcc.cs.berkeley.edu/)
Anyways...the future is bright, but we need someone to throw a ridiculous amount of money, and time at it.