我对查询处理的理解是否正确？
-
从缓存中获取 DocSet 或第一个过滤器查询将创建 OpenBitSet 或 SortedVIntSet 的实现并缓存它
-
从缓存中获取 DocSet 或所有其他过滤器创建它们的 DocBitSet 实现，并将与原始 (该代码的效率取决于 DocSet 的第一个实现的实现)
- 我们使用 Lucene 过滤器+查询搜索（在所有交叉点之后）对 MainQuery 和最终 DocSet 进行跨越（其效率取决于第一个 DocSet 实现)
- 我们应用后置过滤器（成本> 100 && 缓存== false）作为原始查询的AND
因此，性能将取决于第一过滤器因为对于小型查询 SortedIntSet 更有效，而对于大型 BitSet 则更好。
我对么？
问题的第二部分:
DocSet 有两个主要实现 - HashDocSet 和 SortedIntDoc，每个交集实现都会迭代第一个过滤器中的所有实例，并检查它是否也在第二个 DocSet 中...这意味着我们必须按大小对过滤器进行排序，首先是最小的。
是否可以控制缓存过滤器的顺序（成本仅适用于非缓存过滤器）？
这听起来不错。欲了解更多信息，请查看SolrIndexSearcher#getProcessedFilter http://grepcode.com/file/repo1.maven.org/maven2/org.apache.solr/solr-core/4.0.0-ALPHA/org/apache/solr/search/SolrIndexSearcher.java#SolrIndexSearcher.getProcessedFilter%28org.apache.solr.search.DocSet,java.util.List%29.
因此，性能将取决于第一个过滤器，因为对于小型查询 SortedIntSet 更有效，而对于大 BitSet 则更好。我对么？
这更多的是空间效率问题而不是速度问题。一个排序的 int[] 花费 4 * nDocs 字节，而一个位集花费 maxDoc / 8 字节，这就是为什么 Solr 在集合中的文档数量
问题的第二部分：DocSet 有两个主要实现 - HashDocSet 和 SortedIntDoc
SortedIntDocSet 的问题是它不支持随机访问，而 HashDocSet 的问题是它无法按顺序枚举文档 ID，而这对于评分可能很重要。这就是为什么 Solr 几乎在任何地方都使用 SortedIntDocSets，并在需要随机访问时创建临时 HashDocSet（例如，查看 JoinQParserPlugin 或 DocSlice#intersect）。
本文内容由网友自发贡献，版权归原作者所有，本站不承担相应法律责任。如您发现有涉嫌抄袭侵权的内容，请联系:hwhale#tublm.com(使用前将#替换为@)
