长话短说: 长时间运行的查询会为其他用户杀死整个应用程序。规避这种情况的策略是什么？
您好，我正在 AWS T2.small 实例(2GB，1 核)上运行 MongoDB，用于流量较小的 Meteor 应用程序。它工作正常，除非人们想要运行一个包含大约 30 个聚合以显示各种 KPI 的报告。当一个用户运行报告(大约需要一分钟才能完成)时，应用程序性能很糟糕(几乎为零)，最糟糕的情况是其他人同时为他们自己的数据启动报告。然后他们甚至可能需要 10 分钟才能完成。 Web 服务器的负载几乎没有，也不会导致问题，但 MongoDB 服务器的 CPU 在此类事件期间以 100% 的速度运行(使用 Meteor 的 unblock() 执行所有单独的聚合调用不会提高性能)。
我知道我可以优化个别查询，或者我可以为更快的服务器支付更多费用，但这不是重点。如何防止应用程序锁定(用户甚至无法登录，因为数据库很忙，因为它没有时间回复用户登录请求)？我想要一些指导。
副本集会有帮助吗(例如隐藏的副本集成员)？我将如何针对这个实例进行报告(来自 MeteorJS)？有没有办法为此类查询分配低优先级并仅在服务器的空闲时间执行它们？
最佳答案
看起来聚合查询太多，服务器无法处理。如果它适用于您的用例，您或许能够创建预聚合报告。
预聚合报告的概念是，当您向集合中插入新数据时，您还更新了另一个集合中的“聚合文档”。例如，如果您的聚合需要某个字段的总值，“聚合文档”中的 sum 字段会将新文档的值添加到现有值。
使用预先聚合的报告将消除运行聚合查询的需要。相反，单个 db.aggregates.find() 查询就足够了。
这种方法的一个缺点是，您需要插入 + 更新，而不是单个插入操作。
请注意，如果预聚合方法不合适，那么将您的部署配置增加到更大的机器将是唯一现实的选择。
请参阅https://docs.mongodb.com/ecosystem/use-cases/pre-aggregated-reports-mmapv1/一些例子。请注意，虽然技术细节适用于 MMAPv1 存储引擎，但基本概念同样适用于 WiredTiger 存储引擎。
关于mongodb - 一般 MongoDB 性能故障排除，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/48132958/