我正在开发一个结构化文档查看器，其中每个Solr文档都是大量法律文档中的“部分”或“段落”，以及各种元数据。我有一个语料库，可能代表10 ^ 12或更多这些部分。我想为用户提供分页，以便他们可以sort_path顺序一次查看这些部分中的N个。
现在出现问题：即使sort_path被编入索引，也会一直添加和删除文档。一个简单的排序和分页解决方案将最终导致用户可能会跳过部分或意外地跳出订单，即使他们远远没有在订购中添加/删除的文档;这种行为是不可接受的。
示例：我将“下一页”链接点设为...sort_order=sort_path+desc&rows=N&start:12345。然后，当用户正在查看页面时，将删除sort_path顺序中早期的文档。现在当他们获取接下来的N行时，他们会在不知情的情况下跳过1个文档。
所以，鉴于我有一个sort_path字段来命令这些部分，前端需要能够在“之前”或“之后”sort_path:/X/Y/Z请求N个部分，而不是要求{ {1}} rows:N。我不知道如何在Solr查询中表示这一点。
我可能会把Solr的边缘推得太远，最终可能会更有意义地在Solr中存储这些“section”文档的表示（对于内容搜索，Solr非常棒）和RDBMS（用于订购和索引）。我希望避免这种情况，这种查询在数据库中仍然很难看，所以也许你有一些想法。 （谢谢！）
事实证明，solr范围与排序相结合可能会让我得到我需要的东西。在索引字段上，我可以执行类似
的操作start:12345获取“下一个”N个部分，然后执行
sort_path:["/A/B/C" TO *]
按sort_path:[* TO "/A/B/C"]
排序，然后反转返回的块以获取前面的N个部分。我将测试此解决方案的性能，但似乎可行。
答案 0 :(得分：2)
这不是Solr特定的问题，而是任何外部数据源分页的一般问题，因为数据源与（web）应用程序具有独立的状态。例如，它也发生在关系数据库中。 Here's对关系数据库中的分页以及可能的解决方案进行了很好的报道。大多数Web应用程序/网站采用第一种解决方案：“对每个新请求重复查询”，因为其他解决方案要复杂得多且不可扩展，但这会遇到您描述的问题。浏览stackoverflow.com上的问题一段时间，你会发现它，因为问题一直在不断创建。
在您的情况下，我会考虑将Solr文档建模为您的整个法律文档，而不是其各个部分。您将获得更少的文档（因此插入/删除速度较慢），您可以使用highlighting parameters来获取与用户查询匹配的部分的片段。
另一个选择是降低你的提交率，但这可能会导致文档新鲜度低于理想值。