MongoDB性能测试报告

MongoDB性能测试报告

1 测试点

测试点包括

1. 磁盘占用情况

a) 1000w数据磁盘占用情况

2. 批量导入性能

a) 批量导入速度， mongoimport

b) 导入过程中对查询性能的影响

3. 查询性能

a) kw数据集级别的key-value查询速度，针对java driver

b) 并发查询性能，针对java driver 多线程查询

4. 系统稳定性

a) 运行稳定性

b) 备份方案可用性

c) 单个节点负载

2 测试环境

2.1 硬件环境

Server *4

CPU : Intel Xeon E5620 @ 2.40GHz 8core

Memory: 16G

2.2 软件环境

OS: Red Hat Enterprise Linux AS release 4 (Nahant Update 3) kernel 2.6.9_5-9-0-0

FileSystem: Ext2

MongoDB: mongodb-linux-x86_64-1.6.3

2.3 测试数据集

2.3.1 生成方式

采用简单的行数据，每行包括long， int， date， string， double类型各一个字段，

由程序计数生成样本数据集。

2.3.2 测试数据集规模

每个数据集为1000w 数据(每行5个字段，包括一个较长的字符串) ，磁盘占用 2.8G。

3 测试结果

3.1 Single node

Java driver 插入1000w数据，总耗时为 547s ，平均每秒插入18281行

Java driver性能稍低，且不是应用场景，不再做复杂测试。

下面着重测试mongoimport导入csv文件的情况。

3.1.1 批量导入性能测试

Case1. 测试批量导入数据的耗时和磁盘占用情况

每次导入1kw数据，共导入10kw数据

数据库Collection索引情况: 单一索引和复合索引

导入方式: 本地导入和远程导入

导入耗时情况如下表所示，

批量导入耗时情况

390

370

350

330

310

290

270

250

导

入

耗

时

(

秒

)

(1index)本地导入耗时(秒)

3243215

(1index)远程导入耗时(秒)

296379331

(2index)本地导入耗时(秒)

2973328322318314352

(2index)远程导入耗时(秒)

279285

从中可以看出

1. 平均导入速度为 3w行/秒。

2. 索引个数对导入性能影响不大。

3. 由于测试环境的机器都在一个网段内，远程导入和本地导入差别也不是很明显。

导入过程中的磁盘占用情况如下，包括数据和索引。

磁盘占用情况

80

70

60

50

40

30

20

10

0

(1index)磁盘占用(GB)

占

用

空

间

(

G

B

)

1kw

8

8

2kw

14

14

3kw

20

22

4kw

26

30

5kw

32

38

6kw

38

44

7kw

44

50

8kw

50

58

9kw10kw

56

62

60

68

(2index)磁盘占用(GB)

从中可以看出复合索引比单一索引多占用一定的磁盘空间，空间占用不是纯粹按倍数增长，

这是与monogdb的数据预分配策略有关的

说明: mongodb出于性能考虑，采用预分配方式。 每个个数据库的文件集从序号0开

始分配，大小依次是64M，128M，256M，512M，1G，2G，然后就是一直2G的创建下去

（32位系统最大到512M，因为有文件大小限制）。所以如果上一个文件是1G，而数据量刚

好超过1G，则下一个文件（大小为2G)则可能有超过90%都是空的。

Case2. 测试批量导入数据的耗时，每次导入的数据量翻倍。

每次导入2kw数据，共导入10kw数据

数据库Collection索引情况: 单一索引和复合索引

导入方式: 本地导入

导入耗时情况如下表所示，

批量导入耗时情况

690

680

670

660

650

640

630

(1index)本地导入耗时

(秒)

(2index)本地导入耗时

(秒)

导

入

耗

时

(

秒

)

1

635

643

2

640

654

3

686

647

4

652

671

5

638

642

从中可以看出

1. 平均导入速度约为 3w行/秒。

2. 一次导入2kw和导入1kw对导入性能影响不大

3.1.2 批量导入性能拐点测试

Case1. 测试批量导入性能的拐点，远程导入，每次导入1kw

每次导入1kw数据，共导入50kw数据

数据库Collection索引情况:复合索引

导入方式: 远程导入

导入耗时情况如下

批量导入性能拐点

2800

导

入

耗

时

(

秒

)

2300

1800

1300

800

300

729343454749

从中可以看出当数据量达到15

KW

时，导入性能就开始出现明显下降

Case2. 测试批量导入性能的拐点，本地导入， 每次导入2kw

每次导入2kw数据，共导入50kw数据

数据库Collection索引情况:复合索引

导入方式: 本地导入

导入耗时情况如下

