Elasticsearch索引存储机制及索引大小异常波动问题咨询

1. Elasticsearch是否会将多日前的文档累积至当日？ #

不会。文档的存储归属完全基于写入时的时间戳（或业务指定的时间字段），Elasticsearch不会自动把旧文档“移动”或“累积”到当日索引中。你观察到的索引先持续增大后突然变小的现象，大概率是**段合并（Segment Merging）**导致的：

• Elasticsearch基于Lucene构建，写入文档时会生成多个小的不可变索引段（Segment），这些小段会占用额外磁盘空间；
• 后台进程会定期将多个小段合并为大段，合并过程中会清理标记为删除的文档、去重，合并完成后删除旧的小段，因此索引体积会突然缩小；
• 合并操作仅清理无效数据，不会删除未标记删除的旧文档，所以你仍能查询到多日前的内容。

2. Elasticsearch如何存储文档？ #

Elasticsearch的文档存储基于Lucene的倒排索引机制，核心流程如下：

• 写入阶段：文档先写入内存缓冲区，同时写入事务日志（Translog）保证数据不丢失；默认每隔1秒（可通过refresh_interval配置）会将缓冲区内容刷新到磁盘，生成新的不可变段（Segment），此时文档可被查询；
• 段管理：段一旦生成就不可修改，删除/更新文档时仅在对应段中标记文档为“已删除”，不会立即物理删除；后台段合并进程会定期将多个小段合并为大段，合并时彻底清理标记删除的文档，释放磁盘空间；
• 分片与副本：一个索引会拆分为多个分片（Shard），每个分片是独立的Lucene索引，存储索引的部分数据；副本分片是主分片的备份，用于故障恢复和负载均衡，存储结构与主分片一致。

3. 关于部分索引规模远超其他索引的问题 #

部分索引体积是其他索引的2倍，可能的原因包括：

• 这些索引的单文档平均体积更大（比如包含更多字段、更长文本或二进制数据）；
• 文档更新/删除频率更高，导致段中存在大量标记删除的文档，合并前占用额外空间；
• 分片设置不合理，比如分片数量过少，单个分片体积过大；
• 写入模式差异，比如批量写入的大小、频率不同，影响段的生成与合并效率。

内容的提问来源于stack exchange，提问作者marytlf