solr 过滤器是如何实际实现的？

Question

我对查询处理的理解正确吗？

1. 从缓存中获取 DocSet 或第一个过滤器查询将创建 OpenBitSet 或 SortedVIntSet 的实现并缓存它
2. 从缓存中获取 DocSet 或所有其他过滤器都会创建它们的 DocBitSet 实现，并将与原始过滤器相交（此代码的效率取决于 DocSet 的第一个实现的实现）李>
3. 我们使用 Lucene 过滤器+查询搜索对 MainQuery 和最终 DocSet（在所有交集之后）进行跨越（效率取决于第一个 DocSet 实现）
4. 我们应用后置过滤器（成本 > 100 && 缓存==false）作为原始查询的 AND

因此，性能将取决于第一个过滤器，因为对于小型查询，SortedIntSet 更有效，而对于大型 BitSet 则更好。 我对么？

问题的第二部分： DocSet 有两个主要实现 - HashDocSet 和 SortedIntDoc，每个交集实现迭代第一个过滤器中的所有实例并检查它是否也在第二个 DocSet 中......这意味着我们必须按大小对过滤器进行排序，最小的在前。 是否可以控制缓存过滤器的顺序（成本仅适用于非缓存过滤器）？

Answer 1

听起来不错。欲了解更多信息，请查看SolrIndexSearcher#getProcessedFilter。

因此，性能将取决于第一个过滤器，因为对于小型查询，SortedIntSet 更有效，而大型 BitSet 更好。我说的对吗？

这更多的是空间效率问题而不是速度问题。排序的 int[] 花费 4 * nDocs 字节，而位集花费 maxDoc / 8 字节，这就是为什么 Solr 在集合中的文档数为

问题的第二部分：DocSet 有两个主要实现 - HashDocSet 和 SortedIntDoc

SortedIntDocSet 的问题是它不支持随机访问，而 HashDocSet 的问题是它不能按顺序枚举文档 ID，这对于评分很重要。这就是为什么 Solr 几乎在所有地方都使用 SortedIntDocSet，并在需要随机访问时创建一个瞬态 HashDocSet（例如，查看 JoinQParserPlugin 或 DocSlice#intersect）。