批量导入性能拐点

5600

导

入

耗

时

(

秒

)

4600

3600

2600

1600

600

1718192

从中可以看出当数据量达到16

KW

时，导入性能就开始出现明显下降。

磁盘占用情况如下

批量导入磁盘占用情况

磁

盘

占

用

(

G

B

)

300

200

100

0

2

k

w

4

k

w

6

k

w

8

k

w

1

0

k

w

1

2

k

w

1

4

k

w

1

6

k

w

1

8

k

w

2

0

k

w

2

2

k

w

2

4

k

w

2

6

k

w

2

8

k

w

3

0

k

w

3

2

k

w

3

4

k

w

3

6

k

w

3

8

k

w

4

0

k

w

4

2

k

w

4

4

k

w

4

6

k

w

4

8

k

w

5

0

k

w

从中可以看出磁盘占用为线性增长，50

KW

数据共占用269GB空间

3.1.3 查询性能测试

Case1.

测试1kw数据的查询耗时情况

数据量1kw

Collection索引情况:复合索引

查询策略:随机生成主键id作为一次查询， 共执行10批查询，次数从1w次到10w

次

，以1w次为间隔

并发策略: 分为单线程，8线程，16线程，32线程

不同并发情况查询耗时如下

1kw数据查询耗时

查

询

耗

时

(

毫

秒

)

7400

6400

5400

4400

3400

2400

1400

400

1 thread

8 thread

16 thread

32 thread

1w

1453

473

459

515

2w

1610

698

591

584

3w

2218

843

867

866

4w

2943

998

1123

969

5w

3855

1632

2051

2041

6w

4126

1552

1463

1453

7w

4925

1942

2147

2137

8w

5544

2202

2419

2408

9w

6421

3393

3650

3623

10w

7085

2117

3160

3145

不同并发下每次查询平均耗时情况如下

线程数

1

8

16

32

每次查询平均耗时 (ms/query)

0。073

0。028

0。032

0。032

从中可以看出当查询线程达到8到16左右时，系统吞吐量基本饱和。

Case2. 测试数据导入过程中的查询耗时情况

数据量1kw， 查询发生在再导入1kw数据的过程中

Collection索引情况:复合索引

查询策略:随机生成主键id作为一次查询， 共执行10批查询，次数从1w次到10w

次，以1w次为间隔

并发策略: 分为单线程，8线程，16线程，32线程

不同并发情况查询耗时如下

导入过程中查询耗时（基础1kw）

查

询

耗

时

（

毫

秒

）

10400

8400

6400

4400

2400

400

1 thread

8 thread

16 thread

32 thread

1w

1738

601

2w

1819

941

3w

3163

1131

4w

4110

1351

5w

4776

1300

6w

6053

1659

7w

6865

1881

8w

8014

2257

9w

2490

10w

2743

896810611

675

623

1085

1240

1336

1152

3343

1538

1459

1507

1864

1885

2096

2114

3318

2542

2844

2796

3016

3214

不同并发下每次查询平均耗时情况如下

线程数 每次查询平均耗时 (ms/query)

1

8

16

32

0。010

0。029

0。038

0。033

从中可以看出导入数据过程会有写锁产生，对查询性能有略微影响。

Case3. 测试数据导入过程中的查询耗时情况，基础数据量翻倍

数据量2kw， 查询发生在再导入1kw数据的过程中

Collection索引情况:复合索引

查询策略:随机生成主键id作为一次查询， 共执行10批查询，次数从1w次到10w

次，以1w次为间隔

并发策略: 分为单线程，8线程，16线程，32线程

不同并发情况查询耗时如下

不同并发下每次查询平均耗时情况如下

线程数

1

8

16

32

每次查询平均耗时 (ms/query)

0。010

0。034

0。040

0。036

从中可以看出随着基础数据量上升，导入过程中查询性能也会受到影响

3.1.4 查询性能拐点测试

Case1.

测试查询性能变化的拐点

数据量分别为1kw， 2kw， 3kw， 4kw，10kw，50kw

Collection索引情况:复合索引

查询策略: 随机生成主键id作为一次查询

对于1kw，2kw，3kw共执行10批查询，次数从1w次到10w次，以1w次为间隔

对于4kw共执行10批查询，次数从1k次到10k次，以1k次为间隔

对于10kw，50kw共执行10批查询，次数从100次到1k次，以100次为间隔

并发策略: 分为单线程，8线程，16线程，32线程

不同并发情况每次查询平均耗时如下

查询性能拐点情况

每

次

查

询

平

均

耗

时

（

毫

秒

）

600.0000

500.0000

400.0000

300.0000

