您好,登錄后才能下訂單哦!
今天小編給大家分享的是關于MongoDB aggregate的性能優化經歷,一起來看看吧。
在一臺配置為2核4G的阿里云服務器上,硬盤是普通的云盤(即SATA盤),除mongoDB外,運行了若干個java應用,單節點mysql和redis,mongo的實際可用內存在1.5G左右。單表數據200萬條的時候,一個聚合函數響應時間約為6秒,頁面端每秒請求一次,由于響應不夠及時,頁面刷新不及時,服務端堆積了大量的mongo aggregate請求,系統可用內存不足,直接導致了溢出,mongo服務被動shutdown。
mongod(ZN5mongo15printStackTraceERSo+0x41) [0x55bd3a2dd321]
mongod(ZN5mongo29reportOutOfMemoryErrorAndExitEv+0x84) [0x55bd3a2dc954]
mongod(ZN5mongo12mongoReallocEPvm+0x21) [0x55bd3a2d22b1]
mongod(ZN5mongo11BufBuilderINS21SharedBufferAllocatorEE15growreallocateEi+0x83) [0x55bd38981833]
mongod(ZN5mongo3rpc17OpMsgReplyBuilder22getInPlaceReplyBuilderEm+0x80) [0x55bd39d4b740]
mongod(+0xAB9609) [0x55bd389be609]
mongod(+0xABBA59) [0x55bd389c0a59]
下面是聚合的腳本,很簡單,就是統計某輛車多個狀態碼的最新值(通過$first實現)。
db.getCollection("vinMsgOut").aggregate([
{"$match": {"vinCode": "LSGKR53L3HA149563"}},
{"$sort": {"postTime" : -1}},
{"$group": {
"_id": "$messageType",
"resultValue": {"$first": "$resultValue"}
}
}
],{ allowDiskUse: true })
第一反應是增加過濾條件及增加索引。
結合業務,增加時間條件過濾,將$match改為:
{"$match": {"vinCode": "LSGKR53L3HA149563", "createTime": {$gt: ISODate("2020-03-01T06:30:12.038Z")}}}
再分別為vinCode和createTime創建索引,執行,依舊是6秒多。。。
將$sort的字段改成索引字段createTime,{"$sort": {"createTime" : -1}}
再次執行,時間依舊是6秒多。。。
由于系統可分配內存有限,存儲引擎已經默認是最快的wiredTiger,磁盤也沒法更給力,只能從業務上再著手。考慮到這些最新狀態的出現,一般都是同一個時間段,狀態碼只有幾百個,如果sort之后,只從pipe取其中一部分進行group,會不會更快些?帶著這個疑問,我加了一條limit。
db.getCollection("vinMsgOut").aggregate([
{"$match": {"vinCode": "LSGKR53L3HA149563", "createTime": {$gt: ISODate("2020-03-01T06:30:12.038Z")}}},
{"$sort": {"createTime" : -1}},
{"$limit": 1000},
{"$group": {
"_id": "$messageType",
"resultValue": {"$first": "$resultValue"}
}
}
],{ allowDiskUse: true })
結果是秒回!
去掉$match中的createTime條件,依舊秒回!這是否意味著createTime索引并沒有起作用?帶著疑問,將createTime索引刪掉,返現時間變成5秒,所以createTime的索引是有用的,用在$sort而已。綜上,完成了整個查詢的優化,總結下來就是:
免責聲明:本站發布的內容(圖片、視頻和文字)以原創、轉載和分享為主,文章觀點不代表本網站立場,如果涉及侵權請聯系站長郵箱:is@yisu.com進行舉報,并提供相關證據,一經查實,將立刻刪除涉嫌侵權內容。