解析NoSQL的可靠性及扩展操作

jieforest

添加一个节点

向主节点中输入数据，确认数据的大小是5GB，这要保证比内存的容量小。接下来，添加一个新的slave节点到主节点上，在这种情况下，新增的从节点并不会降低主节点的性能，而新增一个从节点复制所有数据的时间只需要几分钟。

而对MongoDB来说，由于故障或者增加节点带来的性能降低是非常小的。然而当主节点和从节点的备份信息是不一致的，一旦主节点出现故障 —— 那些还没有复制到从节点中的数据有可能会丢失。在MongoDB中，主节点将操作记录写入本地服务器的Oplog日志中，然后从节点读取日志并且储存在自己的数据库中。

如果在故障发生时从节点仍然未完成日志读取并保存，未经读取的数据将会丢失。此外，即使主节点的日志已满，但是从节点还未完成文件的复制，所有主节点的数据都被读取并存入从节点，而不是复制到日志中。这被称为数据同步。如果上面这种情况发生主节点故障，那么大量的数据将会丢失。

jieforest

结论：

到现在为止，作者对Cassandra, HBase以及MongoDB的故障恢复逐一做了论述。

Cassandra提供高可用性的写操作，然而，它需要很长时间来从一个失败中恢复数据。这是因为Cassandra识别要恢复的所有数据，然后读和写每个数据的最新版本。它还因在响应服务请求添加新节点时，仍在恢复数据，导致错误的读取结果返回。

此外,Read Repair会在读取数据用以恢复的时候运行两次。尽管它在新节点添加同时发生节点失败会有相对处理，但是如果在数据恢复之前进行读取仍然会返回错误的结果。因此一致性等级的性能不被提高,它仍然不能用于需要读操作的服务。

由于它的配置问题，HBase自身存在很多因素可能导致问题的产生。不过对比Cassandra节点失败时必须进行数据的恢复，HBase却不需要恢复数据，除非HDFS出现问题。这样HBase宕机时间就会很短，即使HDFS出现问题宕机时间也不会很长。虽然读性能在数据的恢复过程中会受到影响，但是数据的一致性完全可以得到保证。用这种方式，如果SPoF部分成为冗余，我们将从HBase获得很高的可靠性。

jieforest

MongoDB提供了一个自动故障恢复并且发生宕机的时间很短。然而，异步复制方式在故障恢复的过程中很容易造成数据的丢失。

当然，在最终选择适合自己的数据库解决方案之前，应该对比每个产品的特点。举个例子，CUBRID 关系型数据库系统，为数据的一致性提供了同步的高可用性体系，虽然没有数据的丢失问题，但是它远远比不上NoSQL解决方案的性能。

jieforest

over.