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

数据库 其他数据库
正如原作者所言,本文有标题党之嫌,但确实道出了一个众所周知的问题。就是很多NoSQL产品的官方 benchmark 过高。虽然本人并不完全同意作者的观点,但是其不盲从轻信较劲的态度还是值得学习。

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

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

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

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

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

继续讨论,一旦内存放不下全部的数据,会怎么办呢?

有很多策略,但无非都是访问磁盘,将数据Cache到内存中。

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

来看下面的测试代码。

  1. void test_fseek_set() 
  2.     long offset; 
  3.     FILE*fp = NULL; 
  4.     long i; 
  5.  
  6.     fp = fopen(FILE_NAME, "r"); 
  7.     if(!fp) 
  8.     { 
  9.         printf("Open file fail.\n"); 
  10.         printf("%s\n",strerror(errno)); 
  11.         exit(-1); 
  12.     }    
  13.  
  14.     for(i=0; i<TIMES; i++) 
  15.     { 
  16.         //Because random max is 1<<30 - 1 
  17.         offset = random() * 10 % MAX_FILE; 
  18.         if(fseek(fp, offset, SEEK_SET)) 
  19.         { 
  20.             printf("fseek error.\n"); 
  21.             printf("%ld",offset); 
  22.             printf("%s\n",strerror(errno)); 
  23.         } 
  24.     }    
  25.  
  26.     fclose(fp); 

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

答案是QPS<=80。

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

  1. sync; echo 3 > /proc/sys/vm/drop_caches 

很多时候,之所以我们能在小数据时达到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性能,并不是一定要尽量把所有数据放到内存,实际上只要保证了热数据都能装在内存中就够了。
  • 作者举例中的程序,主要用了磁盘seek,磁盘的seek速度慢,原本就是磁盘物理结构的硬伤,所以许多NoSQL存储采用了变随机写为顺序写的方式,减少磁盘seek操作,也是提升IO性能的良方。

【编辑推荐】

  1. MongoDB之父:MongoDB胜过BigTable
  2. 主流NoSQL数据库全方位评测之MongoDB
  3. 教你如何利用MySQL学习MongoDB
  4. 在Windows环境下MongoDB搭建和简单操作
  5. Mongodb源码分析之Mongos分析
责任编辑:艾婧 来源: 开源中国社区
相关推荐

2020-07-03 14:05:26

Serverless云服务商

2022-03-14 08:33:09

TypeScriptJavaScript前端

2021-11-29 18:27:12

Web Wasmjs

2019-09-23 13:37:09

Anthos谷歌Kubernetes

2023-05-05 16:26:33

2011-10-27 13:37:51

网页设计

2018-07-02 14:31:47

健康品牌

2019-01-18 15:01:17

云计算运维管理

2023-03-21 10:16:36

2021-02-25 14:09:55

人工智能数据机器学习

2023-05-04 07:44:13

编程界小语言Java

2019-09-23 13:10:02

容器进程

2012-02-08 10:02:53

Web

2018-01-23 11:48:17

Vue.js前端开发

2021-01-14 15:34:53

区块链比特币机器

2015-04-16 15:42:21

关系型数据库NoSQL

2017-10-02 11:53:17

数据库SQLNoSQL

2023-07-19 08:00:00

Raft分布式系统

2022-05-20 11:41:00

数据科学编程语言Python

2023-05-17 16:37:29

点赞
收藏

51CTO技术栈公众号