Question

根据https://cwiki.apache.org/confluence/display/solr/Faceting，我可以使用facet.offset和facet.limit进行分页。

我认为这些对于普通查询结果类似于start和rows。

但是，如果我有太多方面的结果，这不是很慢吗？根据{{3}}：

当您希望从Solr获取大量排序结果时进入外部系统，使用非常大的值开始或行参数可能非常低效。分页使用开始和行不仅要求Solr在内存中计算（和排序）所有应该为当前页面获取的匹配文档，还有以前会出现的所有文件页。

因此，对于普通查询的深度分页，我会改为使用cursorMark。

所以

1）我是否正确使用facet.offset对facet结果进行深度分页与上面引用的性能相同？

2）对于facet结果而不是cursorMark，是否有facet.offset或更高效的深度分页？

Answer 1

是的，如果您要查看其中一个FacetCollector实现，您会看到如下内容：

@Override
  public boolean collect(BytesRef term, int count) {
    if (count > min) {
      // NOTE: we use c>min rather than c>=min as an optimization because we are going in
      // index order, so we already know that the keys are ordered.  This can be very
      // important if a lot of the counts are repeated (like zero counts would be).
      spare.copyUTF8Bytes(term);
      queue.add(new SimpleFacets.CountPair<>(spare.toString(), count));
      if (queue.size()>=maxsize) min=queue.last().val;
    }
    return false;
  }

以上一点：

maxsize = limit>0 ? offset+limit : Integer.MAX_VALUE-1;

基本上导致与深度分页相同的问题。代码将创建一个巨大的BoundedTreeSet（因为maxsize由偏移和限制的总和确定），并且复杂性将与深度分页方案中的大致相同。

然而，大多数时候，我不认为任何人的阵面值大于10_000（从我的头顶得到它，可能更少），这不应该造成任何麻烦（直到你得到了数百万个方面的价值观。）

通常，facets来自语义有限（品牌，颜色，状态，部门等）的字段，通常这些值是有限的。

总结：算法与收集匹配的文档相同，但是facet值的性质应该可以帮助我们解决问题。

关于方面结果的深度分页

1 个答案: