MongoDB:索引在100+ mio文档上非常慢

Question

我指望的是有超过1亿份文件的收藏。

我的问题是：

{
"domain": domain,
"categories" : "buzz",
"visit.timestamp" : { "$gte": date_from, "$lt": date_to },
}

我只投影_id。

我有一些索引，例如：

{ "visit.timestamp": -1 }

和复合指数，如：

{ "visit.timestamp": -1, "domain": 1, "categories" : 1 }

例如，基于最后30天的计数，在30秒内得出结果。一个explain()显示查询使用最简单的索引：{ "visit.timestamp": -1 }

因此，我试图按其他顺序强制使用复合索引：

{ "categories" : 1, "domain": 1, "visit.timestamp": -1 }
{ "domain": 1, "categories" : 1, "visit.timestamp": -1 }

然后，查询使用其中之一，但是结果花费的时间要长得多:在第一种情况下~60秒，对于另一种情况，超过241秒！

注释1: --聚合框架的结果是一样的，但这并不令人惊讶。

备注2: "visit.timestamp“是ISODate。每一份文件都比前一份文件更近期。

注释3:返回140万个文档(在1.05亿文档中)，但检查了1200万个文档(见下文)。

问题：

1/我不明白为什么一个查询在使用应该完全覆盖它的索引时花费更长的时间。你有什么解释吗？

2/您有什么提示可以改善此查询的响应时间吗？explain()显示查询所查看的是：

"totalKeysExamined": 12628476,
"totalDocsExamined": 12628476,

因为，正如我所理解的，索引只覆盖日期索引visit.timestamp，因此必须检查时间范围内的所有文档。

Answer 1

第二个问题：

1. 确保问题在MongoDB的范围内。将它与应用程序代码隔离开来，I/O通过本地连接到(一个) MongoDB服务器并执行查询来实现这一点。
2. 在本地发生？检查服务器的CPU和磁盘运行情况。
3. CPU和磁盘都不适合出汗？确保您的索引符合RAM。。引用MongoDB的FAQ：

如果索引不适合RAM，会发生什么情况？ 当索引太大，无法容纳内存时，MongoDB必须从磁盘读取索引，这比从RAM读取索引要慢得多。请记住，当您的服务器有可用的RAM用于索引时，索引与工作装置的其余部分相结合时，索引适合RAM。 在某些情况下，索引不需要完全适应RAM。有关详细信息，请参阅仅保存RAM中最近值的索引。

第一个问题：

也许你的索引不适合RAM。使其复合可能会增加磁盘的I/O操作次数。不过，我不是MongoDB专家。