前言

今天開發(fā)同學(xué)向我們提了一個(gè)緊急的需求，從集合mt_resources_access_log中，根據(jù)字段refererDomain分組，取分組中最近一筆的數(shù)據(jù)，然后將這些符合條件的數(shù)據(jù)導(dǎo)入到集合mt_resources_access_log_new中。

接到這個(gè)需求，還是有些心虛的，原因有二，一是，業(yè)務(wù)需要，時(shí)間緊；二是，實(shí)現(xiàn)這個(gè)功能MongoDB聚合感覺有些復(fù)雜，聚合要走好多步。

數(shù)據(jù)記錄格式如下：

記錄1

{
 "_id" : ObjectId("5c1e23eaa66bf62c0c390afb"),
 "_class" : "C1",
 "resourceUrl" : "/static/js/p.js",
 "refererDomain" : "1234",
 "resourceType" : "static_resource",
 "ip" : "17.17.13.13",
 "createTime" : ISODate("2018-12-22T19:45:46.015+08:00"),
 "disabled" : 0
}

記錄2

{
 "_id" : ObjectId("5c1e23eaa66bf62c0c390afb"),
 "_class" : "C1",
 "resourceUrl" : "/static/js/p.js",
 "refererDomain" : "1234",
 "resourceType" : "Dome_resource",
 "ip" : "17.17.13.14",
 "createTime" : ISODate("2018-12-21T19:45:46.015+08:00"),
 "disabled" : 0
}

記錄3

{
 "_id" : ObjectId("5c1e23eaa66bf62c0c390afb"),
 "_class" : "C2",
 "resourceUrl" : "/static/js/p.js",
 "refererDomain" : "1235",
 "resourceType" : "static_resource",
 "ip" : "17.17.13.13",
 "createTime" : ISODate("2018-12-20T19:45:46.015+08:00"),
 "disabled" : 0
}
記錄4

{
 "_id" : ObjectId("5c1e23eaa66bf62c0c390afb"),
 "_class" : "C2",
 "resourceUrl" : "/static/js/p.js",
 "refererDomain" : "1235",
 "resourceType" : "Dome_resource",
 "ip" : "17.17.13.13",
 "createTime" : ISODate("2018-12-20T19:45:46.015+08:00"),
 "disabled" : 0
}

以上是我們的4條記錄，類似的記錄文檔有1500W。

因?yàn)榍闆r特殊，業(yè)務(wù)發(fā)版需要這些數(shù)據(jù)。催的比較急，而 通過 聚合 框架aggregate，短時(shí)間有沒有思路， 所以，當(dāng)時(shí)就想著嘗試采用其他方案。

最后，問題處理方案如下。

Step 1 通過聚合框架 根據(jù)條件要求先分組，并將新生成的數(shù)據(jù)輸出到集合mt_resources_access_log20190122 中；

實(shí)現(xiàn)代碼如下：

db.log_resources_access_collect.aggregate(
      [
      
      { $group: { _id: "$refererDomain" } },
      { $out : "mt_resources_access_log20190122" }
      ]
 
     )

Step 2 通過2次 forEach操作，循環(huán)處理 mt_resources_access_log20190122和mt_resources_access_log的數(shù)據(jù)。

代碼解釋，處理的邏輯為，循環(huán)逐筆取出mt_resources_access_log20190122的數(shù)據(jù)（共95筆），每筆逐行加工處理，處理的邏輯主要是 根據(jù)自己的_id字段數(shù)據(jù)（此字段來自mt_resources_access_log聚合前的refererDomain字段）， 去和 mt_resources_access_log的字段 refererDomain比對，查詢出符合此條件的數(shù)據(jù)，并且是按_id 倒序，僅取一筆，最后將Join刷選后的數(shù)據(jù)Insert到集合mt_resources_access_log_new。

新集合也是95筆數(shù)據(jù)。

大家不用擔(dān)心性能，查詢語句在1S內(nèi)實(shí)現(xiàn)了結(jié)果查詢。

db.mt_resources_access_log20190122.find({}).forEach(
 function(x) {
  db.mt_resources_access_log.find({ "refererDomain": x._id }).sort({ _id: -1 }).limit(1).forEach(
   function(y) {
    db.mt_resources_access_log_new.insert(y)
   }
  )
 }
)

Step 3 查詢驗(yàn)證新產(chǎn)生的集合mt_resources_access_log_new，結(jié)果符合業(yè)務(wù)要求。

刷選前集合mt_resources_access_log的數(shù)據(jù)量為1500多W。

刷選后產(chǎn)生新的集合mt_resources_access_log_new 數(shù)據(jù)量為95筆。

注意：根據(jù)時(shí)間排序的要求，因?yàn)椴糠治臋n沒有createTime字段類型，且 createTime字段上沒有創(chuàng)建索引，所以未了符合按時(shí)間排序我們采用了sort({_id:1})的變通方法，因?yàn)開id 還有時(shí)間的意義。下面的內(nèi)容為MongoDB對應(yīng)_id 的相關(guān)知識(shí)。

最重要的是前4個(gè)字節(jié)包含標(biāo)準(zhǔn)的Unix時(shí)間戳。后面3個(gè)字節(jié)是機(jī)器ID，緊接著是2個(gè)字節(jié)的進(jìn)程ID。最后3個(gè)字節(jié)存儲(chǔ)的是進(jìn)程本地計(jì)數(shù)器。計(jì)數(shù)器可以保證同一個(gè)進(jìn)程和同一時(shí)刻內(nèi)不會(huì)重復(fù)。

總結(jié)

以上就是這篇文章的全部內(nèi)容了，希望本文的內(nèi)容對大家的學(xué)習(xí)或者工作具有一定的參考學(xué)習(xí)價(jià)值，如果有疑問大家可以留言交流，謝謝大家對腳本之家的支持。