优化Solr进行排序

Question

我正在使用Solr作为实时搜索索引。我的数据集大约是60M大文档。我需要按时间排序，而不是按相关性排序。目前我在查询中使用sort标志按时间排序。这适用于特定搜索，但是当搜索返回大量结果时，Solr必须获取所有生成的文档并在返回之前按时间排序。这很慢，必须有更好的方法。

更好的方法是什么？

Answer 1

我找到了答案。

如果您想按时间排序，而不是相关性，请对所有过滤器使用fq =而不是q =。这样，Solr不会浪费时间来计算匹配q =的文档的加权值。事实证明，Solr花了太多时间来加权，而不是排序。

此外，您可以通过在solrconfig.xml中预热newSearcher和firstSearcher事件侦听器中的排序字段来加快排序速度。这将确保通过缓存完成排序。

Answer 2

明显的第一个问题：你的时间领域是什么类型的？如果它是字符串，那么排序显然非常慢。 tdate甚至比date更快。

另一点：你对Solr有足够的记忆吗？如果它开始交换，那么性能立即变得糟糕。

第三个：如果你有较旧的Lucene，那么date只是字符串，这非常慢。

Answer 3

警告 ：狂野的建议，不是基于先前的经验或已知的事实。 ：）

1. 执行不排序的查询和rows = 0以获取匹配数。禁用分面等以提高性能 - 我们只需要匹配的总数。
2. 根据步骤1中的匹配数量，数据的分布以及所需结果的计数/偏移量，触发另一个按日期排序的查询，并在日期上添加过滤器，如{{ 1}}其中fq=date:[NOW()-xDAY TO *]是我们将找到所需匹配文档数量的估计时间段。
3. 如果步骤＃2的结果数量少于您需要的数量，请稍微放松一下过滤器并触发另一个查询。

---

对于初学者，您可以使用以下内容估算x：

如果您每天将x个文档统一添加到大小为n个文档的索引中，并在步骤1中将特定查询与N个文档进行匹配，那么就可以获得最高d个文档1}}结果您可以使用r。如果您必须在步骤3中过于放松过滤器，请根据需要在公式中慢慢增加值1.2。