200.0000

100.0000

0.0000

1 thread

8 thread

16 thread

32 thread

1kw

0.0731

0.0288

0.0326

0.0323

2kw

0.0898

0.0309

0.0350

0.0338

3kw

0.1137

0.0366

0.0397

0.0384

4kw

5.9677

1.9970

1.7681

1.7713

10kw

81.1236

27.4424

24.3073

22.9858

50kw

495.8382

164.1371

159.8656

0.0000

其中50kw的32线程由于耗时较长，且跟16线程相近，所以没有单独测试

从中可以看出当数据量达到4

KW

时。查询性能就开始出现较大幅度下降。

3.2 2 shards

3.2.1 服务部署情况

Server1

•shard1

•config

•mongos

Server2

•shard2

•mongos

Server3

•mongos

其中Server1和Server2为同一网段机器，部署两个分片，Server1还部署了mongo的config

server， Server3在其他网段， mongos为mongodb的前端路由，为方便使用，部署在3台

机器上。

3.2.2 批量导入性能测试

Case1.

测试批量导入数据的耗时和磁盘占用情况

每次导入1kw数据，共导入10kw数据

数据库Collection索引情况: 单一索引

导入方式: 从Server3远程导入

导入耗时情况如下表所示

批量导入耗时情况

390

导

入

耗

时

(

秒

)

360

330

300

1kw2kw

357

3kw

333

4kw

354

5kw

385

6kw

349

7kw

326

8kw

344

9kw10kw

344320

导入耗时(秒)

326

从中可以看出平均导入速度为2。9

W

行/秒，跟单机导入性能保持一致。

磁盘占用情况如下

磁盘占用情况

占

用

空

间

(

G

B

)

40

30

20

10

0

1kw2kw

8.4

8

3kw

11

11

4kw

15

15

5kw

18

17

6kw

20

21

7kw

24

23

8kw

28

30

9kw10kw

32

34

36

36

shard1

6.2

shard2

6.2

从中可以看出由于测试数据比较规整，根据

SHARD KEY

能均匀分布在两个分片中。

数据总量较单机情况会有所上升。应该是由于

MONOGODB

的预分配机制导致。

3.2.3 批量导入性能拐点测试

Case1. 测试批量导入性能的拐点，远程导入，每次导入1kw

每次导入1kw数据，共导入50kw数据

数据库Collection索引情况:单一索引

导入方式: 从Server远程导入

导入耗时情况如下

批量导入性能拐点测试

800

导

入

耗

时

（

秒

）

700

600

500

400

300

200

100

0

729343454749

从中可以看出

1. 2 shards的批量导入性能相对单机有明显提升。

2. 30kw数据处开始出现性能拐点，但性能下降不是很快，预计更大的拐点在50kw数据以

后。

3.2.4 查询性能测试

Case1. 测试1kw数据查询性能， 查询方与数据库不在相同网段，使用本地mongos

数据量1kw

Collection索引情况:单一索引

查询策略:随机生成主键id作为一次查询， 共执行10批查询，次数从1w次到10w，

以1w次为间隔

并发策略: 分为单线程，8线程，16线程，32线程

查询方:由Server3发起查询，使用本地mongos

不同并发情况查询耗时如下

1kw数据查询耗时情况

80000

70000

60000

50000

40000

30000

20000

10000

0

1 thread

8 thread

16 thread

32 thread

查

询

耗

时

(

毫

秒

)

1w

1258

866

912

2w

2323

1546

1569

3w

3501

2347

2458

4w

4793

3138

2938

5w

6085

4476

4431

6w

7014

4357

4432

7w

8316

5555

5518

8w9w10w

656245849492469

933

6506

6280

8077

7936

8110

7913

Case2. 测试1kw数据查询性能， 查询方与数据库不在相同网段，使用远程数据库的

mongos

数据量1kw

Collection索引情况:单一索引

查询策略:随机生成主键id作为一次查询， 共执行10批查询，次数从1w次到10w

次，以1w次为间隔。

并发策略: 分为单线程，8线程，16线程，32线程

查询方:由Server3发起查询，使用远程mongos

不同并发情况查询耗时如下

1kw数据查询耗时情况

70000

60000

50000

40000

30000

20000

10000

0

1 thread

8 thread

16 thread

32 thread

查

询

耗

时

(

毫

秒

)

1w

6849

1303

890

2w

2419

1715

3w

3671

2512

4w

4860

3366

5w

6477

5085

6w

7323

4787

7w

8672

6108

8w

9923

7168

9w10w

4648454245446943916518

1208511757

85989023

9443

Case3.

