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

Question

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

1. 从缓存中获取DocSet或第一个过滤查询将创建OpenBitSet或SortedVIntSet的实现并对其进行缓存
2. 从缓存中获取DocSet或所有其他过滤器都会创建DocBitSet的实现，并且它将与原始相交（此代码的效率取决于DocSet的第一个实现的实现 ）
3. 使用Lucene过滤器+查询搜索（效率取决于第一个DocSet实现），我们使用MainQuery和最终DocSet（在所有交叉点之后）实现越级跳跃。
4. 我们将后置过滤器（费用＆gt; 100＆amp;＆amp; cache == false）应用为orignal查询的AND

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

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

Answer 1

听起来不错。有关详细信息，请查看SolrIndexSearcher#getProcessedFilter。

  

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

这是一个空间效率问题而不是速度问题。排序的int []花费4 * nDocs个字节，而位设置花费maxDoc / 8个字节，这就是为什么当集合中的文档数量为＆lt;时，Solr使用sorted int []。 maxDoc / 32。

  

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

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