MongoDB數據量大于2億后遇到的問題 及原因分析

一、數據增長情況

?? ?每月增長量最大達到了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.索引的優化，盡可能的發揮主鍵索引的功能，比如上面說到的，使用日期范圍自己生成_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

總結

以上是生活随笔為你收集整理的MongoDB数据量大于2亿后遇到的问题 及原因分析的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。