關于MongoDBaggregate的性能優(yōu)化經歷分享

今天小編給大家分享的是關于MongoDB aggregate的性能優(yōu)化經歷，一起來看看吧。

成都創(chuàng)新互聯(lián)主要從事網站制作、成都網站建設、網頁設計、企業(yè)做網站、公司建網站等業(yè)務。立足成都服務深圳,十年網站建設經驗,價格優(yōu)惠、服務專業(yè),歡迎來電咨詢建站服務:18982081108

在一臺配置為2核4G的阿里云服務器上，硬盤是普通的云盤（即SATA盤），除mongoDB外，運行了若干個java應用，單節(jié)點MySQL和redis，mongo的實際可用內存在1.5G左右。單表數(shù)據(jù)200萬條的時候，一個聚合函數(shù)響應時間約為6秒，頁面端每秒請求一次，由于響應不夠及時，頁面刷新不及時，服務端堆積了大量的mongo aggregate請求，系統(tǒng)可用內存不足，直接導致了溢出，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]

---

下面是聚合的腳本，很簡單，就是統(tǒng)計某輛車多個狀態(tài)碼的最新值(通過$first實現(xiàn))。

db.getCollection("vinMsgOut").aggregate([
  {"$match": {"vinCode": "LSGKR53L3HA149563"}},
  {"$sort": {"postTime" : -1}},
  {"$group":  {
      "_id": "$messageType",
      "resultValue": {"$first": "$resultValue"}
      }
  }
],{ allowDiskUse: true })

第一反應是增加過濾條件及增加索引。
結合業(yè)務，增加時間條件過濾，將$match改為：

{"$match": {"vinCode": "LSGKR53L3HA149563", "createTime": {$gt: ISODate("2020-03-01T06:30:12.038Z")}}}

再分別為vinCode和createTime創(chuàng)建索引，執(zhí)行，依舊是6秒多。。。
將$sort的字段改成索引字段createTime，
{"$sort": {"createTime" : -1}}
再次執(zhí)行，時間依舊是6秒多。。。

由于系統(tǒng)可分配內存有限，存儲引擎已經默認是最快的wiredTiger，磁盤也沒法更給力，只能從業(yè)務上再著手?？紤]到這些最新狀態(tài)的出現(xiàn)，一般都是同一個時間段，狀態(tài)碼只有幾百個，如果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索引刪掉，返現(xiàn)時間變成5秒，所以createTime的索引是有用的，用在$sort而已。綜上，完成了整個查詢的優(yōu)化，總結下來就是：

1. $match條件需要增加索引，如果是多個，最好用組合索引；
2. $sort的字段也需要增加索引；
3. $group的_id也需要增加索引；
4. limit可以大幅度降低時耗。
5. 關于MongoDB aggregate的性能優(yōu)化經歷分享到這里了，當然并不止以上和大家分析的辦法，不過小編可以保證其準確性是絕對沒問題的。希望以上內容可以對大家有一定的參考價值，可以學以致用。如果喜歡本篇文章，不妨把它分享出去讓更多的人看到。

網頁標題：關于MongoDBaggregate的性能優(yōu)化經歷分享
本文URL：http://muchs.cn/article42/ieghec.html

成都網站建設公司_創(chuàng)新互聯(lián)，為您提供網頁設計公司、App開發(fā)、響應式網站、標簽優(yōu)化、關鍵詞優(yōu)化、電子商務

廣告

聲明：本網站發(fā)布的內容（圖片、視頻和文字）以用戶投稿、用戶轉載內容為主，如果涉及侵權請盡快告知，我們將會在第一時間刪除。文章觀點不代表本網站立場，如需處理請聯(lián)系客服。電話：028-86922220；郵箱：631063699@qq.com。內容未經允許不得轉載，或轉載時需注明來源： 創(chuàng)新互聯(lián)