优化 Solr 以进行排序答案

【问题标题】：Optimizing Solr for Sorting优化 Solr 以进行排序
【发布时间】：2011-04-02 06:33:22
【问题描述】：

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

有什么更好的方法？

【问题讨论】：

标签： lucene solr

【解决方案1】：

我找到了答案。

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

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

【讨论】：

【解决方案2】：

显而易见的第一个问题：您的时间字段的类型是什么？如果是字符串，那么排序显然很慢。 tdate 甚至比 date 还要快。

还有一点：你有足够的内存供 Solr 使用吗？如果它开始交换，那么性能会立即变得糟糕。

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

【讨论】：

我在一个分配了 30GB RAM 的专用机器上安装了 Solr。也就是说，当 Solr 尝试按日期排序时，“显示所有项目，第 1 页，每页 100 行”的查询将交换（我假设），因为我的索引约为 120GB。我认为这是我问题的根源。我正在使用最新的 Solr 1.4.1，我认为它与最新的 Lucene 一起提供。我正在使用日期。也许 tdate 会加快速度？
Solr 1.4.1 使用 tdate 作为日期字段，但精度步长为 0。我将其提高到 4 的精度步长（推荐的默认值），但我没有看到速度增加。我认为问题只是在运行巨型数据集时进行交换。

【解决方案3】：

警告：野蛮建议，并非基于先前的经验或已知事实。 :)

执行不排序且 rows=0 的查询以获取匹配数。禁用分面等以提高性能 - 我们只需要匹配的总数。
根据第 1 步中的匹配数、数据分布和所需结果的计数/偏移量，触发另一个按日期排序并在日期上添加过滤器的查询，例如 @987654321 @ 其中x 是我们将找到所需数量的匹配文档的估计时间段（以天为单位）。
如果第 2 步的结果数量少于您需要的数量，请稍微放松过滤器并触发另一个查询。

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

如果您每天将n 文档统一添加到大小为N 文档的索引中，并且在步骤#1 中与d 文档匹配的特定查询，那么要获得顶部的r 结果，您可以使用@ 987654328@。如果您不得不在第 3 步中过于频繁地放松过滤器，请根据需要慢慢增加公式中的值 1.2。

【讨论】：

这可能真的有效。执行两次搜索的代价可能会增加大约 200 毫秒的请求，但避免对大型数据集进行排序可能是值得的。我会试试这个。不过我认为一定有更好的方法。
是的，我同意这看起来有点不稳定。另一种选择（我的回答中的警告仍然适用）可能是维护多个索引 - 一个包含上周的数据，另一个包含上个月的数据，另一个包含去年的数据等。（根据您的要求选择时间段和数据/查询分布）。当您获得一个新查询时，在最小的索引上触发它并检查您是否获得了所需数量的结果。如果没有，请在连续更大的索引上触发它，直到获得所需数量的结果。