MongoDB文本索引搜索缓慢的大表中的常见单词

Question

我正在主持一个支持全文搜索的680万条记录集合的服务的MongoDB数据库。

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

大部分的搜索需要不到一秒。一些搜索需要两到三秒钟的时间。但是，一些搜索需要15-60秒！ 15-60秒的搜索情况对我的应用程序来说是不可接受的。我需要找到一种方法来加速这些。

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

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

我可以通过从数据库查询中省略最常见的单词（即“产品”），然后在接收到db找到的记录之后在应用程序端重新应用通用术语过滤器来实现上述方案。所有查询逻辑最好发生在数据库上，但是我们可以向应用程序端处理速度支付。

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

有没有人有任何关于如何加快这个系统的见解和/或建议。我希望尽可能多的数据库上的处理以保持速度。我敢肯定，我的小6.8M记录表并不是mongodb所见过的最大记录表。谢谢！

Answer 1

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

如果有人正在使用AND搜索来挣扎MongoDB文本搜索性能，只需切换回OR并使用权重控制结果。它表现更好。

心连心

Answer 2

这是完全一样的问题，因为所有$男性的为$英寸$ all仅使用数组中第一个关键字的索引。我相信你在这里看到了同样的问题，这就是为什么OR a.k.a. IN为你工作的原因。