相同数据与文档数的Elasticsearch集群索引大小差异问题咨询

你观察到的集群索引大小差异90%的核心原因是Lucene的软删除机制，结合两套集群的段合并触发状态不一致导致：

• Elasticsearch的删除/更新操作不会立即物理清理旧数据，只会给对应文档打上删除标记，这类标记为删除的文档只有在所属段触发合并时才会被真正清理释放空间。
• 你提供的索引状态显示，该索引删除文档数达到1882万，是存活文档数（891万）的2倍以上，大量未清理的软删除文档占用了绝大多数存储空间。
• 两套集群的写入压力、段合并触发时机不同，其中一套集群已经自动触发过段合并清理了大部分软删除文档，另一套未达到合并触发阈值，所以会出现配置、存活文档数完全一致但索引大小差异极大的情况。

你执行段合并操作反而触发磁盘耗尽、分片分配失败的原因如下：

• 无论是自动合并还是手动调用强制merge API，段合并过程都需要额外的临时磁盘空间：需要先读取所有待合并的旧段，写入生成新的合并后段，再删除旧段，整个过程需要的临时空间最高可达待合并段总大小的2倍。
• 你执行merge时磁盘剩余空间已经不足以支撑合并过程的临时开销，合并过程中临时文件占用了剩余磁盘空间，最终触发Lucene提交失败、磁盘无空间的IO异常，导致分片分配失败。
• 你配置了单节点分片上限为2，该索引主分片数为6、副本数为1，总共需要12个分片位置，若集群节点数不足也会进一步加剧分片分配异常的问题。

临时清理方案 #

你已经扩容了EBS卷，后续可以在业务低峰期执行以下命令仅清理带删除文档的段，相比全量强制merge占用的临时空间小很多：

POST /local-deals-1624295772015/_forcemerge?only_expunge_deletes=true

长期优化方案 #

• 调整段合并清理阈值：将索引参数index.merge.policy.expunge_deletes_allowed从默认的10%适当调小（比如调整为5%），让软删除文档的清理更及时，避免长期累积占用空间。
• 若你的业务为周期性写入的时序类/离线类数据，建议使用索引别名 + 滚动索引的模式，老索引写入完成后直接执行强制merge为只读状态，既节省空间也能提升查询性能。
• 评估分片配置合理性：你当前配置单节点分片上限为2，需对应调整集群节点数或索引分片数，保证分片能够正常分配。

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