Elasticsearch 底层存储与写入链路：从 Segment 到 Merge，一篇搞懂

Elasticsearch 底层存储与写入链路从 Segment 到 Merge一篇搞懂作者皮蛋0solo粥 |发布日期2026-04-22标签Elasticsearch、Lucene、Segment、写入链路、搜索引擎、底层原理目录引言先建立正确的心智模型一、核心概念Segment不可变的小索引文件二、写入一条数据到底发生了什么三、更新和删除的真相四、为什么需要 Merge段合并五、Merge 到底干了什么六、写入链路全景图七、逐层拆解写入流程八、refresh近实时搜索的关键九、flush真正的持久化十、translog数据安全的第一道保障十一、为什么 ES 查询快倒排索引十二、实战现象解释文档数↑但 size↓十三、结合实际场景理解bulk embedding 大量写入十四、三道理解检查题面试自测十五、总结最基础的三板斧 写入链路一句话引言先建立正确的心智模型很多人一开始就错在这里❌ 误解Elasticsearch 像 MySQL一条数据写进去就更新文件真实情况是✅Elasticsearch 基于 Apache Lucene底层是追加写 不可变文件模型你可以理解为ES ≈ 一个不断写新文件、很少修改旧文件的系统如果你带着ES 像 MySQL的假设去调优你会觉得很多现象不可解释。但如果从追加写 不可变文件出发一切都会变成必然。一、核心概念Segment不可变的小索引文件1.1 什么是 SegmentSegment 是 Lucene 中最核心的存储单元 一个 Segment 就是一个已经写好、不可再修改的小索引文件一个 Index索引由多个 Shard分片组成每个 Shard 内部维护了一组 Segment 文件。Index └── Shard 0 │ ├── Segment 1不可变 │ ├── Segment 2不可变 │ └── Segment 3不可变 └── Shard 1 ├── Segment 1不可变 └── Segment 2不可变1.2 Segment 的关键特性特性说明不可变Segment 一旦生成就不会修改自包含每个 Segment 包含完整的倒排索引和存储数据独立查询搜索时可以并行扫描多个 Segment逐步增长写入时不断产生新的 Segment二、写入一条数据到底发生了什么不是修改原数据而是写入数据 → 生成一个新的 Segment时间线 T1: 写入 doc1 → 生成 segment_1 T2: 写入 doc2 → 生成 segment_2 T3: 写入 doc3 → 生成 segment_3 Shard 内部[segment_1, segment_2, segment_3]到这里要形成一个核心认知ES 的数据是越写越多文件而不是修改已有文件三、更新和删除的真相3.1 更新一条数据ES 不会就地修改而是执行两步操作旧数据 → 标记删除打 delete 标记 新数据 → 写入一个新 Segment示例更新 doc_id5 旧 Segment 中doc_id5 → 标记为 deleted 新 Segment 中doc_id5新版本→ 正常写入3.2 删除一条数据只是打标记deleted true并不会立刻释放空间。删除 doc_id10 Segment 中doc_id10 → 标记为 deleted 磁盘空间暂不释放等 merge 清理3.3 核心公式update delete标记旧版本 insert写入新版本 delete 标记删除不释放空间四、为什么需要 Merge段合并如果一直只写不合并会出现什么问题写入 10000 条数据 → 产生几千个小 Segment 问题 ├── 查询要扫描几千个 Segment → 慢 ├── 有大量已删除但没清理的数据 → 浪费空间 ├── 文件句柄占用多 → 系统资源紧张 └── 倒排索引分散 → 无法利用压缩优化所以引入一个机制Merge段合并后台定期将多个小 Segment 合并成少量大 Segment五、Merge 到底干了什么Merge 执行三个核心操作5.1 合并 Segmentseg_1 seg_2 seg_3 seg_4 → seg_big5.2 清理已删除数据合并前 seg_1: [doc1✅, doc2✅, doc3❌deleted] seg_2: [doc4❌deleted, doc5✅] 合并后 seg_big: [doc1✅, doc2✅, doc5✅] ← doc3 和 doc4 被物理删除5.3 重新压缩数据倒排索引重新组织字典编码FST优化存储格式更紧凑合并前总大小seg_1(5KB) seg_2(3KB) seg_3(4KB) 12KB含 3KB 废数据 合并后总大小seg_big(7KB) ← 压缩 清理省了 5KB六、写入链路全景图一次写入不是直接落盘而是分阶段完成Client │ ▼ Coordinating Node协调节点── 不存数据只做路由调度 │ ▼ Primary Shard主分片── 真正写数据的地方 │ ├──→ Replica Shard副本分片── 数据冗余 读负载均衡 │ ▼ Indexing Buffer内存缓冲区── 数据先写这里不可搜索 │ ▼ Refresh每秒一次默认── Buffer → 新 Segment可搜索但未持久化 │ ▼ Flush条件触发── Segment 落盘 清空 Translog持久化完成 │ ▼ Merge后台持续── Segment 合并 清理删除 压缩优化一句话版本写入 先写内存 → 再变成 Segment → 最后后台优化七、逐层拆解写入流程7.1 Coordinating Node协调节点职责 ├── 接收客户端请求 ├── 根据 routing 规则找到目标 Shard ├── 转发请求到 Primary Shard └── 汇总各 Shard 结果返回客户端 关键不存数据只做调度7.2 Primary Shard主分片职责 ├── 接收写入请求 ├── 执行实际写入操作 ├── 保证数据一致性 └── 写完后同步给 Replica Shard写入是先写 Primary再同步 ReplicaClient → Primary写成功→ Replica同步→ 返回成功7.3 Replica Shard副本分片职责 ├── 数据冗余容灾Primary 挂了可以切换 ├── 提供读能力负载均衡 └── 提升查询吞吐7.4 Indexing Buffer内存缓冲区写入的数据先放这里 ├── ❌ 不可搜索还没变成 Segment ├── ❌ 不在磁盘纯内存 └── ✅ 写入延迟极低内存操作八、refresh近实时搜索的关键8.1 refresh 做了什么Indexing Buffer内存──refresh──→ 新 Segment可搜索refresh 将内存中的数据转成一个新的 Segment并打开 Searcher 使其对查询可见。8.2 refresh 之后的状态状态说明✅ 可搜索Searcher 已打开新 Segment❌ 未持久化数据仍在内存中宕机可能丢失8.3 默认行为# 默认每 1 秒 refresh 一次index.refresh_interval:1s这就是 ES 被称为Near Real-Time近实时搜索引擎的原因——写入后最多 1 秒即可被搜索到。8.4 refresh 的代价很重要每次 refresh ├── 生成一个新 Segment ├── Segment 越多 → 查询要扫越多 └── 触发 Merge 的概率越大 代价链 频繁 refresh → 大量小 Segment → merge 压力激增 → IO/CPU 上升 → 写入吞吐下降九、flush真正的持久化9.1 flush 做了什么flush 操作 1. 将内存中的 Segment 写入磁盘fsync 2. 清空 Translog 3. 更新 checkpoint9.2 flush 触发时机触发条件说明translog太大默认 512MB防止恢复时间过长定时触发每 5 秒检查一次手动触发POST /index/_flush9.3 refresh vs flush易混淆点维度refreshflush做了什么内存 → 新 SegmentSegment 落盘 清 Translog数据可搜索✅ 是✅ 是数据持久化❌ 否内存 Segment✅ 是磁盘 Segment触发频率每秒默认条件触发远低于 refresh代价中等产生新 Segment较高磁盘 fsync十、translog数据安全的第一道保障10.1 什么是 translogtranslogtransaction log是 ES 的预写日志WAL类似于 MySQL 的 redo log。写入流程实际上是 写数据 → 写 translog磁盘顺序写→ 写 buffer内存10.2 translog 的作用如果 ES 宕机 ├── 内存中的 Buffer 数据丢失 ├── 磁盘上的 Segment 数据保留 └── Translog 记录了Segment 之外的写入 恢复时 ├── 读取已有 Segment └── 重放 Translog → 补回未 flush 的数据10.3 translog 的配置# translog 刷盘策略index.translog.durability:request# 每次写入都 fsync默认最安全index.translog.durability:async# 定时 fsync性能更好可能丢数据# translog 大小阈值index.translog.flush_threshold_size:512mb10.4 数据安全的三个阶段面试级表述阶段 1写入 translog 成功 → 具备可恢复性宕机不丢数据 阶段 2refresh 完成 → 具备可搜索性查询可见 阶段 3flush 完成 → 具备持久性Translog 清空数据在 Segment 中一句话总结数据在 refresh 后对搜索可见在 translog 写入后具备容灾能力在 flush 后完成最终持久化。十一、为什么 ES 查询快倒排索引11.1 核心数据结构传统数据库正排索引文档 → 内容 doc1 → 感冒药 阿莫西林 头孢 doc2 → 止咳糖浆 胃药 doc5 → 感冒药 布洛芬 doc20 → 感冒药 对乙酰氨基酚ES倒排索引词 → 出现在哪些文档 感冒药 → [doc1, doc5, doc20] 阿莫西林 → [doc1] 止咳糖浆 → [doc2] 布洛芬 → [doc5]11.2 查询过程查询感冒药 ├── 不用扫描全量文档 ├── 直接查倒排索引感冒药 → [doc1, doc5, doc20] └── 只需读取这 3 个文档 → 极快 查询感冒药 AND 布洛芬 ├── 感冒药 → [doc1, doc5, doc20] ├── 布洛芬 → [doc5] └── 交集 [doc5] → 只返回 doc111.3 倒排索引的组成倒排索引 ├── Term Dictionary词典所有去重词的有序列表 │ └── 用 FSTFinite State Transducer压缩存储 ├── Postings List倒排链每个词对应的文档 ID 列表 │ └── 用 Frame of ReferenceFOR压缩 └── Doc Values正排数据用于排序、聚合 └── 列式存储按字段独立存储十二、实战现象解释文档数↑但 size↓这是一个非常经典的反直觉现象。理解了前面的 Segment 和 Merge 机制答案就水到渠成了写入阶段 ├── 产生大量小 Segment ├── 包含很多 delete 标记update delete insert 产生的 └── 数据比较松散压缩率低 Merge 后 ├── 删除了所有标记为 deleted 的无效数据 ├── 重新压缩 Segment倒排索引优化 └── Segment 数量减少文件系统开销降低 结果 文档数 ↑有效文档确实多了 磁盘 size ↓浪费空间被清理了十三、结合实际场景理解bulk embedding 大量写入在医药商品搜索系统的实际场景中我们经常需要做大量数据写入含 embedding 向量这时候理解写入链路就非常关键。13.1 为什么 bulk 写入比逐条写入快逐条写入1000 条 ├── 1000 次 refresh → 1000 个 Segment → merge 压力巨大 └── 1000 次网络往返 → 延迟累积 bulk 写入1000 条/批 ├── 1 次 refresh → 1 个 Segment → merge 压力小 └── 1 次网络往返 → 延迟极低13.2 为什么大数据量写入时要调大 refresh_interval# 写入阶段关闭 refresh攒够数据再开PUT /my_index/_settings{index:{refresh_interval:-1# 关闭自动 refresh}}# 写入完成后恢复 refreshPUT /my_index/_settings{index:{refresh_interval:1s}}关闭 refresh 的效果 ├── 数据持续写入 Buffer → 不产生新 Segment ├── 没有 Segment → 不触发 merge └── IO 降低 → 写入吞吐大幅提升13.3 写入优化参数速查表参数默认值写入优化建议说明refresh_interval1s-1关闭或 30s减少 Segment 生成number_of_replicas10写入阶段减少副本同步开销translog.durabilityrequestasync减少 fsync 次数bulk_size-5~15MB/批平衡内存和网络index.buffer_size10% JVM20%~30% JVM增大 Buffer13.4 写入完成后别忘了恢复# 恢复副本PUT /my_index/_settings{index:{number_of_replicas:1,refresh_interval:1s}}# 强制 merge可选让 Segment 尽快合并POST /my_index/_forcemerge?max_num_segments1十四、三道理解检查题面试自测Q1删除数据后磁盘空间为什么不会立刻减少✅ ES 的删除只是打标记deleted true物理空间在 Merge 时才真正释放。Merge 是后台异步执行的不是实时触发。Q2bulk 写入为什么比逐条写入性能高✅ bulk 将多条写入合并为一次请求减少了 refresh 次数和网络往返。每次 refresh 会生成新 Segment而 Segment 越多merge 压力越大写入吞吐越低。bulk 从根源上减少了 Segment 的生成。Q3为什么 refresh 太频繁会拖慢写入✅ refresh 会生成新的 Segment。频繁 refresh 导致 Segment 数量激增触发更多 Merge 操作。Merge 是重量级操作读多 Segment 写大 Segment 清理删除 重压缩大量消耗 IO 和 CPU最终拖慢写入吞吐。十五、总结最基础的三板斧 写入链路一句话如果你只记三件事#核心认知说明1️⃣ES 不修改数据只追加update delete insert2️⃣数据存储在 Segment不可变Segment 一旦生成就不会改3️⃣Merge 负责清理 压缩 合并后台持续优化存储结构写入链路一句话面试级表述Elasticsearch 的写入流程是先写入 Primary Shard同时记录 Translog 并写入内存 Buffer。数据在 Refresh 时会被转为 Segment从而对搜索可见。随后在 Flush 时持久化到磁盘并清理 Translog。后台通过 Merge 合并 Segment、清理删除数据并优化存储结构。写入链路全景一图总结写入请求 │ ▼ Coordinating Node ── 路由到目标 Shard │ ▼ Primary Shard ├── 写 Translog磁盘容灾保障 ├── 写 Indexing Buffer内存 └── 同步到 Replica Shard │ ▼ Refresh1s 默认── Buffer → 新 Segment → 可搜索 │ ▼ Flush条件触发── Segment 落盘 清 Translog → 持久化 │ ▼ Merge后台持续── 合并 Segment 清理删除 压缩优化 │ ▼ 优化后的存储文档数↑size 可能↓参考资料Elasticsearch 官方文档 - Index LifecycleApache Lucene - Segment File Format《Elasticsearch 权威指南》- 索引管理Lucene 源码 - IndexWriter / SegmentMerger