可能是一个有点老的问题和许多有用的答案和建议,但我会尝试总结结果并描述使用 cursor 对大型数据集进行分页的解决方案,bec。我最近遇到了这个问题。
作为mentioned by Yonik,通常start/rows 的问题是,当我们有大数据集并且start 比零更远(更远)时,我们有很好的在效率和内存方面的开销。这是因为从500K条记录的“中间”提取20个文档+使用排序,至少需要对所有数据集进行排序(内部唯一性排序 em>)。此外,如果搜索是分布式的,它将更加消耗资源,bec。来自每个分片的数据集(500 020 行)应返回到要合并的聚合器节点,以找出适用的 20 行。
Solr 无法计算哪个匹配文档是排序顺序中的第 999001 个结果,除非先确定前 999000 个匹配的排序结果是什么。
这里的解决方案是使用Solr cursorMark。
在第一个查询中,您宣布 &cursorMark=*.意思是下一步:
你可以认为这类似于 start=0 来告诉 Solr“从我的排序结果的开头开始”,除了它还通知 Solr 你想使用光标.
! 这里的一个“警告”是您的sort 子句必须包含 uniqueKey 字段。如果它是唯一的,它可以是id 字段。
第一个查询的一部分如下所示:
?sort=price desc,id asc&start=0&cursorMark=* ...
结果你会收到下一个结构
{
"response":{"numFound":20,"start":0,"docs":[ /* docs here */ ]},
"nextCursorMark":"AoIIRPoAAFBX" // Here is cursor mark for next "page"
}
要检索下一页,下一个查询将查找下一个:
?sort=price desc,id asc&start=0&cursorMark=AoIIRPoAAFBX ...
请注意之前回复中的cursorMark。结果,您将获得下一页结果(与第一个响应的结构相同,但具有另一个 nextCursorMarker 值)。等等……
这种方法非常适合无限滚动分页,但要在经典分页中使用它,需要考虑一些事情:)。
这里有一些我找到的解决这个问题的参考资料,希望它可以帮助某人完成它。