近日Thumbtack发布了两篇论文，分别为 超高性能NoSQL基准和 NoSQL故障转移特征；前者是分析持久性和性能的权衡，后者则是关于Aerospike、Cassandra、Couchbase和MongoDB几个NoSQL的故障转移特征。两个基准都尝试测试“有高吞吐量、低延时需求的面向用户应用程序，这些应用程序的数据都可以使用键值形式进行存储”。
Thumback使用的是YCSB（Yahoo! Cloud Serving Benchmark）的升级版，新的YCSB改变记录在第一篇论文的文档中。在着眼新的基准测试之前我们首先看一下原YCSB上的一件趣事：
YCSB推出不久后（1年多以前），HyperDex使用这个基准对HyperDex、Redis和MongoDB几个高性能数据库进行测试，而得出的结果更是犀利无比 —— 吞吐量秒杀风头正劲的MongoDB与Cassandra，赶超Redis。
为此有“热心”的网友在Redis社区中发表了帖子 HyperDex vs.Redis，并得到了Redis之父Salvatore Sanfilippo大神“强有力”的回复：
事实并没有听起来那么有趣，因为：
Redis和Memcached在单核心每秒查询上具有或多或少的上限，Memcached允许自动的使用多核技术（这一点Redis在将来可能会实现），而使用Redis你需要多实例，并且这只能在网络服务器中使用，当然这些系统使用的都是内存处理形式，并且通过合理的优化。
我想说的是，我也可以修改Redis让其返回的总是“foo”，从而达到单核心每秒15万ops。那么真实情况应该是这样的：
1. 基准E设计的非常粗糙，Redis并不支持，这样的对比一点“营养”都没有
2. 在所有其它的测试中，他们可能都是使用单核心Redis在对抗多核心HyperDex（或者是多节点HyperDex）。举个例子，Redis LPUSH每秒可以轻易的插入100万个选项进入列表，然而如果你同时使用4个实例，每个核心每秒你可能都会得到3、4百万写操作。然而这并不意味着我们需要在首页上写上“单核心每秒400万次操作”！
3. 基准测试用例的数据集可能一直都储存在内存中
4. 没有公布所有方法，这样这个测试结果无任何价值
最后我认为，使用错误的引导去塑造产品同样是不好的行为，前3个月可能会有所收获，那么之后会发生些什么？
“任何企图同时抓两只兔子的人，最终将毫无收获。”
而之后Salvatore Sanfilippo更是对YCSB基准做出了如下的评论：
这是我在HackerNews上对这个基准YCSB发起的讨论： 讨论地址
根本上说YCSB在构造思路上犯了经典的错误，取代使用合适的用例来获得不同数据库的最佳性能，它使用一个层来给不同数据库强制数据模型。对于大多数的数据库来说，使用的是本地数据模型，但是对于其它的（比如Redis）数据库来说，只是在模拟使用本地操作。
同样这个基准对比的是单核心Redis和多核心Hyperdex之间的性能。
(责任编辑：蒙遗善)
