NoSQL基准对比Aerospike、Cassandra、Couchbase和MongoDB

为了查看Aerospike、Cassandra、Couchbase和MongoDB这些数据库在处理插入吞吐量、最大吞吐量时的表现以及故障恢复期间的延迟时间和行为，最近的一个基准集合对这些数据库做了比较。

Thumbtack Technology发布了两个基准白皮书，其中包含了一些键—值存储的比较结果：超高性能 NoSQL基准: 分析持久性和性能权衡 (PDF) 和 NoSQL故障恢复特性: Aerospike、Cassandra、Couchbase和MongoDB (PDF)。这两个基准都试图检测“直面客户的应用程序，它们需要非常高的吞吐量和低延迟时间，同时其信息又能够使用键-值模式表示”。

Thumbtack使用了一个改善版本的Yahoo! 云服务基准 (YCSB) ，该基准可以克服使用高容量多客户端时遇到的一些限制。YCSB的变化已经写入了第一个白皮书并且提交回了社区。

测试的NoSQL数据库包括Aerospike、Cassandra、Couchbase （1.8 和2.0）和 MongoDB。第一个是商业化产品，最后一个是文档数据存储而不是键-值存储，但是因为“在我们遇到的客户端中经常考虑将它用于相似类型的应用程序中”，所以我们将之包含了进来。所有的数据库都使用其提供商提供的建议做了优化。测试系统使用SSD存储，而没有使用旋转磁盘。白皮书中详细记录了测试所使用的方法论、客户端、工作量配置以及硬件配置等信息。

Thumbtack承认它们和“Aerospike、Couchbase以及10gen有商业和（或）战略合作关系”，同时使用的硬件也是从Aerospike租用的。

下面列出了一些测试的基准结果。

插入吞吐量

数据库通过YCSB的加载路由执行了大量插入，载入了初始的工作集合。Couchbase在工作集合载入内存中时结果很好，但是在工作集合载入SSD时遇到了问题，Couchbase 1.8没有完成操作，而对Couchbase 2.0而言则必须使用较小的集合和异步模式。图中蓝色圆柱表示的就是Couchbase，Aerospike处在第二位。

图1：插入吞吐量

注意：对Couchbase 2.0而言，SSD吞吐量使用的样本较小，同时是异步模式；而对Couchbase 1.8而言，即使减少数据集也不能加载。

最大吞吐量

该测试使用了一个“强持久性模型，在复制时使用了一个相对服务器的RAM而言非常大的数据集。该测试打算作为保证强持久性的事务型数据的使用典范”。

在这个图表中并没有Couchbase，因为使用同步复制时它无法完成测试。

图2：最大吞吐量——SSD支持的数据集

在使用异步复制时，内存中的结果如下：

图3：最大吞吐量——内存数据集

延迟时间/吞吐量

基准还测量了在不同级别的传输下读取和更新的延迟时间。下面的图表包含了一个完整视图和每个对应的缩放视图。

图4a——4d：延迟时间/吞吐量结果（平衡负载）

故障恢复

Thumbtack还模拟了一个硬件错误，以便查看在一个节点无法工作时会发生什么：

注意：以上结果依赖于使用的驱动，像Hector这样较新的驱动能恢复到100%的吞吐量。同时假设监控脚本完美。

基准还测量了宕机时间，例如集群从发生错误开始到能够响应所需要的时间，所有数据库显示的值都合理：

图6：宕机时间、异步复制和基于RAM的数据集

Thumbtack基准还包含了很多其他不同情况下的不同结果，但是此处并没有包含这些内容。

另一个NoSQL基准发布于2012年10月，其中对比了Cassandra、HBase、MongoDB和Rick。这些测试中还包含了MySQL，作为针对SQL技术的一个参考。

查看英文原文：NoSQL Benchmark Compares Aerospike, Cassandra, Couchbase and MongoDB