测试1kw数据查询性能， 查询方与数据库在相同网段，使用本地mongos

数据量1kw

Collection索引情况:单一索引

查询策略:随机生成主键id作为一次查询， 共执行10批查询，次数从1w次到10w

次，以1w次为步进值

并发策略: 分为单线程，8线程，16线程，32线程

查询方:由Server3发起查询，使用本地mongos

不同并发情况查询耗时如下

1kw数据查询耗时情况

查

询

耗

时

(

毫

秒

)

20000

16000

12000

8000

4000

0

1 thread

8 thread

16 thread

32 thread

1w

2375

562

572

596

2w

3310

757

709

702

3w

4855

1106

1012

1187

4w

6333

1570

1322

1187

5w

7991

2181

2291

2308

6w

2183

1758

1779

7w

2610

2494

2508

8w

2924

2827

2839

9w

3432

4100

4101

10w

3753

3655

3685

9

前面三个case不同并发下每次查询平均耗时情况如下

线程数

Case1

Case2 Case3

查询平均耗时 (ms/query) 查询平均耗时 (ms/query) 查询平均耗时 (ms/query)

1

8

16

32

0。688

0。118

0。082

0。081

0。682

0。125

0。090

0。091

0。161

0。038

0。038

0。038

从中可以看出

1. 使用本地

MONGOS

和远程

MONGOS

性能较为接近，本地

MONGOS

性能会略微好些

2. 使用S

ERVER

2查询速度有明显提高。主要原因一方面是

SHARD

2所在机器，另一方面

是相同网段。

3. 同单机一样，线程数为8-16时，系统吞吐量达到饱和。

Case4.

测试数据导入过程的查询性能

数据量分别为1kw， 2kw， 3kw

Collection索引情况:单一索引

查询策略: 随机生成主键id作为一次查询，共执行10批查询，次数从1w次到10w

次，以1w次为间隔， 分别对比各级数据量和再导入1kw过程的查询耗时

并发策略: 分为单线程，8线程，16线程，32线程

不同并发情况每次查询平均耗时如下

数据导入过程中查询情况比较

每

次

查

询

平

均

耗

时

(

毫

秒

)

1.0000

0.8000

0.6000

0.4000

0.2000

0.0000

1kw

0.6879

0.1185

0.0818

0.0807

1kw+1kw

0.8139

0.1077

0.0834

0.0826

2kw

0.6255

0.1254

0.0852

0.0833

2kw+lkw

0.7160

0.1698

0.0910

0.1155

3kw

0.7686

0.1137

0.0917

0.0899

3kw+1kw

0.0000

0.1229

0.1049

0.1598

1 thread

8 thread

16 thread

32 thread

其中1kw+1kw表示1kw基础上导入1kw数据的过程的查询情况。其中3kw+1kw的单线程

情况为节约时间没有测试。

从中可以看出导入过程对查询速度的有一定影响，但总体影响不是很大。

3.2.5 查询性能拐点测试

Case1.

测试查询性能变化的拐点

数据量为1kw到10kw，以1kw为间隔

Collection索引情况:单一索引

查询策略: 随机生成主键id作为一次查询

对于1kw到7kw共执行10批查询，次数从1w次到10w次，以1w次为间隔

对于8kw共执行10批查询，次数从1k次到10k次，以1k次为间隔

对于9kw，10kw共执行10批查询，次数从100次到1k次，以100次为间隔

并发策略: 分为8线程，16线程，32线程

查询方:由Server2发起查询，使用本地mongos

不同并发情况每次查询平均耗时如下

2 shards查询性能拐点测试

每

次

查

询

平

均

耗

时

(

毫

秒

)

80.0000

60.0000

40.0000

20.0000

0.0000

1kw2kw3kw4kw5kw6kw7kw8kw9kw10kw50kw

8 thread

0.1180.1250.1130.1380.1280.1340.1861.2356.28810.5972.73

16 thread

0.0810.0850.0910.1000.1030.1080.1151.2324.8297.90763.82

32 thread

0.0800.0830.0890.0970.1030.1070.1141.2104.1776.60960.57

从中可以看出

1．当数据量达到8

KW

时。查询性能就开始出现较大幅度下降。

2．

相比单机情况的4

KW

拐点，可以发现在数据均匀分布的情况下，拐点出现的数

据量可以成倍增长

3。

相对单机本地查询的性能，2

SHARDS

远程查询性能有所下降，但这应该是由

于跨网段是原因导致，所以基本可以认为数据量相同情况下，2

S

HARDS

的查询性能

跟单机情况一致。

3.3 2 shards + 2 replicas

3.3.1 服务部署情况

Server1

•shard1

