【Elasticsearch】为什么文档删除后，索引存储空间有时反而增大

《文档 Document》系列，共包含以下文章：

• 文档（一）：新增 & 删除
• 文档（二）：更新
• 为什么批量写入（bulk）可以提高性能
• 为什么文档删除后，索引存储空间有时反而增大
• 更新文档，_source 字段必须为 true 吗
• 文档迁移（Reindex）

😊 如果您觉得这篇文章有用 ✔️ 的话，请给博主一个一键三连 🚀🚀🚀 吧 （点赞 🧡、关注 💛、收藏 💚）！！！您的支持 💖💖💖 将激励 🔥 博主输出更多优质内容！！！

在 Elasticsearch 中，删除文档后索引存储空间反而增大 的现象看似违反直觉，但实际上是由其底层存储机制和优化策略导致的。以下是可能的原因及详细解释：

1.逻辑删除机制（标记删除而非立即物理删除）

• 根本原因：Elasticsearch 使用 标记删除 机制。删除文档时，并不会立即从磁盘移除数据，而是：
  • 在 事务日志（Translog）中记录删除操作。
  • 在 Lucene 段（Segment）中将文档标记为 deleted，后续搜索时会过滤掉该文档。
• 空间变化：
  • 新增的 删除标记（Tombstone）会占用少量额外空间。
  • 原文档数据仍保留在磁盘上，直到触发 段合并（Segment Merge）。

示例：删除一个 1KB 的文档后，可能新增 0.1KB 的删除标记，导致总存储空间短暂增加。

2.段合并（Segment Merge）延迟

• Lucene 段结构
  • Elasticsearch 底层依赖 Lucene，数据存储在不可变的 段 中。删除文档后，新生成的段会包含删除标记，而旧段中的原始数据仍存在。
• 合并触发条件
  • 段合并会清理已删除的文档，但这是一个后台任务，默认由合并策略（如 TieredMergePolicy）控制，可能不会立即执行。
  • 在合并前，新旧段会 同时存在，导致存储空间暂时增加。

极端情况：如果频繁删除大量文档但未触发合并，空间可能显著膨胀。

3.索引刷新（Refresh）和事务日志（Translog）开销

• 刷新操作
  • 默认每秒刷新（Refresh）一次，生成新的可搜索段（包含删除标记）。
  • 短时间内的多次删除可能导致生成多个小段，增加元数据开销。
• Translog 增长
  • 每次删除都会记录到 Translog（用于故障恢复），直到 Translog 被清除（如执行 flush 或段合并）。

4.版本控制（Versioning）开销

Elasticsearch 会保留文档的版本号（_version），删除操作会增加版本号记录。如果频繁更新和删除同一文档，版本元数据可能累积。

5.集群状态和副本分片（Replicas）同步

删除操作需要同步到所有副本分片，副本分片可能因临时状态（如同步延迟）占用额外空间。

6.如何验证和解决？

6.1 检查已删除文档的存储状态

# 查看索引的存储详情（包括标记删除的文档）
GET /_cat/indices/users?v&h=index,docs.count,docs.deleted,store.size

• docs.deleted > 0 表示有待清理的文档。

6.2 手动触发段合并

# 强制合并段并清理已删除文档（谨慎使用，高IO操作）
POST /users/_forcemerge?only_expunge_deletes=true

• only_expunge_deletes=true 仅合并包含删除的段。

6.3 调整合并策略和刷新间隔

# 减少刷新频率（批量删除时临时调整）
PUT /users/_settings
{
  "index.refresh_interval": "30s"
}

6.4 监控 Translog 大小

# 查看 Translog 统计
GET /users/_stats/translog?human

返回示例：

{
  "_shards": { ... },
  "_all": {
    "primaries": {
      "translog": {
        "operations": 42,          // translog 中的操作数
        "size": "12.5kb",         // translog 大小（人类可读格式）
        "size_in_bytes": 12800,    // translog 大小（字节）
        "uncommitted_operations": 10,  // 未提交的操作数
        "uncommitted_size": "2.1kb",
        "uncommitted_size_in_bytes": 2150,
        "earliest_last_modified_age": 3600  // 最早未提交 translog 记录的年龄（秒）
      }
    },
    "total": { ... }  // 包含副本分片的 translog 信息（如果有）
  }
}

• operations：当前 translog 中的操作数量（如新增、更新、删除）。
• size / size_in_bytes：translog 占用的磁盘空间。
• uncommitted_operations：尚未刷盘（flush）的操作数。
• earliest_last_modified_age：最旧的 translog 记录的存活时间（秒），可用于监控 translog 积压情况。

执行 flush 清理 Translog。刷新操作会将内存中的数据（包括 Translog）写入磁盘，然后生成新的 Translog。

POST /users/_flush

7.总结：为什么删除后空间可能增加？

阶段	存储影响	解决方案
标记删除	新增 Tombstone 记录	等待段合并或手动 forcemerge
未合并的旧段	原文档仍占用空间	优化合并策略
Translog 累积	删除操作日志临时增长	定期 flush
副本同步延迟	副本分片可能暂存冗余数据	检查集群健康状态

8.最佳实践

• 批量删除后主动触发 _forcemerge（避开业务高峰）。
• 定期监控 docs.deleted 比例，超过 $10\%$ 时考虑优化。