MongoDB數(shù)據(jù)量大于2億后遇到的問題 及原因分析

一、數(shù)據(jù)增長情況

?? ?每月增長量最大達(dá)到了1.9億，每天增長約300W-500W
?? ?（增長數(shù)據(jù)具體可看頁尾）

二、遇到的情況及解決方法

?? ?1.數(shù)據(jù)量過大，并且都集中在一個(gè)表，所以此表數(shù)據(jù)插入變慢。

?? ??? ?表索引越多越明顯，

?? ??? ?優(yōu)化處理方法：
?? ??? ??? ?1.優(yōu)化索引，以前的startTime日期字段索引，
?? ??? ??? ?修改為客戶端用日期生成ObjectId,再用_id 來進(jìn)行查找。
?? ??? ??? ?2.TraceId 字段（一個(gè)TraceId 對應(yīng)多條記錄）計(jì)劃也刪除，后面再用ES 系統(tǒng)先查詢到_id 后，
?? ??? ??? ?再從mongoDB 進(jìn)行查找。

?? ??? ?原因分析：
?? ??? ??? ?當(dāng)表數(shù)據(jù)增長到千萬級后，內(nèi)存數(shù)據(jù)中的索引數(shù)據(jù)增加，內(nèi)存越來越不夠用，需要刷新臟數(shù)據(jù)增多，?? ??? ??? ?
?? ??? ??? ?mongostat 分析的 dirty % > 3,后從16G 內(nèi)存升級到32G 內(nèi)存后，情況稍有好轉(zhuǎn)。

?? ?2.數(shù)據(jù)量過大后，從節(jié)點(diǎn)時(shí)爾出現(xiàn)CPU load 負(fù)載過高，從節(jié)點(diǎn)尤其明顯。

?? ??? ?
?? ??? ?在把表重命名，新數(shù)據(jù)插入到新表處理后：
?? ??? ?db.TraceLogs.renameCollection("TraceLogs_bak170210");
?? ??? ?（新數(shù)據(jù)插入時(shí)，會(huì)自動(dòng)生成表TraceLogs）


?? ??? ?歷史數(shù)據(jù)表統(tǒng)計(jì)信息?? ?
?? ??? ??? ?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
?? ??? ??? ?}
?? ??? ??? ?從此統(tǒng)計(jì)信息中可以看到：
?? ??? ??? ??? ??? ?表存儲(chǔ)大小：?? ?444G,
?? ??? ??? ??? ??? ?索引 _id_ 3.9G, TraceId_1 大小：11G


?? ??? ?再次查看數(shù)據(jù)庫性能

?? ??? ?從以前的：
?? ??? ?load average: > 5.47, 5.47, 5.47
?? ??? ?降到了：
?? ??? ?load average: 0.88, 1.34, 1.69
?? ??? ?(主從節(jié)點(diǎn)，皆已下降)

?? ??? ?在做歷史數(shù)據(jù)遷移期間，又升到了> 8 并且時(shí)頻繁出現(xiàn)。

?? ??? ?完成數(shù)據(jù)遷移后，回落到? 2 < load avg <: 4 之間?? ??? ?（升級到MongoDB3.4 之后）
?? ??? ??? ?

?? ??? ?原因分析：
?? ??? ??? ?個(gè)人認(rèn)為，主因還是因?yàn)閮?nèi)存不夠。索引+熱數(shù)據(jù)遠(yuǎn)遠(yuǎn)超過了16G的MongoDB使用內(nèi)存。
?? ??? ??? ?從而導(dǎo)致大量的IO，相對的CPU load 也上去了。
?? ??? ??? ?在把原大表TraceLogs 改名后（TraceLogs_bak170210），大量的熱塊數(shù)據(jù)已被清除出內(nèi)存，

?? ?3.此前數(shù)據(jù)庫從節(jié)點(diǎn)內(nèi)存升級后（16G --> 32G)，參數(shù)配置不當(dāng)，節(jié)點(diǎn)實(shí)例當(dāng)機(jī)情況：

