Elasticsearch - 底层存储原理 Elasticsearch 如何与文件系统交互

原创于 2025-11-18 15:00:00 发布 · 1.7k 阅读

8 ·

CC 4.0 BY-SA版权

文章标签：

#elasticsearch #交互 #大数据

ElasticSearch100篇专栏收录该内容

93 篇文章

订阅专栏

在这里插入图片描述

👋 大家好，欢迎来到我的技术博客！
💻 作为一名热爱 Java 与软件开发的程序员，我始终相信：清晰的逻辑 + 持续的积累 = 稳健的成长。
📚 在这里，我会分享学习笔记、实战经验与技术思考，力求用简单的方式讲清楚复杂的问题。
🎯 本文将围绕ElasticSearch这个话题展开，希望能为你带来一些启发或实用的参考。
🌱 无论你是刚入门的新手，还是正在进阶的开发者，希望你都能有所收获！

文章目录

Elasticsearch - 底层存储原理：Elasticsearch 如何与文件系统交互

Elasticsearch - 底层存储原理：Elasticsearch 如何与文件系统交互

在现代数据密集型应用中，Elasticsearch 凭借其卓越的全文检索能力、实时分析性能和横向扩展架构，成为日志聚合、监控告警、电商搜索等场景的首选引擎。然而，许多开发者仅将其视为一个“黑盒”——调用 REST API 写入文档，稍后即可高效查询。这种抽象虽提升了开发效率，却也掩盖了其底层复杂的存储机制。

真正理解 Elasticsearch 的性能瓶颈、故障恢复逻辑、资源调优策略，必须深入其与操作系统的交互细节，尤其是它如何利用文件系统进行数据持久化、缓存管理与 I/O 优化。

本文将系统剖析 Elasticsearch 的底层存储原理，涵盖 Lucene 索引结构、段（Segment）机制、倒排索引与正排索引的物理布局、文件系统缓存（Page Cache）的巧妙利用、fsync 与 refresh 的权衡、存储介质选择建议等内容，并辅以 Java 代码示例、Mermaid 架构图、可验证的外部链接，助你从“会用”走向“精通”。

🔍 一、核心基石：Apache Lucene 与倒排索引

Elasticsearch 并非从零构建存储引擎，而是基于 Apache Lucene —— 一个高性能、全功能的 Java 搜索库。Lucene 提供了倒排索引（Inverted Index）、文档存储、打分模型等核心能力，而 Elasticsearch 在其之上增加了分布式协调、REST 接口、集群管理等功能。

什么是倒排索引？

传统数据库使用 正排索引（Forward Index）：DocID → Content
而搜索引擎使用 倒排索引（Inverted Index）：Term → List of DocIDs

例如：

文档 ID	内容
1	“apple banana”
2	“banana cherry”

其倒排索引为：

apple   → [1]
banana  → [1, 2]
cherry  → [2]

当用户搜索 banana，系统直接定位到文档 1 和 2，无需遍历所有文档。

🔗 Lucene 官方介绍：Apache Lucene - Core

📁 二、索引的物理结构：段（Segment）与文件布局

在 Lucene 中，索引（Index）由多个不可变的段（Segment）组成。每个段是一个独立的倒排索引，包含完整的索引数据结构。

为什么使用“段”？

写入高效：新文档先写入内存缓冲区（Buffer），定期 flush 成新段，避免频繁随机写。
读取高效：段是只读的，可被多个线程安全访问，无锁设计。
合并优化：小段可合并为大段，减少文件数量，提升查询性能。

段的文件组成（关键文件）

当你在 Elasticsearch 中创建一个索引并写入数据后，在磁盘上会看到类似如下文件（路径：/var/lib/elasticsearch/nodes/0/indices/<index_uuid>/0/index/）：

