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

Question

我对查询处理的理解是否正确？

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

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

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

Answer 1

听起来不错。有关更多信息，请查看 SolrIndexSearcher#getProcessedFilter .

So as a consequence performance will be dependent on first filter since for small query SortedIntSet is more efficient and for big BitSet is better. Am I correct?

这与其说是速度问题，不如说是空间效率问题。排序的 int[] 花费 4 * nDocs 字节，而位集花费 maxDoc/8 字节，这就是为什么只要集合中的文档数量为 < maxDoc/32，Solr 就使用排序的 int[]。

Second part of question: DocSet has two main implementation - HashDocSet and SortedIntDoc

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