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



Database as a Service: All content tagged as Database as a Service in NoSQL databases and polyglot persistence

Where Does Xeround Fit In The CAP Theorem?

Itamar Haber over the Xeround blog:

Q: Is Xeround Inconsistent? Xeround employs a set of majority-based algorithms to facilitate its reading and writing of data from/to multiple, distributed nodes. […] Via the use of these algorithms we are ensured that all access to the data is consistent so inconsistency is not an issue.

Q: Is Xeround Unavailable? There is no single point of failure in Xeround and every component that the system consists of is redundant and replaceable.

Q: Is Xeround Partitioning-Intolerant? Yes, to a certain extent it is.

After reading it, I got the same impression as VoltDB’s John Hugg who commented:

It sounds like you’ve gotten this backwards. According to you, in the face of a network event, the system becomes unavailable, but remains consistent. I think you have partition tolerance, but with reduced availability.

Instead of focusing strictly on the CAP characteristics of a distributed database, one should focus on what is the required behavior for their system and look for the database solution that offers them the guarantees they need.

Original title and link: Where Does Xeround Fit In The CAP Theorem? (NoSQL database©myNoSQL)