_0.cfe    # 字段信息（Field Info）
_0.cfs    # 复合文件（Compound File），若启用则合并多个小文件
_0.si     # 段信息（Segment Info）
_0_Lucene90_0.doc   # 正排存储（Stored Fields）
_0_Lucene90_0.tim   # 倒排索引的 Term Dictionary
_0_Lucene90_0.tip   # Term Dictionary 的索引（用于快速跳转）
_0_Lucene90_0.pos   # 位置信息（用于短语查询）
_0_Lucene90_0.pay   # Payload 信息
_0_Lucene90_0.vec   # 向量字段（如 dense_vector）
write.lock            # 写锁文件
segments_1            # 段清单文件，记录当前有哪些段

💡 注意：文件名前缀 _0 表示段编号，后续新段为 _1, _2…

Mermaid：Elasticsearch 索引物理结构图

该图展示了索引 → 分片 → 段 → 具体文件的层级关系。

⚙️ 三、写入流程：从内存到磁盘

Elasticsearch 的写入并非直接落盘，而是经过多层缓冲与异步持久化，以平衡性能与可靠性。

写入四阶段

客户端请求 → 协调节点（Coordinating Node）
路由到主分片（Primary Shard）
写入内存缓冲区（Memory Buffer） + Translog 日志
定期 Refresh → 生成新段（可搜索）
定期 Flush → 持久化段 + 清空 Translog

详细步骤

Step 1: 写入内存缓冲区 & Translog

文档首先写入 内存缓冲区（Memory Buffer），此时不可搜索。
同时，操作被追加到 Translog（Transaction Log） 文件中，确保即使 JVM 崩溃，数据也可恢复。

📌 Translog 默认每 5 秒 fsync 一次（index.translog.sync_interval），或每次请求后 sync（index.translog.durability: request）。

Step 2: Refresh（默认每 1 秒）

将内存缓冲区中的文档写入一个新的段（Segment），该段被打开供搜索。
此过程不涉及磁盘 I/O（除元数据外），因为段最初存在于文件系统缓存（Page Cache）中。
这就是 Elasticsearch “近实时搜索（NRT）” 的来源。

Step 3: Flush（当满足条件时）

当 Translog 达到一定大小（默认 512MB）或时间（默认 30 分钟），触发 Flush：
- 执行一次 Refresh
- 将所有内存中的段 fsync 到磁盘
- 清空 Translog

🔗 官方文档：Elasticsearch Near Real-Time Search

💾 四、文件系统交互：Page Cache 的魔法

Elasticsearch 性能的关键秘密之一，是极度依赖操作系统的文件系统缓存（Page Cache）。

什么是 Page Cache？

当进程读取文件时，Linux 内核会将文件内容缓存在内存中（Page Cache）。后续读取相同区域时，直接从内存返回，速度极快。

Elasticsearch 如何利用 Page Cache？

段文件（.tim, .doc 等）一旦生成，即被 mmap 或 read into Page Cache
查询时，Lucene 直接从 Page Cache 读取索引数据，而非磁盘
Elasticsearch 主动“放弃”JVM Heap 中的缓存，将内存留给 OS 做 Page Cache

✅ 最佳实践：JVM Heap ≤ 32GB（且 ≤ 物理内存 50%），剩余内存全部交给 OS 做缓存。

示例：内存分配建议

假设服务器有 64GB RAM：

JVM Heap: 31GB（避免压缩指针失效）
OS Page Cache: ~33GB（用于缓存段文件）
剩余：OS 内核、其他进程

若错误地将 Heap 设为 50GB，则 Page Cache 仅剩 14GB，大量 I/O 需回退到磁盘，性能骤降。

🔗 深度解析：Elasticsearch Heap Sizing

🔁 五、段合并（Merge）：性能与空间的博弈

随着写入持续进行，小段越来越多，导致：

查询需遍历多个段，性能下降
文件句柄耗尽
磁盘空间浪费（删除文档不会立即释放空间）

段合并机制

Lucene 后台线程会自动将小段合并为大段：

合并策略：TieredMergePolicy（默认）
合并过程：
1. 选择若干小段
2. 读取其文档，过滤已删除文档
3. 写入一个新段
4. 删除旧段文件

