NoSQL产品测评：Cassandra、MongoDB、Couchbase和Aerospike

近日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之间的性能。

在不久的将来，云计算一定会彻底走入我们的生活，有兴趣入行未来前沿产业的朋友，可以收藏云计算，及时获取人工智能、大数据、云计算和物联网的前沿资讯和基础知识，让我们一起携手，引领人工智能的未来！

标签： 大数据 服务器 数据库 网络 网络服务器 云计算

版权申明：本站文章部分自网络，如有侵权，请联系：west999com@outlook.com
特别注意：本站所有转载文章言论不代表本站观点！
本站所提供的图片等素材，版权归原作者所有，如需使用，请与原作者联系。