MongoDB文本索引搜索对于大表中的常用单词来说很慢

Question

我正在为一项服务托管一个mongodb数据库，该服务支持对包含680万条记录的集合进行全文搜索。

其文本索引包括十个具有不同权重的字段。

大多数搜索只需不到一秒钟。有些搜索需要两到三秒钟。但是，有些搜索需要15到60秒！ 15-60秒的搜索案例对我的申请来说是不可接受的。我需要找到一种方法来加快这些速度。

在搜索查询中使用索引中非常常见的单词时，搜索需要15-60秒。

我似乎文本搜索功能不支持延迟参数。我的第一个想法是在我的文本索引中缓存50个最常见单词的列表，然后让mongodb评估最后（懒惰）并在较不常见的参数返回的过滤结果之上。希望人们还在我身边。例如，假设我有一个“产品巧克力”的查询，其中产品很常见，而巧克力并不常见。我希望能够先让mongodb评估“巧克力”，然后用“产品”术语过滤这些结果。有谁知道实现这个目标的方法？

我可以通过从db查询中省略最常用的单词（即“products”），然后在接收到db找到的记录之后在应用程序端重新应用公共术语过滤器来实现上述场景。所有查询逻辑最好在数据库上进行，但是对于速度支付，我可以接受应用程序端处理。

此设计中仍有一些漏洞。如果用户只搜索常用术语，我别无选择，只能使用所有术语来访问数据库。从初步阅读开始，我认为不建议（或不支持）在同一个集合上有多个文本索引（具有不同的名称）。我的计划是创建两个相同的表，每个表都有我的6.8M记录，具有不同的索引 - 一个用于常用词，一个用于非常用词。这感觉很笨拙，但我愿意这样做以提高速度。

是否有人对如何加速此系统有任何见解和/或建议。我希望尽可能多地在数据库上进行处理以保持快速。我敢肯定我的小6.8M记录表不是mongodb看到的最大记录表。谢谢！

Answer 1

我通过允许MongoDB全文搜索以OR格式搜索来解决这些性能问题。我通过微调我的索引字段的权重并按排名排序来优先考虑我的结果。我得到的结果比预期的要多，但这不是一个大问题，因为我的加权结果出现在顶部很可能会在我的用户在底部得到不太相关的结果之前消耗掉。

如果有人只使用AND搜索来解决MongoDB文本搜索性能问题，只需切换回OR并使用权重控制结果。它更好地实现了飞跃。

HTH

Answer 2

这与$ all与$ in完全相同。 $ all仅使用数组中第一个关键字的索引。我相信你在这里看到同样的问题，为什么OR a.k.a. IN适合你。