•config

•mongos

Server2

•replica1

•mongos

Server3

•shard2

•mongos

Server4

•replica2

•mongos

其中Server1，Server2在相同网段，Server3和Server4在相同网段

3.3.2 批量导入性能测试

Case1. 测试批量导入性能的拐点，远程导入，每次导入1kw

每次导入1kw数据，共导入10kw数据

数据库Collection索引情况:单一索引

导入方式: 从Server2远程导入

导入耗时情况如下

批量导入耗时情况

导

入

耗

时

（

秒

）

800

600

400

200

0

导入耗时（秒）

42838452

从中可以看出

1. 由于两个

SHARD

不在相同网段，且

YF

网速较慢，此种情况下平均导入速度为1。8

W

行/秒

2. 10

KW

数据下性能拐点不明显。

3.3.3 查询性能测试

Case1.

测试查询性能变化的拐点

数据量为1kw到10kw，以1kw为间隔

Collection索引情况:单一索引

查询策略: 随机生成主键id作为一次查询

共执行10批查询，次数从1k次到1w次，以1k次为间隔

并发策略: 分为8线程，16线程

查询方:由Server2发起查询，使用本地mongos

不同并发情况每次查询平均耗时如下

2shards+2replica查询平均耗时情况

每

次

查

询

平

均

耗

时

（

毫

秒

）

25.0000

20.0000

15.0000

10.0000

5.0000

0.0000

1kw2kw3kw4kw5kw6kw7kw8kw9kw

10k

w

8 thread (ms)

0.06840.08090.75682.70994.04818.83098.446313.54715.30220.060

16 thread (ms)

0.05530.05830.53431.63693.30809.36188.117713.88117.09318.290

从中可以看出

1. 数据量较小情况，查询性能跟同网段2

SHARDS

情况相近

2. 当数据量达到6

KW

时，查询性能出现明显下降，不过比较同网段2

SHARDS

的情况，

跨网段对查询性能影响比较大。

3.4 4 shards + 4 replicas

3.4.1 服务部署情况

Server1

•shard1

•shard2

•config

•mongos

Server2

•shard3

•shard4

•mongos

Server3

•replica1

•replica2

•mongos

Server4

•replica 3

•replica4

•mongos

由于Server3，Server4所在网段的网络较差，Server4本身也有一定问题，所以把分片集中

部署到Server1，Server2上

3.4.2 批量导入性能测试

Case1. 测试批量导入性能

每次导入1kw数据，共导入32kw数据

数据库Collection索引情况:复合索引

导入方式: 从Server3远程导入

导入耗时情况如下

批量导入耗时情况

1600

1200

800

400

0

72931

导入耗时（秒）

从中可以看出

1. 总体平均导入时间1。6

W

行/秒

2. 随着数据量增大，导入性能逐渐下降，性能拐点大约出现在20

KW

数据量

3.4.3 查询性能测试

Case1.

测试查询性能变化的拐点

数据量为1kw到32kw，以1kw为间隔

Collection索引情况:单一索引

查询策略: 随机生成主键id作为一次查询

对于1kw到12kw分别执行10批查询，次数从1k次到1w次，以1k次为间隔

对于12kw以上，分别执行10批查询，次数从100次到1k次，以100次为间隔

并发策略: 分为8线程，16线程

查询方:由Server3发起查询，使用本地mongos

不同并发情况每次查询平均耗时如下

4 shards 查询平均耗时情况

50.0000

40.0000

30.0000

20.0000

10.0000

0.0000

1kw3kw5kw7kw9kw11kw13kw15kw17kw19kw21kw23kw25kw27kw29kw31kw

8 thread (ms)16 thread (ms)

从中可以看出

1. 4

SHARDS

情况下，性能拐点出现在8

KW

数据量，随着数据量增加，查询耗时随着一

个缓慢的曲线上升。

2. 在相同物理节点条件下，增加分片对查询性能没有明显改善，性能拐点也跟2

SHARDS

一致。

4 总结

根据测试结果，下面简单总结一下

1. MongoDB在千万级数据量的批量导入性能和查询性能跟mysql相比有较大的优势。

2. MongoDB的分片机制可以在大数据量情况大幅度提升批量导入性能和查询性能，

MongDB的性能具有可扩展性。

3. MongoDB在正确配置情况下，稳定性良好，在有备份机制的情况下具备自动恢复的能

力。分片机制能动态的根据网络情况调整分片的分布情况，分片在运行过程也是可以动

态增加的。

4. MongoDB在数据导入过程中，索引会自动建立，有部分写锁，但对查询性能影响不是

很大，不会造成停止响应。