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

Question

我们有一个关于长期索引重建期间的最佳实践/编程的一般性问题。这个问题不是“solr specific”，也可以适用于原始 Lucene 或任何其他类似的索引工具/库/黑盒。

问题

在长时间重建索引后确保 Solr/Lucene 索引“绝对最新”的最佳做法是什么，即如果在 12 小时的索引重建过程中，用户添加/更改/删除数据库记录或文件 ( PDF)，您如何确保最后的重建索引“包含”这些更改？

上下文

• 在 Solr 中建立索引的大型数据库和文件系统（例如 pdf）
• 多核 solr 实例，其中 core0 用于“搜索”，所有添加/更改/删除 core1 用于“重建”。 Core1 是“临时核心”。
• 重建结束后，我们将 core1 “移动”到 core0，因此搜索和更新将针对新重建的 db

当前方法

• 重建过程查询数据库和/或遍历文件系统以查找“所有数据库记录”或“所有文件”
• 如果它们发生在查询/文件系统遍历结束时，重建将“获取”新的数据库记录/pdf。 （例如，查询是“select * from element order by element_id”。如果我们保持结果集打开——即不是一次构建一个大列表——结果集将包括最后添加的条目。类似地，如果新文件在“最后”添加（新文件夹或新文件），文件遍历将包括这些文件。
• 重建将不会“获得”以下内容：对重建过程已处理的数据库记录/文档的更改或删除，“只是重新编制索引”

建议的方法

• 在 Solr 客户端（即通过数据库表）中跟踪数据库/文件系统发生的所有添加/更改/删除
• 在重建结束时（但在交换核心之前），处理这些更改：即从索引中删除所有已删除的记录/pdf，重新索引所有更新和添加

继续

• 有没有更好的方法
• solr 有什么神奇的方法可以将 core0 “融合”到 core1 中

谢谢

Answer 1

给这只猫剥皮的方法有很多种...... “ 核）。

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

2. 您可以代理传入的实时更新并多路复用 (?) 它们，以便它们同时发送到 Core1 和 Core0。我构建了一个简单的代理接口，发现它非常简单。这样一来，您的所有更新都会发送到您的两个核心，而您无需进行任何“协调”。

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

很想听听这是怎么回事！