indexing - 长时间重建后确保 Solr/Lucene 索引为 "up to date"的最佳实践

Question

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

问题

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

上下文

在 Solr

中索引的大型数据库和文件系统(例如 pdf)

多核 solr 实例，其中 core0 用于“搜索”，所有添加/更改/删除 core1 用于“重建”。 Core1 是“临时核心”。

重建结束后，我们将 core1 “移动”到 core0，因此搜索和更新将针对新重建的数据库

当前方法

重建过程查询数据库和/或遍历文件系统以查找“所有数据库记录”或“所有文件”

如果它们发生在查询/文件系统遍历结束时，重建将“获取”新的数据库记录/pdf。 (例如，查询是“select * from element order by element_id”。如果我们保持结果集打开——即不是一次构建一个大列表——结果集将包括最后添加的条目。类似地，如果新文件在“最后”添加(新文件夹或新文件)，文件遍历将包括这些文件。

重建不会“获得”以下内容:对重建过程已经处理的数据库记录/文档的更改或删除，“只是重新索引”

建议的方法

在 Solr 客户端(即通过数据库表)中跟踪数据库/文件系统发生的所有添加/更改/删除

在重建结束时(但在交换核心之前)，处理这些更改:即从索引中删除所有已删除的记录/pdf，重新索引所有更新和添加

关注

有没有更好的方法

solr 有什么神奇的方法可以将 core0 “融合”到 core1

谢谢

Answer 1

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

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

您可以代理传入的实时更新并多路复用(？)它们，以便它们同时发送到 Core1 和 Core0。我已经构建了一个简单的代理接口(interface)，发现它非常简单。这样，您的所有更新都将发送到您的两个核心，而您不必进行任何“和解”。

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

喜欢听听这是怎么回事!