Mongodb亿级数据量的性能测试

浏览数：22 / 时间：2015年06月12日

Mongodb亿级数据量的性能测试 ——转载

进行了一下Mongodb亿级数据量的性能测试，分别测试如下几个项目：

（所有插入都是单线程进行，所有读取都是多线程进行）

1）普通插入性能（插入的数据每条大约在1KB左右）

2）批量插入性能（使用的是官方C#客户端的InsertBatch），这个测的是批量插入性能能有多少提高

3）安全插入功能（确保插入成功，使用的是SafeMode.True开关），这个测的是安全插入性能会差多少

4）查询一个索引后的数字列，返回10条记录（也就是10KB）的性能，这个测的是索引查询的性能

5）查询两个索引后的数字列，返回10条记录（每条记录只返回20字节左右的2个小字段）的性能，这个测的是返回小数据量以及多一个查询条件对性能的影响

6）查询一个索引后的数字列，按照另一个索引的日期字段排序（索引建立的时候是倒序，排序也是倒序），并且Skip100条记录后返回10条记录的性能，

这个测的是Skip和Order对性能的影响

7）查询100条记录（也就是100KB）的性能（没有排序，没有条件），这个测的是大数据量的查询结果对性能的影响

8）统计随着测试的进行，总磁盘占用，索引磁盘占用以及数据磁盘占用的数量

并且每一种测试都使用单进程的Mongodb和同一台服务器开三个Mongodb进程作为Sharding（每一个进程大概只能用7GB左右的内存）两种方案

其实对于Sharding，虽然是一台机器放3个进程，但是在查询的时候每一个并行进程查询部分数据，再有运行于另外一个机器的mongos来汇总数据，

理论上来说在某些情况下性能会有点提高，基于以上的种种假设，猜测某些情况性能会下降，某些情况性能会提高，那么来看一下最后的测试结果怎么样？

备注：测试的存储服务器是 E5620 @ 2.40GHz，24GB内存，CentOs操作系统，打压机器是E5504 @ 2.0GHz，4GB内存，

Windows Server 2003操作系统，两者千兆网卡直连。

从这个测试可以看出，对于单进程的方式：

1） Mongodb的非安全插入方式，在一开始插入性能是非常高的，但是在达到了两千万条数据之后性能骤减，

这个时候恰巧是服务器24G内存基本占满的时候（随着测试的进行mongodb不断占据内存，一直到操作系统的内存全部占满），

也就是说Mongodb的内存映射方式，使得数据全部在内存中的时候速度飞快，当部分数据需要换出到磁盘上之后，性能下降很厉害。

（这个性能其实也不算太差，因为我们对三个列的数据做了索引，即使在内存满了之后每秒也能插入2MB的数据，在一开始更是每秒插入25MB数据）。

Foursquare其实也是把Mongodb当作带持久化的内存数据库使用的，只是在查不到达到内存瓶颈的时候Sharding没处理好。

2）对于批量插入功能，其实是一次提交一批数据，但是相比一次一条插入性能并没有提高多少，一来是因为网络带宽已经成为了瓶颈，二来我想写锁也会是一个原因。

3）对于安全插入功能，相对来说比较稳定，不会波动很大，我想可能是因为安全插入是确保数据直接持久化到磁盘的，而不是插入内存就完事。

4）对于一列条件的查询，性能一直比较稳定，别小看，每秒能有8000-9000的查询次数，每次返回10KB，相当于每秒查询80MB数据，

而且数据库记录是2亿之后还能维持这个水平，性能惊人。

5）对于二列条件返回小数据的查询，总体上性能会比4）好一点，可能返回的数据量小对性能提高比较大，但是相对来说性能波动也厉害一点，

可能多了一个条件就多了一个从磁盘换页的机会。

6）对于一列数据外加Sort和Skip的查询，在数据量大了之后性能明显就变差了（此时是索引数据量超过内存大小的时候，不知道是否有联系），

我猜想是Skip比较消耗性能，不过和4）相比性能也不是差距特别大。

7）对于返回大数据的查询，一秒瓶颈也有800次左右，也就是80M数据，这就进一步说明了在有索引的情况下，顺序查询和按条件搜索性能是相差无几的，

这个时候是IO和网络的瓶颈。

