MongoDB汇聚排序取第一条纪录的实例与完成方式

2021-02-06 15:24

MongoDB汇聚排序取第一条纪录的实例与完成方式 |频道：MongoDB|点一下： 次

序言

ess_log中，依据字段名refererDomain排序，ess_log_new中。

收到这一要求，還是一些胆虚的，缘故有二，一是，业务流程必须，時间紧；二是，完成这一作用MongoDB汇聚觉得一些繁杂，汇聚要走许多步。

数据信息纪录文件格式以下：

 "_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
 "_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
 "_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
 "_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。

由于状况独特，业务流程发版必须这种数据信息。催的较为急，而 根据 汇聚 架构aggregate，短时间间有木有构思， 因此，那时候就惦记着试着选用别的计划方案。

最终，难题解决计划方案以下。

Step 1 根据汇聚架构 ess_log 中（共造成95笔数据信息）；

完成编码以下：

ess_collect.aggregate(
 { $group: { _id: "$refererDomain" } },
 { $out : "ess_log" }
 )

Step 2 根据两次 forEach实际操作，ess_log的数据信息。

编码表述，ess_log的数据信息（共95笔），每笔逐行生产加工解决，解决的逻辑性关键是 ess_log汇聚前的refererDomain字段名）， ess_log的字段名 refererDomain核对，查寻出合乎此标准的数据信息，而且是按_id 倒序，ess_log_new。

新结合也是95笔数据信息。

大伙儿无需担忧特性，查寻句子在1S内完成了断果查寻。

ess_log.find({}).forEach(
 function(x) {
 ess_log.find({ "refererDomain": x._id }).sort({ _id: -1 }).limit(1).forEach(
 function(y) {
 ess_log_new.insert(y)
)

Step ess_log_new，結果合乎业务流程规定。

留意：依据時间排列的规定，由于一部分文本文档沒有createTime字段名种类，且 createTime字段名上沒有建立数据库索引，因此未了合乎准时间排列大家选用了sort({_id:1})的随机应变方式，由于_id 也有時间的实际意义。下边的內容为MongoDB相匹配_id 的有关专业知识。

最大要的是前4个字节数包括着规范的Unix時间戳。后边3个字节数是设备ID，随后是两个字节数的过程ID。最终3个字节数储存的是过程当地电子计数器。电子计数器能够确保同一个过程和同一時刻内不容易反复。

小结

之上便是本文的所有內容了，期待文中的內容对大伙儿的学习培训或是工作中具备一定的参照学习培训使用价值，假如有疑惑大伙儿能够留言板留言沟通交流，感谢大伙儿对本网的适用。