我正在考虑使用Solr作为一个需要深度分页的用例,认为大约100k总结果的上限从大约1000万条记录的集合中分成1k页.我很快发现了为什么使用start& num_rows对于结果集来说是个坏主意,并且在进程中遇到了cursorMark.我发现有关cursorMark的文章提出了一个相对恒定的记录访问时间,无论该集合中的位置如何,这对我的情况来说都是完美的.

我遇到的问题是,这条路线会产生什么样的性能影响？假设我在时间返回1000时,使用cursorMark深度页面到1k,10k,100k,100万条记录的结果集中,在内存/ CPU使用方面是否有任何性能差异？

最佳答案 理论上,当你向下翻页时,它会更快一些.实际上,差异是如此之小,以至于你不会注意到它.

标准的非游标搜索使用一个小队列来保存top-X结果.每个匹配都添加到该队列,如果队列已满,则推出较差的匹配.

游标搜索也使用大小为X的队列.如果队列的排序值超出前一个游标标记,则每个匹配都会添加到该队列,如果队列已满,则推出较差的匹配.因此,当您更深入地页面时,插入量会少一些.

在https://lucidworks.com/blog/2013/12/12/coming-soon-to-solr-efficient-cursor-based-iteration-of-large-result-sets/处有一些非常简单的光标性能图表