一、数据增长情况
每月增长量最大达到了1.9亿，每天增长约300W-500W
（增长数据具体可看页尾）二、遇到的情况及解决方法
1.数据量过大，并且都集中在一个表，所以此表数据插入变慢。
表索引越多越明显，
优化处理方法：
1.优化索引，以前的startTime日期字段索引，
修改为客户端用日期生成ObjectId,再用_id 来进行查找。
2.TraceId 字段（一个TraceId 对应多条记录）计划也删除，后面再用ES 系统先查询到_id 后，
再从mongoDB 进行查找。
原因分析：
当表数据增长到千万级后，内存数据中的索引数据增加，内存越来越不够用，需要刷新脏数据增多，
mongostat 分析的 dirty % > 3,后从16G 内存升级到32G 内存后，情况稍有好转。 2.数据量过大后，从节点时尔出现CPU load 负载过高，从节点尤其明显。
在把表重命名，新数据插入到新表处理后：
db.TraceLogs.renameCollection("TraceLogs_bak170210");
（新数据插入时，会自动生成表TraceLogs）
历史数据表统计信息
Log:PRIMARY> db.TraceLogs_bak170210.stats()
{
"ns" : "RavenLogs.TraceLogs_bak170210",
"count" : 384453917,
"size" : 865594958942,
"avgObjSize" : 2251,
"storageSize" : 444,613,255,168,
.....
"nindexes" : 2,
"totalIndexSize" : 15275057152,
"indexSizes" : {
"_id_" : 3,973,029,888,
"TraceId_1" : 11,302,027,264
},
"ok" : 1
}
从此统计信息中可以看到：
表存储大小： 444G,
索引 _id_ 3.9G, TraceId_1 大小：11G
再次查看数据库性能
从以前的：
load average: > 5.47, 5.47, 5.47
降到了：
load average: 0.88, 1.34, 1.69
(主从节点，皆已下降)
在做历史数据迁移期间，又升到了> 8 并且时频繁出现。
完成数据迁移后，回落到 2 < load avg <: 4 之间 （升级到MongoDB3.4 之后）
原因分析：
个人认为，主因还是因为内存不够。索引+热数据远远超过了16G的MongoDB使用内存。
从而导致大量的IO，相对的CPU load 也上去了。
在把原大表TraceLogs 改名后（TraceLogs_bak170210），大量的热块数据已被清除出内存， 3.此前数据库从节点内存升级后（16G --> 32G)，参数配置不当，节点实例当机情况：
wiredTiger:
engineConfig:
cacheSizeGB: 28 (限制mongoDB 使用内存最大值)
后调整为默认值
#cacheSizeGB: 28 (限制mongoDB 使用内存最大值)，默认值为50%
mongoDB实例恢复正常，但CPU load 也一直居高不下。
原因分析：
系统使用内存太少，可能是磁盘缓存过低，而无法读写数据，但在mongoDB 日志中，
无法找到原因。只是看到实例被关闭。 4.因为oplog 同步表最大设置值(oplogSizeMB)为50G, 但50G 只能保存52h 的数量变化量。
想添加新的从节点时，当同步完成数据后，已过了oplog 的窗口期.
（oplogSizeMB的大小要大于数据同步完成+索引建立完成的时间段内生成的数据量,
当同步完成后，从节点从主节点读oplog表的数据，发现最小的同步时间，已大于从节点中
同步开始时的时间了，这就是窗口期已过期）
数据量大后，重新创建索引的时间特别惊人，一个索引需要10多个小时。
500G 存储量，总共需要3天左右的数据完成节点的数据同步及索引创建。
后面计划在添加节点前，做以下调整：
1.把数据库升级到3.4 版本，此版本在新节点数据同步，创建索引上，号称已有很大的改善。
2.删除能够优化的索引，如果索引无法优化，也可以考虑先把某个索引删除，节点完成后，再重新建立经验总结：
（增长数据具体可看页尾）二、遇到的情况及解决方法
1.数据量过大，并且都集中在一个表，所以此表数据插入变慢。
表索引越多越明显，
优化处理方法：
1.优化索引，以前的startTime日期字段索引，
修改为客户端用日期生成ObjectId,再用_id 来进行查找。
2.TraceId 字段（一个TraceId 对应多条记录）计划也删除，后面再用ES 系统先查询到_id 后，
再从mongoDB 进行查找。
原因分析：
当表数据增长到千万级后，内存数据中的索引数据增加，内存越来越不够用，需要刷新脏数据增多，
mongostat 分析的 dirty % > 3,后从16G 内存升级到32G 内存后，情况稍有好转。 2.数据量过大后，从节点时尔出现CPU load 负载过高，从节点尤其明显。
在把表重命名，新数据插入到新表处理后：
db.TraceLogs.renameCollection("TraceLogs_bak170210");
（新数据插入时，会自动生成表TraceLogs）
历史数据表统计信息
Log:PRIMARY> db.TraceLogs_bak170210.stats()
{
"ns" : "RavenLogs.TraceLogs_bak170210",
"count" : 384453917,
"size" : 865594958942,
"avgObjSize" : 2251,
"storageSize" : 444,613,255,168,
.....
"nindexes" : 2,
"totalIndexSize" : 15275057152,
"indexSizes" : {
"_id_" : 3,973,029,888,
"TraceId_1" : 11,302,027,264
},
"ok" : 1
}
从此统计信息中可以看到：
表存储大小： 444G,
索引 _id_ 3.9G, TraceId_1 大小：11G
再次查看数据库性能
从以前的：
load average: > 5.47, 5.47, 5.47
降到了：
load average: 0.88, 1.34, 1.69
(主从节点，皆已下降)
在做历史数据迁移期间，又升到了> 8 并且时频繁出现。
完成数据迁移后，回落到 2 < load avg <: 4 之间 （升级到MongoDB3.4 之后）
原因分析：
个人认为，主因还是因为内存不够。索引+热数据远远超过了16G的MongoDB使用内存。
从而导致大量的IO，相对的CPU load 也上去了。
在把原大表TraceLogs 改名后（TraceLogs_bak170210），大量的热块数据已被清除出内存， 3.此前数据库从节点内存升级后（16G --> 32G)，参数配置不当，节点实例当机情况：
wiredTiger:
engineConfig:
cacheSizeGB: 28 (限制mongoDB 使用内存最大值)
后调整为默认值
#cacheSizeGB: 28 (限制mongoDB 使用内存最大值)，默认值为50%
mongoDB实例恢复正常，但CPU load 也一直居高不下。
原因分析：
系统使用内存太少，可能是磁盘缓存过低，而无法读写数据，但在mongoDB 日志中，
无法找到原因。只是看到实例被关闭。 4.因为oplog 同步表最大设置值(oplogSizeMB)为50G, 但50G 只能保存52h 的数量变化量。
想添加新的从节点时，当同步完成数据后，已过了oplog 的窗口期.
（oplogSizeMB的大小要大于数据同步完成+索引建立完成的时间段内生成的数据量,
当同步完成后，从节点从主节点读oplog表的数据，发现最小的同步时间，已大于从节点中
同步开始时的时间了，这就是窗口期已过期）
数据量大后，重新创建索引的时间特别惊人，一个索引需要10多个小时。
500G 存储量，总共需要3天左右的数据完成节点的数据同步及索引创建。
后面计划在添加节点前，做以下调整：
1.把数据库升级到3.4 版本，此版本在新节点数据同步，创建索引上，号称已有很大的改善。
2.删除能够优化的索引，如果索引无法优化，也可以考虑先把某个索引删除，节点完成后，再重新建立经验总结：
1.索引的优化，尽可能的发挥主键索引的功能，比如上面说到的，使用日期范围自己生成_id 范围，用_id字段进行查询，
能不建立索引，就不建立。在大增长的表中，极其重要。
2.数据库服务器的内存配置上，内存>索引大小，或者是配置到 内存>=索引大小+热数据大小 还是有必要的。
3.数据库服务器的磁盘配置上，如果是云服务器，尽量采用高效云盘。使用EXT4,或者使用NFS 格式也是有必要的。
4.如果一个库有多个表的数据达到亿级时，可能也是考虑使用分片集群的时候，特别是如果此表是做为主业务
数据库的情况。
---------- 表数据增长情况 ------------------
......
1/1/2017,4318897
1/2/2017,3619411
1/3/2017,2583555
1/5/2017,5523416
1/6/2017,3052537
1/7/2017,3482728
1/8/2017,3931742
1/9/2017,4732320
1/10/2017,4651948
1/11/2017,4438733
1/12/2017,4286169
1/13/2017,4405242
1/14/2017,5664654
1/15/2017,5623800
1/16/2017,3638656
1/17/2017,3617628
1/18/2017,3601569
1/19/2017,3738790
1/20/2017,3788641
1/21/2017,4603575
1/22/2017,4466660
1/23/2017,3913910
1/24/2017,3749316
1/25/2017,3969802
1/26/2017,4101293
1/27/2017,2581358
1/28/2017,3160561
1/29/2017,3051008
1/30/2017,3332417
1/31/2017,3476649
2/1/2017, 3152283
2/2/2017, 3394489
2/3/2017, 3524487
2/4/2017, 3511386
2/5/2017, 3870305
2/6/2017, 3056966
2/7/2017, 3022927
2/8/2017, 3484463
2/9/2017, 4033520
--------------------------
2016/12: 191914076
2017/01: 119106985
2017/02: 31050826
————————————————
原文链接：https://blog.csdn.net/miyatang/article/details/55509419MongoDB数据量大于2亿后遇到的问题 及原因分析
能不建立索引，就不建立。在大增长的表中，极其重要。
2.数据库服务器的内存配置上，内存>索引大小，或者是配置到 内存>=索引大小+热数据大小 还是有必要的。
3.数据库服务器的磁盘配置上，如果是云服务器，尽量采用高效云盘。使用EXT4,或者使用NFS 格式也是有必要的。
4.如果一个库有多个表的数据达到亿级时，可能也是考虑使用分片集群的时候，特别是如果此表是做为主业务
数据库的情况。
---------- 表数据增长情况 ------------------
......
1/1/2017,4318897
1/2/2017,3619411
1/3/2017,2583555
1/5/2017,5523416
1/6/2017,3052537
1/7/2017,3482728
1/8/2017,3931742
1/9/2017,4732320
1/10/2017,4651948
1/11/2017,4438733
1/12/2017,4286169
1/13/2017,4405242
1/14/2017,5664654
1/15/2017,5623800
1/16/2017,3638656
1/17/2017,3617628
1/18/2017,3601569
1/19/2017,3738790
1/20/2017,3788641
1/21/2017,4603575
1/22/2017,4466660
1/23/2017,3913910
1/24/2017,3749316
1/25/2017,3969802
1/26/2017,4101293
1/27/2017,2581358
1/28/2017,3160561
1/29/2017,3051008
1/30/2017,3332417
1/31/2017,3476649
2/1/2017, 3152283
2/2/2017, 3394489
2/3/2017, 3524487
2/4/2017, 3511386
2/5/2017, 3870305
2/6/2017, 3056966
2/7/2017, 3022927
2/8/2017, 3484463
2/9/2017, 4033520
--------------------------
2016/12: 191914076
2017/01: 119106985
2017/02: 31050826
————————————————
原文链接：https://blog.csdn.net/miyatang/article/details/55509419MongoDB数据量大于2亿后遇到的问题 及原因分析