前言

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

接到這個需求，還是有些心虛的，原因有二，一是，業(yè)務(wù)需要，時間緊；二是，實現(xiàn)這個功能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è)務(wù)發(fā)版需要這些數(shù)據(jù)。催的比較急，而 通過 聚合 框架aggregate，短時間有沒有思路， 所以，當時就想著嘗試采用其他方案。

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

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

實現(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ù)。

大家不用擔心性能，查詢語句在1S內(nèi)實現(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 查詢驗證新產(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ù)時間排序的要求，因為部分文檔沒有createTime字段類型，且 createTime字段上沒有創(chuàng)建索引，所以未了符合按時間排序我們采用了sort({_id:1})的變通方法，因為_id 還有時間的意義。下面的內(nèi)容為MongoDB對應(yīng)_id 的相關(guān)知識。

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

總結(jié)

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