8）在整个过程中索引占的数据量已经占到了总数据量的相当大比例，在达到1亿4千万数据量的时候，光索引就可以占据整个内存，

此时查询性能还是非常高，插入性能也不算太差，mongodb的性能确实很牛。

看看Sharding模式有什么亮点：

1）非安全插入和单进程的配置一样，在内存满了之后性能急剧下降。安全插入性能和单进程相比慢不少，但是非常稳定。

2）对于一个条件和两个条件的查询，性能都比较稳定，但条件查询性能相当于单进程的一半，但是在多条件下有的时候甚至会比单进程高一点。

我想这可能是某些时候数据块位于两个Sharding，这样Mongos会并行在两个Sharding查询，然后在把数据进行合并汇总，

由于查询返回的数据量小，网络不太可能成为瓶颈了，使得Sharding才有出头的机会。

3）对于Order和Skip的查询，Sharding方式的差距就出来了，我想主要性能损失可能在Order，因为我们并没有按照排序字段作为Sharding的Key，

使用的是_id作为Key，这样排序就比较难进行。

4）对于返回大数据量的查询，Sharding方式其实和单进程差距不是很大，我想数据的转发可能是一个性能损耗的原因（虽然mongos位于打压机本机，

但是数据始终是转手了一次）。

5）对于磁盘空间的占用，两者其实是差不多的，其中的一些差距可能是因为多个进程都会多分配一点空间，加起来有的时候会比单进程多占用点磁盘

（而那些占用比单进程少的地方其实是开始的编码错误，把实际数据大小和磁盘文件占用大小搞错了）。

测试最后的各个Sharding分布情况如下：

 1 {
 2         "sharded" : true,
 3         "ns" : "testdb.test",
 4         "count" : 209766143,
 5         "size" : 214800530672,
 6         "avgObjSize" : 1024.0000011441311,
 7         "storageSize" : 222462757776,
 8         "nindexes" : 4,
 9         "nchunks" : 823,
10         "shards" : {
11                 "shard0000" : {
12                         "ns" : "testdb.test",
13                         "count" : 69474248,
14                         "size" : 71141630032,
15                         "avgObjSize" : 1024.0000011515058,
16                         "storageSize" : 74154252592,
17                         "numExtents" : 65,
18                         "nindexes" : 4,
19                         "lastExtentSize" : 2146426864,
20                         "paddingFactor" : 1,
21                         "flags" : 1,
22                         "totalIndexSize" : 11294125824,
23                         "indexSizes" : {
24                                 "_id_" : 2928157632,
25                                 "Number_1" : 2832745408,
26                                 "Number1_1" : 2833974208,
27                                 "Date_-1" : 2699248576
28                         },
29                         "ok" : 1
30                 },
31                 "shard0001" : {
32                         "ns" : "testdb.test",
33                         "count" : 70446092,
34                         "size" : 72136798288,
35                         "avgObjSize" : 1024.00000113562,
36                         "storageSize" : 74154252592,
37                         "numExtents" : 65,
38                         "nindexes" : 4,
39                         "lastExtentSize" : 2146426864,
40                         "paddingFactor" : 1,
41                         "flags" : 1,
42                         "totalIndexSize" : 11394068224,
43                         "indexSizes" : {
44                                 "_id_" : 2969355200,
45                                 "Number_1" : 2826453952,
46                                 "Number1_1" : 2828403648,
47                                 "Date_-1" : 2769855424
48                         },
49                         "ok" : 1
50                 },
51                 "shard0002" : {
52                         "ns" : "testdb.test",
53                         "count" : 69845803,
54                         "size" : 71522102352,
55                         "avgObjSize" : 1024.00000114538,
56                         "storageSize" : 74154252592,
57                         "numExtents" : 65,
58                         "nindexes" : 4,
59                         "lastExtentSize" : 2146426864,
60                         "paddingFactor" : 1,
61                         "flags" : 1,
62                         "totalIndexSize" : 11300515584,
63                         "indexSizes" : {
64                                 "_id_" : 2930942912,
65                                 "Number_1" : 2835243968,
66                                 "Number1_1" : 2835907520,
67                                 "Date_-1" : 2698421184
68                         },
69                         "ok" : 1
70                 }
71         },
72         "ok" : 1
73 }