我正在开发一个应用程序，该应用程序向用户显示他们选择的位置内的某些可用服务，包括该服务的价格。我已经Services存储在一个集合中，而这些服务的定价中的每一个都存储在自己的另一个集合中（Prices）。某些服务具有相同的定价，因此通常存在一对多的关系。
问题在于，在我用来确定最佳可用服务的“算法”中，我通过轮询 Mongo 并获得正确的值来确定很多值，其中包括服务的价格。
我最初在模型中嵌入了每项服务的定价结构Service，但这是一个问题，因为我必须Services定期扫描集合以更新此定价以了解变化/波动性。我最终嵌入了一个从Service到Price.
我的问题
如何在减少对 Mongo 的调用次数的同时最好地实现我目前正在做的事情？
我目前在每个用户搜索中以大约 50-400 次读取（特别是针对定价）访问 Mongo，当与其他查询结合使用时，这会减慢速度，而且效率非常低。我正在考虑多种选择：
- 创建一个存储桶（可能是
globalNode 命名空间中的一个对象），我在其中缓存所有定价信息_id。每次我需要查找 a 的定价时Service，我都会遍历该存储桶，如果定价已经缓存在存储桶中，我会进行计算并返回价格，否则我会从 Mongo 获取文档并将其添加到存储桶中当前和未来的使用。
我担心这可能会带来诸如内存泄漏之类的问题。理想情况下，存储桶应该可供所有用户使用，而不是像只属于一个用户的 cookie（我对 cookie 的理解在这里可能是错误的）。我还不知道是否可以在全局范围内公开一个对象，让所有用户都可以访问它。
- 我见过一些 Mongo 的“内存实现”（目前找不到），它们模拟 MongoDB，但使用 LocalStorage 作为数据存储。我正在考虑分叉其中一个并针对服务器端功能进行调整。
我不知道这是否可行，而且我似乎需要一些时间来做。
- 将数据存储为 JSON 文件（或多个文件，我可以找到一种拆分文件的方法）。然后我可以使用 Node 来读取 JSON 文件
require()。这是目前我的首选选项，因为我可以使用fsAPI 来处理 JSON 文件的定期更新。
我担心 JSON 文件的大小，主要是如果它们足够大，它们可能会减慢 Node 的速度，但我正在考虑这一点，因为我将在数据库上节省 50 - 400 次点击。我还假设我不会加载单个 JSON 文件的n时间（n即某个时间点服务上的用户数）
考虑到以上3个选项，哪个有很好的工作机会？有些选项可能是不可能的，所以我可以将它们从我的列表中划掉，可能还有一些我还没有考虑过的选项。
最后，我的免责声明： 我知道这可以在 SQL 中使用 JOIN 语句轻松实现，不，我没有使用锤子来处理需要螺丝刀的东西。尽管对于我项目的某些部分，SQL 看起来是一个明显的胜利，但对于我存储的大部分数据，Mongo 更好。再加上以经验的名义重新发明轮子会有所帮助。
谢谢