当前位置：首页 > news >正文

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

news 2026/4/25 12:40:49

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 什么是 Segment？

Segment 是 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_id=5 旧 Segment 中：doc_id=5 → 标记为 deleted 新 Segment 中：doc_id=5（新版本）→ 正常写入

3.2 删除一条数据？

只是打标记（deleted = true），并不会立刻释放空间。

删除 doc_id=10 Segment 中：doc_id=10 → 标记为 deleted 磁盘空间：暂不释放（等 merge 清理）

3.3 核心公式

update = delete（标记旧版本）+ insert（写入新版本） delete = 标记删除（不释放空间）

四、为什么需要 Merge（段合并）

如果一直只写不合并，会出现什么问题？

写入 10000 条数据 → 产生几千个小 Segment 问题： ├── 查询要扫描几千个 Segment → 慢 ├── 有大量"已删除但没清理"的数据 → 浪费空间 ├── 文件句柄占用多 → 系统资源紧张 └── 倒排索引分散 → 无法利用压缩优化

所以引入一个机制：

👉Merge（段合并）：后台定期将多个小 Segment 合并成少量大 Segment

五、Merge 到底干了什么？

Merge 执行三个核心操作：

5.1 合并 Segment

seg_1 + seg_2 + seg_3 + seg_4 → seg_big

5.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，再同步 Replica：

Client → 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. 更新 checkpoint

9.2 flush 触发时机

触发条件	说明
`translog`太大	默认 512MB，防止恢复时间过长
定时触发	每 5 秒检查一次
手动触发	`POST /index/_flush`

9.3 refresh vs flush（易混淆点）

维度	refresh	flush
做了什么	内存 → 新 Segment	Segment 落盘 + 清 Translog
数据可搜索？	✅ 是	✅ 是
数据持久化？	❌ 否（内存 Segment）	✅ 是（磁盘 Segment）
触发频率	每秒（默认）	条件触发（远低于 refresh）
代价	中等（产生新 Segment）	较高（磁盘 fsync）

十、translog：数据安全的第一道保障

10.1 什么是 translog？

translog（transaction 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:512mb

10.4 数据安全的三个阶段（面试级表述）

阶段 1：写入 translog 成功 → 具备"可恢复性"（宕机不丢数据） 阶段 2：refresh 完成 → 具备"可搜索性"（查询可见） 阶段 3：flush 完成 → 具备"持久性"（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] → 只返回 doc1

11.3 倒排索引的组成

倒排索引 ├── Term Dictionary（词典）：所有去重词的有序列表 │ └── 用 FST（Finite State Transducer）压缩存储 ├── Postings List（倒排链）：每个词对应的文档 ID 列表 │ └── 用 Frame of Reference（FOR）压缩 └── 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_interval`	1s	-1（关闭）或 30s	减少 Segment 生成
`number_of_replicas`	1	0（写入阶段）	减少副本同步开销
`translog.durability`	request	async	减少 fsync 次数
`bulk_size`	-	5~15MB/批	平衡内存和网络
`index.buffer_size`	10% JVM	20%~30% JVM	增大 Buffer

13.4 写入完成后别忘了恢复

# 恢复副本PUT /my_index/_settings{"index":{"number_of_replicas":1,"refresh_interval":"1s"}}# 强制 merge（可选，让 Segment 尽快合并）POST /my_index/_forcemerge?max_num_segments=1

十四、三道理解检查题（面试自测）

Q1：删除数据后，磁盘空间为什么不会立刻减少？

✅ ES 的删除只是打标记（deleted = true），物理空间在 Merge 时才真正释放。Merge 是后台异步执行的，不是实时触发。

Q2：bulk 写入为什么比逐条写入性能高？

✅ bulk 将多条写入合并为一次请求，减少了 refresh 次数和网络往返。每次 refresh 会生成新 Segment，而 Segment 越多，merge 压力越大，写入吞吐越低。bulk 从根源上减少了 Segment 的生成。

Q3：为什么 refresh 太频繁会拖慢写入？

✅ refresh 会生成新的 Segment。频繁 refresh 导致 Segment 数量激增，触发更多 Merge 操作。Merge 是重量级操作（读多 Segment + 写大 Segment + 清理删除 + 重压缩），大量消耗 IO 和 CPU，最终拖慢写入吞吐。

十五、总结：最基础的三板斧 + 写入链路一句话

如果你只记三件事：

#	核心认知	说明
1️⃣	ES 不修改数据，只追加	`update = delete + insert`
2️⃣	数据存储在 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 │ ▼ Refresh（1s 默认）── Buffer → 新 Segment → 可搜索 │ ▼ Flush（条件触发）── Segment 落盘 + 清 Translog → 持久化 │ ▼ Merge（后台持续）── 合并 Segment + 清理删除 + 压缩优化 │ ▼ 优化后的存储（文档数↑，size 可能↓）