为了查看 Aerospike、Cassandra、Couchbase 和 MongoDB 这些数据库在处理插入吞吐量、最大吞吐量时的表现以及故障恢复期间的延迟时间和行为，最近的一个基准集合对这些数据库做了比较。
Thumbtack Technology发布了两个基准白皮书，其中包含了一些键—值存储的比较结果： 超高性能 NoSQL__ 基准 _:_ 分析持久性和性能权衡 和 NoSQL__ 故障恢复 __ 特性 _: Aerospike__、、_ Couchbase__ 和 __MongoDB _(PDF)__。_ 这两个基准都试图检测“直面客户的应用程序，它们需要非常高的吞吐量和低延迟时间，同时其信息又能够使用键 - 值模式表示”。
Thumbtack 使用了一个改善版本的 云服务 基准 ，该基准可以克服使用高容量多客户端时遇到的一些限制。YCSB 的变化已经写入了第一个白皮书并且提交回了社区。
测试的 NoSQL 数据库包括、、（1.8 和 2.0）和。第一个是商业化产品，最后一个是文档数据存储而不是键 - 值存储，但是因为“在我们遇到的客户端中经常考虑将它用于相似类型的应用程序中”，所以我们将之包含了进来。所有的数据库都使用其提供商提供的建议做了优化。测试系统使用 SSD 存储，而没有使用旋转磁盘。白皮书中详细记录了测试所使用的方法论、客户端、工作量配置以及硬件配置等信息。
Thumbtack 承认它们和“Aerospike、Couchbase 以及 10gen 有商业和（或）战略合作关系”，同时使用的硬件也是从 Aerospike 租用的。
下面列出了一些测试的基准结果。
插入吞吐量
数据库通过 YCSB 的加载路由执行了大量插入，载入了初始的工作集合。Couchbase 在工作集合载入内存中时结果很好，但是在工作集合载入 SSD 时遇到了问题，Couchbase 1.8 没有完成操作，而对 Couchbase 2.0 而言则必须使用较小的集合和异步模式。图中蓝色圆柱表示的就是 Couchbase，Aerospike 处在第二位。
图：插入吞吐量
注意： 对 Couchbase 2.0 而言，SSD 吞吐量使用的样本较小，同时是异步模式；而对 Couchbase 1.8 而言，即使减少数据集也不能加载。
最大吞吐量
该测试使用了一个“强持久性模型，在复制时使用了一个相对服务器的 RAM 而言非常大的数据集。该测试打算作为保证强持久性的事务型数据的使用典范”。
在这个图表中并没有 Couchbase，因为使用同步复制时它无法完成测试。
图：最大吞吐量——支持的数据集
在使用异步复制时，内存中的结果如下：
图：最大吞吐量——内存数据集
延迟时间 吞吐量
基准还测量了在不同级别的传输下读取和更新的延迟时间。下面的图表包含了一个完整视图和每个对应的缩放视图。
图——：延迟时间 吞吐量结果（平衡负载）
故障恢复
Thumbtack 还模拟了一个硬件错误，以便查看在一个节点无法工作时会发生什么：
注意： 以上结果依赖于使用的驱动，像 Hector 这样较新的驱动能恢复到 100% 的吞吐量。同时假设监控脚本完美。
基准还测量了宕机时间，例如集群从发生错误开始到能够响应所需要的时间，所有数据库显示的值都合理：
图：宕机时间、异步复制和基于的数据集
Thumbtack 基准还包含了很多其他不同情况下的不同结果，但是此处并没有包含这些内容。
另一个NoSQL 基准发布于2012 年10 月，其中对比了Cassandra、HBase、MongoDB 和Rick。这些测试中还包含了MySQL，作为针对SQL 技术的一个参考。
查看英文原文 ： NoSQL Benchmark Compares Aerospike, Cassandra, Couchbase and MongoDB
