关于 Elasticsearch 的存储原理 ，文章将从 整体架构、底层结构、Lucene 段文件、写入-刷新-合并机制、以及运维经验 五个方面详细说明。

一、总结一句话

Elasticsearch 的数据最终是存储在 Lucene 的倒排索引文件中，按照"写入内存缓冲 → 刷盘生成 segment → 合并优化"的过程持续进行，并通过分片机制分布式存储。

二、存储架构概览

sql

复制代码

Index（逻辑索引）

├── Shard（逻辑分片） → Primary + Replica

│ ├── Lucene Index（物理索引）

│ │ ├── Segment 文件（多个）

│ │ ├── .fdt、.fdx、.tim、.tip、.doc、.cfs...

每个 ES 索引被分成多个 shard，每个 shard 是一个独立的 Lucene 实例。

Lucene 中数据被存储为多个 segment（段）文件，每个 segment 是不可变的。

三、底层存储结构：Lucene Segment

Lucene 中常见 segment 文件类型：

文件类型

描述

.fdt

存储原始字段数据（Field Data）

.fdx

文档字段索引

.doc

存储文档元数据

.tim / .tip

倒排索引（Term Info）

.cfs

Compound File（合并后统一存放）

.dvd / .dim

docValues，用于排序/聚合等

一个 segment 一旦生成就不会修改，删除是通过标记 deleted_docs 来实现。

四、写入 → 刷新 → 合并（segment lifecycle）

写入阶段

写入先进入 translog + memory buffer（倒排索引缓冲）

不立即落盘，仅进入内存和事务日志

刷新（refresh）

默认每 1 秒自动触发

将 memory buffer 中数据写入 Lucene 新的 segment，此时数据可被查询

flush

将 memory buffer 和 translog 强制写入磁盘，并清空 translog

避免数据丢失，用于快照、重启恢复

合并（merge）

多个小 segment 合并为一个大 segment

优化磁盘空间和查询性能（减少文件句柄、IO 开销）

可能带来磁盘使用率短暂上升

五、经验与调优

场景

现象

优化建议

大量 segment 存在

查询变慢，句柄过多

配置 merge.policy 控制自动合并，或使用 force merge

写入磁盘慢

I/O 等待高

使用 SSD，合理配置 refresh/flush 间隔

数据丢失

crash 时未写入磁盘

开启 translog.durability=async（提高写入）或 request（提高安全）

冷数据占用空间大

老数据 segment 多

考虑使用 rollover + ILM 做冷热分离

总结一句话

Elasticsearch 的存储底层依赖 Lucene，通过 segment 文件组成倒排索引，并通过写入 → 刷新 → 合并机制确保数据可搜索、可持久、性能可控，熟悉这些原理有助于我们在写入调优、查询性能、集群稳定性方面做出更好的决策。