HBase, Cassandra, and MongoDB - How They Recover From a Failure
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 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.
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 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.