理解Lucene的Segement Merge

Posted 2021-04-19

我们有以下场景：

1. 弹性搜索建立在Lucene上。
2. 1400万份文件的索引基线（批量索引）
3. 每周大约有2万个文档被删除，大约3万个文档被重新索引或更新。索引通过Bulk-API以批量的2000个文档进行。

首先，我们处理文档的删除，然后出现更新。仅供参考，我们可以删除一个文档，该文档将再次由更新程序再次索引几分钟。

我的问题现在：如果ES将文档（ID：D123）标记为在段中删除（假设为A），但之后具有相同ID（ID：D123）的文档被索引到另一个段（B），该文档应该可以搜索。但是，如果发生段合并会发生什么？

段B将合并到段A中，段A包含相同文档ID的删除标志（ID：D123）。

合并后，文档是否还有删除标志？我知道，如果某个段合并，则不会合并已删除的文档。但是，合并发生的方式是否重要？将A分成B或B分成A？

我们在这种情况下丢失了一些文档但仍无法找到原因。

对于短期解决方案，我在重建索引后过滤掉要删除的文档。

我想了解整个过程。看来根本不一致！

谢谢

答案

Lucene的细分合并是创建一个包含以前细分内容的新细分，但没有删除或过时的文档。因此，使用您的示例，将按此顺序创建一个包含A和B段内容的新段C，但过滤掉新段的已删除文档。此外，每个提交创建一个新的段，它们有代（1,2，...）。因此，每个段是提交之间的时间间隔的快照，并且在合并期间首先读取B然后是A是没有意义的，因为相同文档的插入+删除不是可交换的，并且我们将在时间上“向后” 。因此，您通过删除并插入具有相同ID的新文档，有效地更新了文档ID：D123。 Lucene的索引中没有真正的更新：它是一个删除后跟一个插入。