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



Clarifications on the CAP Theorem and Data-Related Errors

Michael Stonebraker detailing his perspective on CAP theorem:

In my experience, network partitions do not happen often.  Specifically, they occur less frequently than the sum of bohrbugs, application errors, human errors and reprovisioning events.  So it doesn’t much matter what you do when confronted with network partitions.  Surviving them will not “move the needle” on availability because higher frequency events will cause global outages.  Hence, you are giving up something (consistency) and getting nothing in return. 

It is difficult to argue against the idea that in an environment where your application and devops and bugs kill your data storage more often than system and network failures would, the CAP theorem remains one of your system priorities.

Original title and link: Clarifications on the CAP Theorem and Data-Related Errors (NoSQL databases © myNoSQL)