了解 Lucene 的分段合并

Question

我们有以下场景：

1. Elastic Search 基于 Lucene 构建。
2. 1400 万份文档的索引基线（批量索引）
3. 每周大约有 2 万个文档被删除，还有大约 3 万个文档被重新索引或更新。通过 Bulk-API 对 2000 个文档批量进行索引。

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

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

段 B 将被合并到段 A 中，其中包含相同文档 ID (ID:D123) 的删除标志。

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

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

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

我想了解整个过程。 好像完全不一致！

谢谢

Answer 1

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