?? ??? ?wiredTiger:
?? ??? ??? ?engineConfig:
?? ?????? cacheSizeGB: 28?? ?(限制mongoDB 使用內(nèi)存最大值)

?? ??? ?后調(diào)整為默認(rèn)值
?? ??? ??? ??? ?#cacheSizeGB: 28?? ?(限制mongoDB 使用內(nèi)存最大值)，默認(rèn)值為50%
?? ??? ?mongoDB實(shí)例恢復(fù)正常，但CPU load 也一直居高不下。

?? ??? ?原因分析：
?? ??? ??? ?系統(tǒng)使用內(nèi)存太少，可能是磁盤緩存過低，而無法讀寫數(shù)據(jù)，但在mongoDB 日志中，
?? ??? ??? ?無法找到原因。只是看到實(shí)例被關(guān)閉。

?? ?4.因?yàn)閛plog 同步表最大設(shè)置值(oplogSizeMB)為50G, 但50G 只能保存52h 的數(shù)量變化量。

?? ?想添加新的從節(jié)點(diǎn)時(shí)，當(dāng)同步完成數(shù)據(jù)后，已過了oplog 的窗口期.
?? ??? ?
?? ?（oplogSizeMB的大小要大于數(shù)據(jù)同步完成+索引建立完成的時(shí)間段內(nèi)生成的數(shù)據(jù)量,
?? ?當(dāng)同步完成后，從節(jié)點(diǎn)從主節(jié)點(diǎn)讀oplog表的數(shù)據(jù)，發(fā)現(xiàn)最小的同步時(shí)間，已大于從節(jié)點(diǎn)中
?? ?同步開始時(shí)的時(shí)間了，這就是窗口期已過期）


?? ??? ?數(shù)據(jù)量大后，重新創(chuàng)建索引的時(shí)間特別驚人，一個(gè)索引需要10多個(gè)小時(shí)。
?? ??? ?500G 存儲(chǔ)量，總共需要3天左右的數(shù)據(jù)完成節(jié)點(diǎn)的數(shù)據(jù)同步及索引創(chuàng)建。

?? ??? ?后面計(jì)劃在添加節(jié)點(diǎn)前，做以下調(diào)整：
?? ??? ?1.把數(shù)據(jù)庫升級到3.4 版本，此版本在新節(jié)點(diǎn)數(shù)據(jù)同步，創(chuàng)建索引上，號(hào)稱已有很大的改善。
?? ??? ?2.刪除能夠優(yōu)化的索引，如果索引無法優(yōu)化，也可以考慮先把某個(gè)索引刪除，節(jié)點(diǎn)完成后，再重新建立

經(jīng)驗(yàn)總結(jié)：

?? ?1.索引的優(yōu)化，盡可能的發(fā)揮主鍵索引的功能，比如上面說到的，使用日期范圍自己生成_id 范圍，用_id字段進(jìn)行查詢，
?? ?能不建立索引，就不建立。在大增長的表中，極其重要。

?? ?2.數(shù)據(jù)庫服務(wù)器的內(nèi)存配置上，內(nèi)存>索引大小，或者是配置到 內(nèi)存>=索引大小+熱數(shù)據(jù)大小 還是有必要的。
?? ?
?? ?3.數(shù)據(jù)庫服務(wù)器的磁盤配置上，如果是云服務(wù)器，盡量采用高效云盤。使用EXT4,或者使用NFS 格式也是有必要的。

?? ?4.如果一個(gè)庫有多個(gè)表的數(shù)據(jù)達(dá)到億級時(shí)，可能也是考慮使用分片集群的時(shí)候，特別是如果此表是做為主業(yè)務(wù)
?? ?數(shù)據(jù)庫的情況。








---------- 表數(shù)據(jù)增長情況 ------------------
......
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

總結(jié)

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

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。