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