我有一个ETL管道，它将时间序列记录下沉到MongoDB。
我需要为每日，每周等计算及时的汇总。我以为MongoDB的聚合引擎是必经之路，因此在对每个分辨率进行聚合查询后，我将它们包装在MongoDB视图中，例如“ daily_view”，“ weekly_view”等。
有可从MongoDB获取的REST服务。根据请求的周期分辨率，它会从上述不同的视图中提取，并采样开始和结束日期。
这些视图/汇总的响应时间非常“差”。可能需要10到15秒。我认为这种失误对于批处理报表而言可能并不令人发指，但就我而言，该服务需要以实时模式发出这些请求以服务于前端，因此10秒的等待时间太多了。
从MongoDB参考文献中我知道Views are computed on demand during read operations，但是对于这样的响应时间我感到有些失望，因为在Elasticsearch或InfluxDB中相同的聚合花费了几秒钟的时间，不幸的是，这对我而言目前不是一种选择。
我还用尽了关于优化查询的研究，并且没有比现在有了更多改进的余地了。
我的直觉告诉我，如果必须通过聚合引擎完成聚合，则我需要在运行中连续执行管道（这样，视图中已经有该服务的记录），而不是每次都在运行时，临时
我试图删除视图，而是进行和聚合，最后一步是向实际集合中输出$ ...但是我仍然遇到相同的问题，它需要“按需”运行。我使用Compass UI编写了管道，并在$ out阶段提供了一个按钮来运行聚合。
是否可以安排此类管道/聚合查询？
我可以考虑的事情是，将粘贴的代码复制粘贴到REST服务的Javascript函数中……但是，仍然有些东西必须定期调用这些函数。我知道我可以将一些库带入服务中进行调度，但是此选项使我在体系结构方面感到不舒服。
在最坏的情况下，我的备份计划是将及时聚合作为初始ETL的逻辑之一，并将所有不同的分辨率下沉到不同的集合中，因此该服务将找到要在聚合中等待的记录集合。但其目的是利用时间聚合功能来访问数据存储引擎。
我现在有最后一刻的建筑困扰
答案 0 :(得分：0)
$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