合并的代价

CPU 消耗：需重新构建索引结构
I/O 压力：读取旧段 + 写入新段
临时磁盘空间：新段生成期间，旧段仍存在

控制合并（通过 Index Settings）

PUT /my-index/_settings
{
  "index": {
    "merge": {
      "policy": {
        "max_merge_at_once": 10,
        "segments_per_tier": 10,
        "floor_segment": "2mb"
      }
    }
  }
}

⚠️ 警告：不要完全禁用合并！否则查询性能会严重退化。

🧹 六、删除与更新：标记删除（Delete Marking）

Lucene 段是不可变的，因此：

删除文档 = 在 .del 文件中标记该文档为 deleted
更新文档 = 删除旧文档 + 写入新文档

只有在段合并时，被标记删除的文档才会真正从磁盘移除。

查看删除文档数量

curl -X GET "localhost:9200/my-index/_segments?pretty"

响应中包含：

"segments": {
  "_0": {
    "num_docs": 1000,
    "deleted_docs": 50,
    "size_in_bytes": 1024000
  }
}

若 deleted_docs 比例过高（如 >20%），应考虑强制合并：

POST /my-index/_forcemerge?max_num_segments=1

🔗 强制合并文档：Force Merge API

💻 七、Java 代码示例：直接操作 Lucene 索引

虽然通常通过 Elasticsearch API 操作，但理解底层可编写更高效的工具。

示例 1：创建 Lucene 索引并写入文档

import org.apache.lucene.analysis.standard.StandardAnalyzer;
import org.apache.lucene.document.Document;
import org.apache.lucene.document.Field;
import org.apache.lucene.document.TextField;
import org.apache.lucene.index.IndexWriter;
import org.apache.lucene.index.IndexWriterConfig;
import org.apache.lucene.store.FSDirectory;

import java.nio.file.Paths;

public class LuceneIndexExample {
    public static void main(String[] args) throws Exception {
        // 指定索引目录（对应 ES 的 shard 目录）
        FSDirectory directory = FSDirectory.open(Paths.get("/tmp/lucene-index"));

        StandardAnalyzer analyzer = new StandardAnalyzer();
        IndexWriterConfig config = new IndexWriterConfig(analyzer);
        config.setOpenMode(IndexWriterConfig.OpenMode.CREATE_OR_APPEND);

        try (IndexWriter writer = new IndexWriter(directory, config)) {
            Document doc = new Document();
            doc.add(new TextField("title", "Elasticsearch Storage Internals", Field.Store.YES));
            doc.add(new TextField("content", "How ES interacts with filesystem...", Field.Store.YES));
            writer.addDocument(doc);
            writer.commit(); // 触发 flush，生成 segment
        }

        System.out.println("Index created at /tmp/lucene-index");
    }
}

示例 2：读取段信息

import org.apache.lucene.index.DirectoryReader;
import org.apache.lucene.index.SegmentInfos;

public class ReadSegments {
    public static void main(String[] args) throws Exception {
        try (DirectoryReader reader = DirectoryReader.open(FSDirectory.open(Paths.get("/tmp/lucene-index")))) {
            SegmentInfos segmentInfos = reader.segmentInfos;
            System.out.println("Number of segments: " + segmentInfos.size());
            for (int i = 0; i < segmentInfos.size(); i++) {
                var info = segmentInfos.info(i);
                System.out.printf("Segment %s: docs=%d, del=%d%n",
                    info.info.name,
                    info.info.maxDoc(),
                    info.getDelCount());
            }
        }
    }
}

💡 依赖（Maven）：

<dependency>
    <groupId>org.apache.lucene</groupId>
    <artifactId>lucene-core</artifactId>
    <version>9.9.2</version>
</dependency>
<dependency>
    <groupId>org.apache.lucene</groupId>
    <artifactId>lucene-analyzers-common</artifactId>
    <version>9.9.2</version>
