MongoDB性能分析

MongoDB 性能测试报告 1 测试点 测试点包括 1. 磁盘占用情况 a) 1000w数据磁盘占用情况 2. 批量导入性能 a) 批量导入速度， mongoimport b) 导入过程中对查询性能的影响 3. 查询性能 a) kw 数据集级别的 key-value 查询速度，针对 java driver b) 并发查询性能，针对 java driver 多线程查询 4. 系统稳定性 a) 运行稳定性 b) 备份 方案 气瓶 现场处置方案 .pdf气瓶 现场处置方案 .doc见习基地管理方案.doc关于群访事件的化解方案建筑工地扬尘治理专项方案下载 可用性 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 索引情况: 单一索引和复合索引 导入方式: 本地导入和远程导入 导入耗时情况如下 表 关于同志近三年现实表现材料材料类招标技术评分表图表与交易pdf视力表打印pdf用图表说话 pdf 所示， 从中可以看出 1. 平均导入速度为 3w 行/秒。 2. 索引个数对导入性能影响不大。 3. 由于测试环境的机器都在一个网段内，远程导入和本地导入差别也不是很明显。 导入过程中的磁盘占用情况如下，包括数据和索引。 从中可以看出复合索引比单一索引多占用一定的磁盘空间，空间占用不是纯粹按倍数增长， 这是与 monogdb 的数据预分配策略有关的 说明: mongodb 出于性能考虑，采用预分配方式。 每个个数据库的文件集从序号 0 开 始分配，大小依次是 64M，128M，256M，512M，1G，2G，然后就是一直 2G 的创建下去 （32 位系统最大到 512M，因为有文件大小限制）。所以如果上一个文件是 1G，而数据量刚 好超过 1G，则下一个文件（大小为 2G)则可能有超过 90%都是空的。 Case2. 测试批量导入数据的耗时，每次导入的数据量翻倍。 每次导入 2kw 数据，共导入 10kw 数据 数据库 Collection 索引情况: 单一索引和复合索引 导入方式: 本地导入 导入耗时情况如下表所示， 1 2 3 4 5 6 7 8 9 10 (1index)本地导入耗时(秒) 308 317 335 333 324 321 328 330 319 315 (1index)远程导入耗时(秒) 296 379 314 358 322 334 310 326 327 329 (2index)本地导入耗时(秒) 297 311 339 333 328 328 322 318 314 352 (2index)远程导入耗时(秒) 279 280 315 331 330 330 329 336 328 335 250 270 290 310 330 350 370 390 导 入 耗 时 (秒 ) 批量导入耗时情况 1kw 2kw 3kw 4kw 5kw 6kw 7kw 8kw 9kw 10kw (1index)磁盘占用(GB) 8 14 20 26 32 38 44 50 56 60 (2index)磁盘占用(GB) 8 14 22 30 38 44 50 58 62 68 0 10 20 30 40 50 60 70 80 占 用 空 间 (G B ) 磁盘占用情况 从中可以看出 1. 平均导入速度约为 3w行/秒。 2. 一次导入 2kw 和导入 1kw对导入性能影响不大 3.1.2 批量导入性能拐点测试 Case1. 测试批量导入性能的拐点，远程导入，每次导入 1kw 每次导入 1kw 数据，共导入 50kw 数据 数据库 Collection 索引情况:复合索引 导入方式: 远程导入 导入耗时情况如下 从中可以看出当数据量达到 15KW时，导入性能就开始出现明显下降 Case2. 测试批量导入性能的拐点，本地导入， 每次导入 2kw 每次导入 2kw 数据，共导入 50kw 数据 数据库 Collection 索引情况:复合索引 1 2 3 4 5 (1index)本地导入耗时 (秒) 635 640 686 652 638 (2index)本地导入耗时 (秒) 643 654 647 671 642 630 640 650 660 670 680 690 导 入 耗 时 (秒 ) 批量导入耗时情况 300 800 1300 1800 2300 2800 1 3 5 7 9 11 13 15 17 19 21 23 25 27 29 31 33 35 37 39 41 43 45 47 49 导 入 耗 时 (秒 ) 批量导入性能拐点 导入方式: 本地导入 导入耗时情况如下 从中可以看出当数据量达到 16KW时，导入性能就开始出现明显下降。 磁盘占用情况如下 从中可以看出磁盘占用为线性增长，50KW 数据共占用 269GB 空间 3.1.3 查询性能测试 Case1. 测试 1kw 数据的查询耗时情况 数据量 1kw Collection 索引情况:复合索引 查询策略:随机生成主键 id作为一次查询， 共执行 10批查询，次数从 1w 次到 10w 次 ，以 1w次为间隔 并发策略: 分为单线程，8线程，16 线程，32 线程 不同并发情况查询耗时如下 600 1600 2600 3600 4600 5600 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 导 入 耗 时 (秒 ) 批量导入性能拐点 0 100 200 300 2 kw 4 kw 6 kw 8 kw 1 0 kw 1 2 kw 1 4 kw 1 6 kw 1 8 kw 2 0 kw 2 2 kw 2 4 kw 2 6 kw 2 8 kw 3 0 kw 3 2 kw 3 4 kw 3 6 kw 3 8 kw 4 0 kw 4 2 kw 4 4 kw 4 6 kw 4 8 kw 5 0 kw 磁 盘 占 用 (G B ) 批量导入磁盘占用情况 不同并发下每次查询平均耗时情况如下 线程数 每次查询平均耗时 (ms/query) 1 0。073 8 0。028 16 0。032 32 0。032 从中可以看出当查询线程达到 8 到 16 左右时，系统吞吐量基本饱和。 Case2. 测试数据导入过程中的查询耗时情况 数据量 1kw， 查询发生在再导入 1kw数据的过程中 Collection 索引情况:复合索引 查询策略:随机生成主键 id作为一次查询， 共执行 10批查询，次数从 1w 次到 10w 次，以 1w 次为间隔 并发策略: 分为单线程，8线程，16 线程，32 线程 不同并发情况查询耗时如下 不同并发下每次查询平均耗时情况如下 线程数 每次查询平均耗时 (ms/query) 1w 2w 3w 4w 5w 6w 7w 8w 9w 10w 1 thread 1453 1610 2218 2943 3855 4126 4925 5544 6421 7085 8 thread 473 698 843 998 1632 1552 1942 2202 3393 2117 16 thread 459 591 867 1123 2051 1463 2147 2419 3650 3160 32 thread 515 584 866 969 2041 1453 2137 2408 3623 3145 400 1400 2400 3400 4400 5400 6400 7400 查 询 耗 时 (毫 秒 ) 1kw数据查询耗时 1w 2w 3w 4w 5w 6w 7w 8w 9w 10w 1 thread 1738 1819 3163 4110 4776 6053 6865 8014 8968 10611 8 thread 601 941 1131 1351 1300 1659 1881 2257 2490 2743 16 thread 675 1085 1336 3343 1459 1864 2096 3318 2844 3016 32 thread 623 1240 1152 1538 1507 1885 2114 2542 2796 3214 400 2400 4400 6400 8400 10400 查 询 耗 时 （ 毫 秒 ） 导入过程中查询耗时（基础1kw） 1 0。010 8 0。029 16 0。038 32 0。033 从中可以看出导入数据过程会有写锁产生，对查询性能有略微影响。 Case3. 测试数据导入过程中的查询耗时情况，基础数据量翻倍 数据量 2kw， 查询发生在再导入 1kw数据的过程中 Collection 索引情况:复合索引 查询策略:随机生成主键 id作为一次查询， 共执行 10批查询，次数从 1w 次到 10w 次，以 1w 次为间隔 并发策略: 分为单线程，8线程，16 线程，32 线程 不同并发情况查询耗时如下 不同并发下每次查询平均耗时情况如下 线程数 每次查询平均耗时 (ms/query) 1 0。010 8 0。034 16 0。040 32 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 线程 不同并发情况每次查询平均耗时如下 其中 50kw的 32 线程由于耗时较长，且跟 16 线程相近，所以没有单独测试 从中可以看出当数据量达到 4KW 时。查询性能就开始出现较大幅度下降。 3.2 2 shards 3.2.1 服务部署情况 其中 Server1和 Server2 为同一网段机器，部署两个分片，Server1 还部署了 mongo 的 config server， Server3 在其他网段， mongos 为 mongodb 的前端路由，为方便使用，部署在 3 台 机器上。 3.2.2 批量导入性能测试 Case1. 测试批量导入数据的耗时和磁盘占用情况 每次导入 1kw 数据，共导入 10kw 数据 数据库 Collection 索引情况: 单一索引 导入方式: 从 Server3 远程导入 导入耗时情况如下表所示 1kw 2kw 3kw 4kw 10kw 50kw 1 thread 0.0731 0.0898 0.1137 5.9677 81.1236 495.8382 8 thread 0.0288 0.0309 0.0366 1.9970 27.4424 164.1371 16 thread 0.0326 0.0350 0.0397 1.7681 24.3073 159.8656 32 thread 0.0323 0.0338 0.0384 1.7713 22.9858 0.0000 0.0000 100.0000 200.0000 300.0000 400.0000 500.0000 600.0000 每 次 查 询 平 均 耗 时 （ 毫 秒 ） 查询性能拐点情况 Server1 •shard1 •config •mongos Server2 •shard2 •mongos Server3 •mongos 从中可以看出平均导入速度为 2。9W行/秒，跟单机导入性能保持一致。 磁盘占用情况如下 从中可以看出由于测试数据比较规整，根据 SHARD KEY 能均匀分布在两个分片中。 数据总量较单机情况会有所上升。应该是由于 MONOGODB 的预分配机制导致。 3.2.3 批量导入性能拐点测试 Case1. 测试批量导入性能的拐点，远程导入，每次导入 1kw 每次导入 1kw 数据，共导入 50kw 数据 数据库 Collection 索引情况:单一索引 导入方式: 从 Server 远程导入 导入耗时情况如下 1kw 2kw 3kw 4kw 5kw 6kw 7kw 8kw 9kw 10kw 导入耗时(秒) 326 357 333 354 385 349 326 344 344 320 300 330 360 390 导 入 耗 时 (秒 ) 批量导入耗时情况 1kw 2kw 3kw 4kw 5kw 6kw 7kw 8kw 9kw 10kw shard1 6.2 8.4 11 15 18 20 24 28 32 36 shard2 6.2 8 11 15 17 21 23 30 34 36 0 10 20 30 40 占 用 空 间 (G B ) 磁盘占用情况 从中可以看出 1. 2 shards的批量导入性能相对单机有明显提升。 2. 30kw数据处开始出现性能拐点，但性能下降不是很快，预计更大的拐点在 50kw 数据以 后。 3.2.4 查询性能测试 Case1. 测试 1kw 数据查询性能， 查询方与数据库不在相同网段，使用本地 mongos 数据量 1kw Collection 索引情况:单一索引 查询策略:随机生成主键 id作为一次查询， 共执行10批查询，次数从1w次到10w， 以 1w 次为间隔 并发策略: 分为单线程，8线程，16 线程，32 线程 查询方:由 Server3 发起查询，使用本地 mongos 不同并发情况查询耗时如下 Case2. 测试 1kw 数据查询性能， 查询方与数据库不在相同网段，使用远程数据库的 0 100 200 300 400 500 600 700 800 1 3 5 7 9 11 13 15 17 19 21 23 25 27 29 31 33 35 37 39 41 43 45 47 49 导 入 耗 时 （ 秒 ） 批量导入性能拐点测试 1w 2w 3w 4w 5w 6w 7w 8w 9w 10w 1 thread 6562 11612 21794 34581 35272 34436 49492 46039 65643 72939 8 thread 1258 2323 3501 4793 6085 7014 8316 9330 10736 11805 16 thread 866 1546 2347 3138 4476 4357 5555 6506 8077 8110 32 thread 912 1569 2458 2938 4431 4432 5518 6280 7936 7913 0 10000 20000 30000 40000 50000 60000 70000 80000 查 询 耗 时 (毫 秒 ) 1kw数据查询耗时情况 mongos 数据量 1kw Collection 索引情况:单一索引 查询策略:随机生成主键 id作为一次查询， 共执行 10批查询，次数从 1w 次到 10w 次，以 1w 次为间隔。 并发策略: 分为单线程，8线程，16 线程，32 线程 查询方:由 Server3 发起查询，使用远程 mongos 不同并发情况查询耗时如下 Case3. 测试 1kw 数据查询性能， 查询方与数据库在相同网段，使用本地 mongos 数据量 1kw Collection 索引情况:单一索引 查询策略:随机生成主键 id作为一次查询， 共执行 10批查询，次数从 1w 次到 10w 次，以 1w 次为步进值 并发策略: 分为单线程，8线程，16 线程，32 线程 查询方:由 Server3发起查询，使用本地 mongos 不同并发情况查询耗时如下 1w 2w 3w 4w 5w 6w 7w 8w 9w 10w 1 thread 6849 12297 18513 24648 45424 54469 43916 50217 56189 62618 8 thread 1303 2419 3671 4860 6477 7323 8672 9923 12085 11757 16 thread 890 1715 2512 3366 5085 4787 6108 7168 8598 9023 32 thread 944 1770 2591 3531 5214 4965 6092 7162 8745 8973 0 10000 20000 30000 40000 50000 60000 70000 查 询 耗 时 (毫 秒 ) 1kw数据查询耗时情况 前面三个 case不同并发下每次查询平均耗时情况如下 线程数 Case1 查询平均耗时 (ms/query) Case2 查询平均耗时 (ms/query) Case3 查询平均耗时 (ms/query) 1 0。688 0。682 0。161 8 0。118 0。125 0。038 16 0。082 0。090 0。038 32 0。081 0。091 0。038 从中可以看出 1. 使用本地 MONGOS 和远程 MONGOS 性能较为接近，本地 MONGOS 性能会略微好些 2. 使用 SERVER2 查询速度有明显提高。主要原因一方面是 SHARD2 所在机器，另一方面 是相同网段。 3. 同单机一样，线程数为 8-16 时，系统吞吐量达到饱和。 Case4. 测试数据导入过程的查询性能 数据量分别为 1kw， 2kw， 3kw Collection 索引情况:单一索引 查询策略: 随机生成主键 id 作为一次查询，共执行 10 批查询，次数从 1w次到 10w 次，以 1w 次为间隔， 分别对比各级数据量和再导入 1kw过程的查询耗时 并发策略: 分为单线程，8线程，16 线程，32 线程 不同并发情况每次查询平均耗时如下 1w 2w 3w 4w 5w 6w 7w 8w 9w 10w 1 thread 2375 3310 4855 6333 7991 9102 11243 12704 14746 16068 8 thread 562 757 1106 1570 2181 2183 2610 2924 3432 3753 16 thread 572 709 1012 1322 2291 1758 2494 2827 4100 3655 32 thread 596 702 1187 1187 2308 1779 2508 2839 4101 3685 0 4000 8000 12000 16000 20000 查 询 耗 时 (毫 秒 ) 1kw数据查询耗时情况 其中 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 不同并发情况每次查询平均耗时如下 1kw 1kw+1kw 2kw 2kw+lkw 3kw 3kw+1kw 1 thread 0.6879 0.8139 0.6255 0.7160 0.7686 0.0000 8 thread 0.1185 0.1077 0.1254 0.1698 0.1137 0.1229 16 thread 0.0818 0.0834 0.0852 0.0910 0.0917 0.1049 32 thread 0.0807 0.0826 0.0833 0.1155 0.0899 0.1598 0.0000 0.2000 0.4000 0.6000 0.8000 1.0000 每 次 查 询 平 均 耗 时 (毫 秒 ) 数据导入过程中查询情况比较 从中可以看出 1．当数据量达到 8KW时。查询性能就开始出现较大幅度下降。 2． 相比单机情况的 4KW拐点，可以发现在数据均匀分布的情况下，拐点出现的数 据量可以成倍增长 3。 相对单机本地查询的性能，2 SHARDS 远程查询性能有所下降，但这应该是由 于跨网段是原因导致，所以基本可以认为数据量相同情况下，2 SHARDS 的查询性能 跟单机情况一致。 3.3 2 shards + 2 replicas 3.3.1 服务部署情况 其中 Server1，Server2 在相同网段，Server3 和 Server4 在相同网段 3.3.2 批量导入性能测试 Case1. 测试批量导入性能的拐点，远程导入，每次导入 1kw 每次导入 1kw 数据，共导入 10kw 数据 数据库 Collection 索引情况:单一索引 1kw 2kw 3kw 4kw 5kw 6kw 7kw 8kw 9kw 10kw 50kw 8 thread 0.118 0.125 0.113 0.138 0.128 0.134 0.186 1.235 6.288 10.59 72.73 16 thread 0.081 0.085 0.091 0.100 0.103 0.108 0.115 1.232 4.829 7.907 63.82 32 thread 0.080 0.083 0.089 0.097 0.103 0.107 0.114 1.210 4.177 6.609 60.57 0.0000 20.0000 40.0000 60.0000 80.0000 每 次 查 询 平 均 耗 时 (毫 秒 ) 2 shards查询性能拐点测试 Server1 •shard1 •config •mongos Server2 •replica1 •mongos Server3 •shard2 •mongos Server4 •replica2 •mongos 导入方式: 从 Server2远程导入 导入耗时情况如下 从中可以看出 1. 由于两个 SHARD 不在相同网段，且 YF网速较慢，此种情况下平均导入速度为 1。8W 行/秒 2. 10KW数据下性能拐点不明显。 3.3.3 查询性能测试 Case1. 测试查询性能变化的拐点 数据量为 1kw 到 10kw，以 1kw为间隔 Collection 索引情况:单一索引 查询策略: 随机生成主键 id 作为一次查询 共执行 10 批查询，次数从 1k 次到 1w 次，以 1k 次为间隔 并发策略: 分为 8 线程，16 线程 查询方:由 Server2发起查询，使用本地 mongos 不同并发情况每次查询平均耗时如下 从中可以看出 1. 数据量较小情况，查询性能跟同网段 2 SHARDS 情况相近 1 2 3 4 5 6 7 8 9 10 导入耗时（秒） 428 384 520 568 599 558 560 563 622 616 0 200 400 600 800 导 入 耗 时 （ 秒 ） 批量导入耗时情况 1kw 2kw 3kw 4kw 5kw 6kw 7kw 8kw 9kw 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 0.0000 5.0000 10.0000 15.0000 20.0000 25.0000 每 次 查 询 平 均 耗 时 （ 毫 秒 ） 2shards+2replica查询平均耗时情况 2. 当数据量达到 6KW 时，查询性能出现明显下降，不过比较同网段 2 SHARDS 的情况， 跨网段对查询性能影响比较大。 3.4 4 shards + 4 replicas 3.4.1 服务部署情况 由于 Server3，Server4 所在网段的网络较差，Server4 本身也有一定问题，所以把分片集中 部署到 Server1，Server2 上 3.4.2 批量导入性能测试 Case1. 测试批量导入性能 每次导入 1kw 数据，共导入 32kw 数据 数据库 Collection 索引情况:复合索引 导入方式: 从 Server3远程导入 导入耗时情况如下 从中可以看出 1. 总体平均导入时间 1。6W 行/秒 2. 随着数据量增大，导入性能逐渐下降，性能拐点大约出现在 20KW数据量 Server1 •shard1 •shard2 •config •mongos Server2 •shard3 •shard4 •mongos Server3 •replica1 •replica2 •mongos Server4 •replica 3 •replica4 •mongos 0 400 800 1200 1600 1 3 5 7 9 11 13 15 17 19 21 23 25 27 29 31 批量导入耗时情况 导入耗时（秒） 3.4.3 查询性能测试 Case1. 测试查询性能变化的拐点 数据量为 1kw 到 32kw，以 1kw为间隔 Collection 索引情况:单一索引 查询策略: 随机生成主键 id 作为一次查询 对于 1kw 到 12kw分别执行 10批查询，次数从 1k次到 1w次，以 1k 次为间隔 对于 12kw以上，分别执行 10批查询，次数从 100次到 1k次，以 100 次为间隔 并发策略: 分为 8 线程，16 线程 查询方:由 Server3发起查询，使用本地 mongos 不同并发情况每次查询平均耗时如下 从中可以看出 1. 4 SHARDS 情况下，性能拐点出现在 8KW数据量，随着数据量增加，查询耗时随着一 个缓慢的曲线上升。 2. 在相同物理节点条件下，增加分片对查询性能没有明显改善，性能拐点也跟 2 SHARDS 一致。 4 总结 根据测试结果，下面简单总结一下 1. MongoDB 在千万级数据量的批量导入性能和查询性能跟 mysql 相比有较大的优势。 2. MongoDB 的分片机制可以在大数据量情况大幅度提升批量导入性能和查询性能， MongDB 的性能具有可扩展性。 3. MongoDB 在正确配置情况下，稳定性良好，在有备份机制的情况下具备自动恢复的能 力。分片机制能动态的根据网络情况调整分片的分布情况，分片在运行过程也是可以动 态增加的。 4. MongoDB 在数据导入过程中，索引会自动建立，有部分写锁，但对查询性能影响不是 很大，不会造成停止响应。 0.0000 10.0000 20.0000 30.0000 40.0000 50.0000 1kw 3kw 5kw 7kw 9kw 11kw13kw15kw17kw19kw21kw23kw25kw27kw29kw31kw 4 shards 查询平均耗时情况 8 thread (ms) 16 thread (ms)