NoSQL Zone is brought to you in partnership with:

Mitch Pronschinske is a Senior Content Analyst at DZone. That means he writes and searches for the finest developer content in the land so that you don't have to. He often eats peanut butter and bananas, likes to make his own ringtones, enjoys card and board games, and is married to an underwear model. Mitch is a DZone Zone Leader and has posted 2573 posts at DZone. You can read more from them at their website. View Full User Profile

HBase, Cassandra, and MongoDB - How They Recover From a Failure

12.15.2011
| 10370 views |
  • submit to reddit
Operational stability and availability are a big deal when your application starts to handle the large, unstructured volumes of data that NoSQL solutions are built for.  Knowing the quirks and nuances of each option is a big deal when making major architectural decisions in your persistence stack. 

So now, I will present to you a recent addition to CURBID's series of NoSQL comparisons.  This one was focused on how Cassandra, HBase, and MongoDB compare when handling failovers.  Here's the summarized version:

UPDATE: Make sure you check out Johnathan Ellis' comment below since he finds CURBID's explanation to be false based on his own experience as a developer of the database.

Cassandra

Cassandra offers high availability for Write operations. However, it takes a long time to recover data from a failure. This is because Cassandra identifies all the data to recover, and then reads and writes the latest version of each data. Also since it responds to service requests while the added node is still in the process of data recovery, an incorrect read result may be returned. ...if the consistency level is not raised, it cannot be used for the services that require read processing.

 

HBase

 

Because of its configuration, HBase has many factors that may cause a failure. However, while Cassandra has to recover data during a failure, HBase does not need to recover data unless a failure occurs in the HDFS. This gives HBase a short downtime. The downtime during an HDFS failure is not that long either.

MongoDB

MongoDB provides automatic failover and has a short downtime. However, its asynchronous replication method may cause data loss after a failover.


Along with Availability and Operational Stability of NoSQL, you should check out What is NoSQL for? and NoSQL Benchmarking, which also cover Cassandra, HBase, and MongoDB.

Source:  http://www.cubrid.org/blog/dev-platform/availability-and-operational-stability-of-nosql/

Comments

Jonathan Ellis replied on Thu, 2011/12/15 - 10:29am

The excerpt you chose about Cassandra is one of the least accurate in the original blog post. In short, it's completely wrong. Cassandra's Dynamo-based availability design is the strongest around; as a matter of fact, I was recently at a Cloud Computing meetup where a Netflix engineer explained that this was a major reason Netflix chose Cassandra over HBase or MongoDB. His slides are here: http://www.slideshare.net/jasedbrown/cassandra-from-the-trenches-migrating-netflix-10586521 As I explained in more detail in a comment on the Cubrid blog, Cassandra tolerates failures as part of its design, with no need for fragile failover handoffs as in HBase or MongoDB. Recovery is effectively instant as soon as a node comes back online; missed updates will be replayed in the background, and whether that node participates in handling requests until that finishes is determined by the chosen ConsistencyLevel. See http://www.datastax.com/docs/1.0/dml/data_consistency for more details.

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.