Lucene 中的段（Segment）：增量索引与不可变设计的平衡
Lucene 的倒排索引一旦写入磁盘，其结构便难以修改（修改会导致大量磁盘 IO 和性能损耗）。为解决增量数据的索引问题，Lucene 引入了段（Segment） 的概念，通过 “多个不可变段的动态组合” 实现高效的增量索引和查询。
段的核心设计：不可变与增量并存
段的不可变性
- 定义：每个段是一个独立的、完整的倒排索引片段，一旦写入磁盘，其数据和结构不可修改（只读）。
- 优势：
- 查询高效：不可变结构允许 Lucene 对段进行预优化（如倒排列表压缩、缓存热点数据），提升查询速度。
- 线程安全：多个查询线程可同时读取同一网段，无需加锁，减少并发冲突。
- 故障安全：段写入过程中若发生崩溃，仅需丢弃未完成的段，不影响已提交的段。
增量索引的实现
当有新文档需要索引时，Lucene 不会修改已有段，而是：
- 创建新段：新文档被写入新的临时段（先存于内存缓冲区）。
- 批量刷盘：当内存中的文档数量或时间达到阈值（如
index.max.bufferedDocs或index.flush.interval），临时段被批量写入磁盘，成为可查询的新段。 - 逻辑组合：所有段通过 “提交点（Commit Point）” 被逻辑组合为一个完整索引，查询时 Lucene 会遍历所有段并合并结果。
示例：
- 初始索引包含段 S1（1000 文档）。
- 新增 500 文档 → 生成新段 S2（500 文档），索引由 S1 + S2 组成。
- 再新增 800 文档 → 生成新段 S3（800 文档），索引由 S1 + S2 + S3 组成。
段的合并：优化索引性能
随着增量索引的进行，段的数量会不断增加（如每次新增文档都生成新段），过多的段会导致：
- 查询效率下降（需遍历多个段，合并结果的开销增大）。
- 磁盘空间浪费（每个段有独立的元数据文件，小段位多会占用额外空间）。
因此，Lucene 会自动触发段合并（Segment Merging）：
合并过程
- 选择多个小段位合并对象（通常是大小相近的段）。
- 读取这些段的所有文档，合并为一个新的大段（倒排索引结构重新优化）。
- 标记原小段位 “已删除”，查询时不再遍历这些段（后续通过垃圾回收释放磁盘空间）。
示例：
- 段 S1（1000 文档）+ S2（500 文档）+ S3（800 文档）→ 合并为 S4（2300 文档）。
- 索引变为 S4，原 S1、S2、S3 被标记删除。
合并策略
Lucene 的 MergePolicy 控制合并时机和对象选择，常见策略：
- LogByteSizeMergePolicy（默认）：根据段的大小合并，优先合并小段位（避免大段频繁合并）。
- TieredMergePolicy：按段的数量和大小分层，合并同层中较小的段，适合大规模索引。
- 可自定义策略（如限制合并的最大段大小、合并触发的时间窗口）。
段与文档的增删改操作
段的不可变性决定了 Lucene 对文档的增删改操作需采用特殊机制：
| 操作 | 实现方式 |
|---|---|
| 新增 | 写入新段（内存缓冲 → 磁盘新段）。 |
| 删除 | 不直接删除段中的文档，而是在 .del 文件中标记文档 ID 为 “已删除”。查询时，Lucene 会过滤被标记的文档（段合并时才真正移除这些文档）。 |
| 修改 | 等价于 “删除旧文档 + 新增新文档”：旧文档被标记删除，新文档写入新段。 |
段的优势与局限
优势
- 增量索引高效：新文档无需修改旧索引，仅需写入新段，适合高频新增场景（如日志实时索引）。
- 查询性能稳定：不可变结构允许预优化和缓存，查询延迟低且可预测。
- 故障恢复简单：崩溃后仅需丢弃未提交的段，已提交的段不受影响。
局限
- 删除 / 修改延迟：被删除的文档仍占用磁盘空间，需等待段合并才会释放（可能导致短期空间浪费）。
- 合并开销：大规模段合并会消耗 CPU 和 IO 资源，可能影响查询性能（通常在低峰期自动执行）