持续运行 MongoDB 聚合管道答案

【问题标题】：Continuously run MongoDB aggregation pipeline持续运行 MongoDB 聚合管道
【发布时间】：2019-07-05 20:00:59
【问题描述】：

我有一个 ETL 管道将时间序列记录下沉到 MongoDB。

我需要计算每日、每周等的及时聚合。我认为 MongoDB 的聚合引擎将是可行的方法，因此在对每个分辨率进行聚合查询后，我将它们与 MongoDB 视图（如“daily_view”、“weekly_view”等）包装起来。

有 REST 服务可以从 MongoDB 中获取。根据请求的周期分辨率，它从上述不同的视图中提取，开始和结束日期的采样。

这些视图/聚合的响应时间相当“差”。它可以是大约 10-15 秒。我认为这个失误对于批量计算报告可能并不令人发指，但在我的情况下，服务需要以实时模式发出这些请求以服务于前端，因此 10 秒的等待时间太长了。

从 MongoDB 参考资料中，我知道 Views are computed on demand during read operations，但我对这样的响应时间有点失望，因为在 Elasticsearch 或 InfluxDB 中，相同的聚合需要几秒钟的时间，不幸的是，目前这不是我的选择。
我还用尽了关于优化查询的研究，没有比现在更好的改进空间了。

我的直觉告诉我，如果聚合必须通过聚合引擎完成，我需要管道在运行中连续执行（因此视图已经为服务提供了记录），而不是每次都运行广告-特设的。

我试图删除视图，而是将最后一个阶段作为 $out 到一个真实集合的聚合......但我仍然有同样的问题，它需要“按需”运行。我使用 Compass UI 组合管道，并在 $out 阶段显示一个按钮来运行聚合。

是否有办法安排此类管道/聚合查询？

我能想到的是，复制粘贴聚合代码并将其放入 REST 服务的 Javascript 函数中……但是，仍然需要定期调用这些函数。我知道我可以将一些库引入服务进行调度，但是这个选项让我在架构方面感到有点不舒服。

在最坏的情况下，我的备份计划是将及时聚合作为初始 ETL 逻辑的一部分实现，并将所有不同的解决方案汇集到不同的集合中，因此服务会在聚合中找到已经等待获取的记录收藏品。但其目的是利用数据存储引擎的时间聚合。

我现在在最后一刻遇到了一些架构问题

【问题讨论】：

标签： mongodb architecture aggregation-framework

【解决方案1】：

$out 聚合阶段。 Documentation.

获取聚合管道返回的文档并将它们写入指定的集合。 $out 运算符必须是管道中的最后一个阶段。

$mongo 接受 javascript 文件作为参数。所以这是打包聚合的最简单方法。 Reference.

mongo file.js --username username --password

然后 - 按计划执行它 - 诸如 cron 作业之类的常用工具来救援。

您可能需要考虑 Mongo Shell 和 Javascrips 之间的差异，例如使用 db = db.getSiblingDB('<db>') 而不是 use <db>。 Write Scripts for the mongo Shell

【讨论】：