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

Question

我们对长期索引重建期间的最佳实践/编程提出了一般性问题。这个问题不是“特定于solr”也可以应用于原始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（也称为“live”）运行用户查询“核心”。

1. 如果您可以区分已发生变化的内容，为什么不更新实时核心？如果您可以针对PDF的实时核心和文件系统运行查询，以找出哪些文档已更新，哪些文档被删除，只需针对实时核心进行查询，并放弃此脱机过程。这将是最简单的....只需将pdf的更新时间放在solr文档中以检测哪些已更改。如果solr中不存在pdf，则添加它。保留solr文档ID列表，最后，可以删除任何没有匹配PDF的文件。在此期间，您仍然可以进行实时更新。

2. 您可以代理传入的实时更新并复用（？）它们，以便它们同时转到Core1和Core0。我已经构建了一个简单的代理接口，发现它非常简单。这样，您的所有更新都将发送到您的两个核心，而您无需进行任何“对帐”。

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

喜欢听听这是怎么回事！