确保Solr/Lucene索引在长期重建后"最新"的最佳实践

Question

我们对长期索引重建期间的最佳实践/编程提出了一般性问题.这个问题不是"solr specific"也可以适用于原始Lucene或任何其他类似的索引工具/库/黑盒子.

这个问题

在长索引重建之后确保Solr/Lucene索引"绝对最新"的最佳做法是什么,即在12小时索引重建过程中,用户是否添加/更改/删除db记录或文件(PDF),你如何确保最后的重建索引"包括"这些变化？

上下文

• 在Solr中索引的大型数据库和文件系统(例如pdf)
• 多核solr实例,其中core0用于"搜索",所有添加/更改/删除core1用于"重建".Core1是"临时核心".
• 在重建结束后,我们将'core1'移动到core0,因此搜索和更新将与新重建的数据库进行对比

目前的方法

• 重建进程查询数据库和/或遍历文件系统以查找"所有数据库记录"或"所有文件"
• 如果它们在查询/文件系统遍历结束时发生,则重建将"获取"新的db记录/ pdf.(例如,查询是"按元素顺序按元素顺序选择*".如果我们将结果集保持为open-i..e而不是一次构建一个大的列表 - 结果集将包括在末尾添加的条目.同样如果新文件被添加到"最后"(新文件夹或新文件),文件遍历将包含这些文件.
• 重建不会 "获取"以下内容:更改或删除重建过程已处理的db记录/文档,"只是重新编制索引"

提议的方法

• 跟踪Solr客户端(即通过db表)对db/filesystem发生的所有添加/更改/删除
• 在重建结束时(但在交换核心之前),处理这些更改:即从索引中删除所有已删除的记录/ pdf,重新索引所有更新和添加内容

继续

• 有没有更好的方法
• solr是否有任何神奇的手段将core0"融合"到core1中

谢谢

Answer 1

有很多方法可以给这只猫剥皮......我猜测在 core1 （又名“甲板上”核心）的漫长索引过程中，您正在针对已经填充的 core0 （又名“实时”核心）运行用户查询。

1. 如果您可以区分发生了什么变化，为什么不直接更新实时核心呢？如果您可以对实时核心和 PDF 文件系统运行查询，以找出哪些文档已更新，哪些文档已删除，那么只需对实时核心执行所有操作，并放弃此离线过程即可。这将是最简单的......只需将 pdf 的更新时间放入 solr 文档中即可检测哪些已更改。如果 solr 中不存在该 pdf，则添加它。保留 solr 文档 ID 列表，最后，任何没有匹配 PDF 的都可以删除。与此同时，您仍然可以收到实时更新。

2. 您可以代理传入的实时更新并复用（？）它们，以便它们同时到达 Core1 和 Core0。我构建了一个简单的代理界面，发现它非常简单。这样，您的所有更新都会发送至两个核心，并且您无需进行任何“协调”。

3. 最后，您可以合并两个核心：http://wiki.apache.org/solr/MergingSolrIndexes#Merging_Through_CoreAdmin 我真的不知道如果您有两个具有相同 id 的文档，或者文档不存在，会发生什么在一个核心中，但在另一个核心中......我认为这都是一个附加过程，但你想深入研究这一点。

很想听听事情进展如何！