我正在开发一个应用程序，向用户显示其所选位置内的某些可用服务，包括该服务的价格。我将Services存储在一个集合中，并将每个服务的定价存储在他们自己的另一个集合中（Prices）。有些服务的价格相同，所以通常会有一对多的关系。
问题在于，在我用来确定最佳可用服务的'算法'中，我通过轮询Mongo并获得正确的值来确定很多值，其中包括服务的价格。 / p>
我最初在Service模型中嵌入了每项服务的定价结构，但这是一个问题，因为我必须定期浏览Services集合，以更新此变化/波动率的定价。我最终嵌入了从Service到Price的数据库引用。
我的问题
如何在减少对Mongo的调用次数的同时，最好地实现我目前正在做的事情？
我目前正在以每次用户搜索大约50-400次读取（特别是定价）来攻击Mongo，这与其他查询结合起来会减慢一些速度，并且效率非常低。 我正在考虑许多选择：
global命名空间中的一个对象），我按_id缓存所有定价信息。每次我需要查找Service的定价时，我都会查看该桶，如果定价已经缓存在桶中，我会进行计算并返回价格，否则我会从Mongo中获取文档并添加它可以用于当前和未来的使用。我担心这可能会引入内存泄漏等问题。理想情况下，桶应该对所有用户可用，而不是像只属于一个用户的cookie（我对cookie的理解可能在这里是错误的）。我还不知道是否可以全局公开一个对象，以便所有用户都可以访问它。
我不知道这是否可行，而且似乎可能需要一些时间才能完成。
require()来读取带有Node的JSON文件。这是我目前的首选，因为我可以使用fs API来处理JSON文件的定期更新。 我担心JSON文件的大小，主要是如果它们足够大，它们可能会减慢Node的速度，但我正在考虑这个，因为我将节省50 - 400次点击D B。我还假设我没有加载n次{J}个文件（n是某个时间点服务上的用户数量）
考虑以上3个选项，哪个有很好的工作机会？有些选项可能是不可能的，所以我可以将它们从我的列表中删除，可能还有其他一些我还没有考虑过。
最后，我的免责声明： 我知道这可以在SQL中使用JOIN语句轻松实现，而且我没有使用锤子来处理需要螺丝刀的东西。虽然对于我的项目的某些部分，SQL看起来很明显，但对于我存储的大部分数据，Mongo更好。另外，以经验的名义重新发明轮子会有所帮助。
由于