这是一个基本问题，但非常重要，我不确定是否真的明白这一点。

关于官方文档我们可以阅读

MongoDB keeps all of the most recently used data in RAM. If you have created indexes for your queries and your working data set fits in RAM, MongoDB serves all queries from memory.

我不太明白的部分是

If you have created indexes for your queries and your working data set fits in RAM

这里的“索引”是什么意思？

例如，如果我更新一个模型，然后我查询它，因为我已经更新了它，它现在在 RAM 中，所以它将来自内存，但这在我的脑海中不是很清楚。

我们如何确定我们查询的数据是否来自内存？我知道 MongoDB 使用空闲内存来缓存有关当前空闲内存的数据，但是有人可以进一步解释全局行为吗？

在哪种情况下，在存储数据的节点服务器中使用变量比信任 MongoDB 缓存系统更好？

您如何在全局范围内建议使用 MongoDB 处理巨大的流量？

最佳答案

注意:这是在 2013 年写的，当时 MongoDB 还很年轻，它没有今天的功能，虽然这个答案仍然适用于 mmap，但不适用于MongoDB 现在实现的其他存储技术，例如 WiredTiger 或 Percona。

一个很好的开始理解什么是索引的地方:http://docs.mongodb.org/manual/core/indexes/

在您复习这些内容后，您会明白为什么它们如此出色，但是，请直接跳到一些更复杂的问题。

How can we be sure that datas we query will come from the memory or not?

一种方法是查看任何查询 explain() 上的 yields 字段。这将告诉您有多少次读取器因为数据不在 RAM 中而产生了锁定。

另一种更深入的方法是查看像 mongostat 这样的程序。和其他此类程序。这些程序会告诉您 mongod 上发生了哪些页面错误(当需要将数据从磁盘分页到 RAM 时)。

I understand that MongoDB uses the free memory to cache datas about the memory which is free on the moment, but does someone could explain further the global behavior ?

这实际上是不正确的。说 MongoDB 做到这一点更容易，但实际上它没有。实际上是操作系统和它自己的分页算法，通常是 LRU ，这对 MongoDB 来说是这样的。 MongoDB 会在一段时间内缓存索引计划，这样它就不必不断地检查和测试索引。

In which case could it be better to use a variable in our node server which store datas than trust the MongoDB cache system?

不确定您希望它如何工作...我的意思是两者做的事情完全不同，如果您打算在启动时将数据从 MongoDB 读取到应用程序中，那么我绝对不会推荐它。

除了内存管理的操作系统算法非常成熟和快速，所以没关系。

How do you globally advise to use MongoDB for huge traffic?

嗯，这是一个非常大的问题。真的，我会建议你在这个主题上稍微谷歌一下，但正如文档所述，你需要确保你的工作集适合一个人的 RAM。

这是一个很好的起点:What does it mean to fit "working set" into RAM for MongoDB?

https://stackoverflow.com/questions/17534628/