</dependency>

🖥️ 八、存储介质选择：SSD vs HDD vs NVMe

Elasticsearch 对 I/O 延迟极其敏感，强烈推荐使用 SSD 或 NVMe。

不同介质性能对比

操作	HDD (7200 RPM)	SATA SSD	NVMe SSD
随机读延迟	~10 ms	~0.1 ms	~0.01 ms
IOPS	~100	~50,000	~500,000+
吞吐量	~150 MB/s	~500 MB/s	~3500 MB/s

为什么需要低延迟？

查询需随机访问多个段文件（.tim, .pos 等）
合并操作涉及大量随机读写
Translog 需要低延迟 fsync

✅ 生产建议：Data 节点必须使用 SSD/NVMe，Master 节点可用 HDD

🔐 九、数据持久性与 fsync

Translog 的持久化策略

# elasticsearch.yml
index.translog.durability: request  # 每次请求后 fsync（最安全，性能最低）
# or
index.translog.durability: async     # 每 5 秒 fsync（默认）

Refresh vs Flush vs fsync

操作	是否可搜索	是否持久化	是否 fsync
写入内存缓冲区	❌	❌	❌
Refresh	✅	❌（在 Page Cache）	❌
Flush	✅	✅	✅（段 + Translog）

📌 只有 Flush 后的数据才能在断电后恢复！

🧪 十、性能调优建议

1. 禁用 Swap

# elasticsearch.yml
bootstrap.memory_lock: true

并设置 vm.swappiness=1（Linux）

2. 调整 Refresh Interval

高写入场景可增大间隔：

PUT /logs-2025-11/_settings
{
  "index.refresh_interval": "30s"
}

3. 使用 SSD + XFS 文件系统

XFS 在大文件和高并发下表现优于 ext4。

4. 监控段数量与合并

# 查看段数量
GET /_cat/segments?v&h=index,segment,count,docs.deleted

# 查看合并状态
GET /_cat/thread_pool?v&h=node_name,merge,active,rejected

🧩 十一、Elasticsearch 与文件系统的协同设计哲学

Elasticsearch 的存储设计体现了 “信任操作系统” 的哲学：

不重复造轮子：利用 Page Cache 而非自建缓存
拥抱不可变性：段只读，简化并发控制
异步持久化：通过 Translog 保证可靠性，而非阻塞写入
批处理优化：Refresh/Flush/Merge 均为批量操作

这种设计使其在通用硬件上也能实现高性能，但也对运维提出更高要求——必须理解其与 OS 的交互边界。

✅ 总结

Elasticsearch 的底层存储并非神秘黑盒，而是建立在 Lucene 段机制与操作系统文件系统之上的精巧工程：

索引 = 多个只读段的集合
写入 = 内存缓冲 + Translog → Refresh → Flush
查询 = 利用 Page Cache 高速访问段文件
删除 = 标记 + 合并时清理
性能 = SSD + 合理 Heap + 段管理

掌握这些原理，你将能：

准确诊断慢查询（是否缺 Page Cache？）
合理规划硬件（SSD 必须！）
安全调整参数（refresh_interval, merge policy）
编写高效工具（直接操作 Lucene）

愿你在数据海洋中，不仅会航行，更能造舟！⛵🌊

📚 可靠外部资源：

Apache Lucene File Formats
Elasticsearch Storage Internals (官方博客)
Understanding Elasticsearch Refresh and Flush
Lucene in Action (Book Excerpt)
Filesystem Cache Tuning for Elasticsearch

🙌 感谢你读到这里！
🔍 技术之路没有捷径，但每一次阅读、思考和实践，都在悄悄拉近你与目标的距离。
💡 如果本文对你有帮助，不妨 👍 点赞、📌 收藏、📤 分享给更多需要的朋友！
💬 欢迎在评论区留下你的想法、疑问或建议，我会一一回复，我们一起交流、共同成长 🌿
🔔 关注我，不错过下一篇干货！我们下期再见！✨