NoSQL Benchmarks NoSQL use cases NoSQL Videos NoSQL Hybrid Solutions NoSQL Presentations Big Data Hadoop MapReduce Pig Hive Flume Oozie Sqoop HDFS ZooKeeper Cascading Cascalog BigTable Cassandra HBase Hypertable Couchbase CouchDB MongoDB OrientDB RavenDB Jackrabbit Terrastore Amazon DynamoDB Redis Riak Project Voldemort Tokyo Cabinet Kyoto Cabinet memcached Amazon SimpleDB Datomic MemcacheDB M/DB GT.M Amazon Dynamo Dynomite Mnesia Yahoo! PNUTS/Sherpa Neo4j InfoGrid Sones GraphDB InfiniteGraph AllegroGraph MarkLogic Clustrix CouchDB Case Studies MongoDB Case Studies NoSQL at Adobe NoSQL at Facebook NoSQL at Twitter



The demise of eventual consistency?

A well written article by FoundationDB’s founder Dave Rosenthal about eventual consistency:

The concept of eventual consistency comes up frequently in the context of distributed databases. Leading NoSQL databases like Riak, Couchbase, and DynamoDB provide client applications with a guarantee of “eventual consistency”. Others, like MongoDB and Cassandra are eventually consistent in some configurations.

I could ignore some smart word choices and agree that dealing with eventual consistency is not a familiar area to many developers.

What I cannot agree with though, are weak statements like (what does unreliable writes mean?) :

Eventual consistency pushes the pain and confusion of inconsistent reads and unreliable writes onto software developers.

And definitely I cannot agree with unproved statements used solely to prove your point:

A system that keeps some, but not all, of its nodes able to read and write during a partition is not available in the CAP sense but is still available in the sense that clients can talk to the nodes that are still connected. In this way fault-tolerant databases with no single point of failure can be built without resorting to eventual consistency.

By changing the definitions, you are not proving a theorem is incorrect. Nor do you prove a different theorem.

Original title and link: The demise of eventual consistency? (NoSQL database©myNoSQL)