为什么说很多NoSQL的Benchmark是扯淡?

2011.9.25更新

本文被转载到NoSQLFun进行讨论

我才发现原文的一些问题没有表述清楚:

1、本文主要是针对随机读,而非随机写,关于如何构造一个写快的NoSQL系统,见BigTable论文,或者Cassandra、HBase。

2、我实际遇到的都是随机读很慢的情况,热数据可以解决部分问题,但是当规模远大于你的机器规模的时候,还是无法逾越的问题,此时NoSQL相对于RDBMS的优势就小的可怜了。

欢迎继续进行探讨。

原文:

抱歉我用了这么一个标题党的题目做为标题。

写这篇文章只是想引起大家的注意:在选择NoSQL产品时,达到标称性能,需要诸多限制条件,例如本文主要讨论的磁盘I/O。

现在NoSQL的产品已经很多了,很多都宣称“我们的QPS可以达到十万,甚至百万”,但是当我们在生产环境中使用的时候,却明显的感觉到,随着数据文件不断增大,NoSQL的性能却指数下降,问题处在哪里了?

这些NOSQL的Benchmark的量都有一个前提“你得内存足够放下你的全部数据文件”

Case1:有人说,我内存16GB,那只能说明你得数据规模还不够大……我已经经历被无数上百GB的数据库折磨过了。此外,你可能需要在1GB内存的虚拟机上支撑数10GB的数据,比如我现在的情况。

继续讨论,一旦内存放不下全部的数据,会怎么办呢?
有很多策略,但无非都是访问磁盘,将数据Cache到内存中。

我们先讨论最坏的情况,假定每条记录的偏移是放在内存中,但所有数据都放在磁盘,我们使用fseek等操作来查询磁盘。

来看下面的测试代码。

好了,你猜猜上述随机fseek的程序在一个7200转的硬盘上,针对一个4GB的文件随机访问,能跑多块?

答案是QPS

有人说你骗人,我跑的能到1XXX,那么请你执行下述命令清空你内存中的磁盘缓存。

很多时候,之所以我们能在小数据时达到NoSQL官方标称的QPS,而大数据量却指数下降,都是这些缓存在作怪。说白了,我们很Happy的Benchmark半天,实际是在玩系统的缓存,当然快了。

一旦你的数据文件大于内存磁盘缓存,那么速度会马上像我列举的这样,不会多余80QPS,在一个4GB的文件上。

有人说mmap,我曾经也是这样YY的,但根据我的测试,事情不是这样。
我有一个120GB的Tokyo Cabinet数据文件,把内存开满,它默认会用mmap,然后你会发现top中“VIRT”一列,会显示为120GB+(换算后),而我得机器内存却只有32GB。这时,当你访问恰好不在内存中的那部分数据时,操作系统会进行非常耗时的换入换出操作(首先就需要fseek等)。在这台24核、32GB的机器上,QPS勉强能达到3000(这已经远远低于标称的QPS),而一旦清空缓存,QPS会迅速跌落到70左右……

可能还会有人说:我没事闲的为啥要自己清空缓存?

机器不是给你一个NoSQL进程服务的,很多系统其他服务都需要访问磁盘,读取文件,渐渐的就会把你Cache起来的内存全部换掉,根据实际测试的情况,一台完全闲置的机器,开TT能达到3000, 闲置放置48小时(不开其他服务), 性能就会骤降到1000左右,再放置72小时左右,就回归到70的qps了,此时Cache已经基本完全换出。

综上,mmap不是神,因为你的内存不够,而其他进程也会争夺内存来做自己的Cache。

如果你想充分发挥NoSQL的性能,建议用支持集群的NoSQL产品,尽量将全部数据放入内存中。

或者你没钱购置很多Moster内存的服务器,像我一样,就不要期望NoSQL能有很惊人的性能了。此时,NoSQL所能带来的提升,只是关系数据库所剪掉的那部分开销,如果你基本没有什么join,那么可能还会不如关系数据库。

分析性能,我们不能仅仅看官方的数据比较,要考虑机器的实际情况和自己的数据规模,最终才能分析出瓶颈出在哪里。

来源:为什么说很多NoSQL的Benchmark是扯淡?

以上纯属一家之言,如有不当,请指正,谢谢!

Leave a Reply

Your email address will not be published.