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



xeround: All content tagged as xeround 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)


Data Consistency and Synchronization in Scalable NoSQL Solutions

On Xeround blog:

What would be sacrificed if synchronization and transaction mechanisms were added on top of NoSQL foundations?  The answer is performance. Distributed and consistent data services will always be slower than pure raw distributed data service.

… and availability.

Original title and link: Data Consistency and Synchronization in Scalable NoSQL Solutions (NoSQL databases © myNoSQL)


Predictions about SQL and NoSQL databases

Razi Sharir of Xeround1:

  1. Database models and alternatives settle back on SQL
  2. Enterprises and Developers will realize that databases in the cloud have specific needs
  3. 2011 is the year of Database-as-a-Service (DBaaS)
  4. Native SaaS pricing
  5. Elasticity is the key – and in 2011, we expect it to be automatic

All planets are aligning for Xeround. Astronomy center does not confirm though.

  1. Xeround is a service company providing “elastic, always-on database-as-a-service for your MySQL-based application”. I wrote about Xeround and that post generated a very interesting conversation.  

Original title and link: Predictions about SQL and NoSQL databases (NoSQL databases © myNoSQL)


Xeround: MySQL Elastic, Always-on Storage Engine for the Cloud

Xeround is a new MySQL storage engine offered as Database-as-a-Service.

What it promises sounds (a bit?) too good to be true (nb this list have been extracted from their site):

  • seamless replacement of existing MySQL database
  • high availability (including schema changes)
  • automatic fault-detection and recovery
  • full consistency with low latency
  • elasticity

What’s the catch?

Original title and link: Xeround: MySQL Elastic, Always-on Storage Engine for the Cloud (NoSQL databases © myNoSQL)