Elasticsearch 的 ILM 是什么？冷热数据和 rollover 怎么设计？

简化版

ILM 是 Index Lifecycle Management，用来按策略自动管理索引生命周期，例如热阶段写入、温阶段降成本、冷阶段低频查询、删除阶段清理过期数据。rollover 用来在索引达到大小、文档数或时间条件后切到新索引，避免单个索引或分片无限膨胀。

详细版

ILM 常用于日志、监控、订单流水、行为事件等时间序列数据。它解决的问题是：数据会不断写入，但不同年龄的数据访问频率不同。

常见生命周期：

hot：最新数据，写入频繁，查询频繁，放在性能更好的节点。
warm：不再写入，查询变少，可以迁移到成本较低节点。
cold：偶尔查询，更强调低成本保存。
frozen：更低频访问，通常牺牲部分查询性能换成本。
delete：超过保留期后删除。

rollover 解决“当前写入索引何时切换”的问题。常见条件：

索引达到指定大小；
主分片达到指定大小；
文档数达到阈值；
索引年龄达到阈值。

生产设计重点不是把所有阶段都用上，而是根据数据访问模式、保留周期、磁盘成本和查询要求选择合适策略。

完整版教学

一、为什么需要 ILM

日志类索引最典型：

今天的日志：写入多、查询多、排障经常看
7 天前日志：偶尔查
90 天前日志：基本不查，但合规要求保留
180 天前日志：可以删除

如果所有数据都放在同一类高性能节点上，成本会很高；如果一直往同一个索引写，单个索引和分片会越来越大，恢复、迁移、查询都变慢。

ILM 的价值就是让索引随着年龄和大小自动流转，减少人工运维。

二、hot、warm、cold、delete 怎么理解

可以把数据生命周期想成仓库分层：

阶段	数据特点	典型动作
hot	新数据，持续写入，频繁查询	rollover、保留在高性能节点
warm	旧一些，不再写入，查询下降	shrink、forcemerge、迁移节点
cold	更旧，低频查询	放到低成本存储或节点
frozen	极低频访问	进一步降低成本
delete	超过保留期	删除索引

不是所有业务都必须配置每个阶段。小系统可能只需要 hot + delete；大规模日志平台才更需要完整冷热分层。

三、rollover 解决什么问题

rollover 的目标是控制写入索引规模。比如不要让 logs 永远写到一个索引里，而是写到一个别名或 data stream 背后的当前索引：

logs-000001 -> 达到 50GB -> rollover
logs-000002 -> 继续写入
logs-000003 -> 继续写入

常见 rollover 条件：

"rollover": {
  "max_primary_shard_size": "50gb",
  "max_age": "7d"
}

这样可以让单个主分片保持在可管理范围内，避免恢复和迁移过慢。

四、ILM 策略大致怎么配置

一个简化策略：

PUT _ilm/policy/logs_policy
{
  "policy": {
    "phases": {
      "hot": {
        "actions": {
          "rollover": {
            "max_primary_shard_size": "50gb",
            "max_age": "7d"
          }
        }
      },
      "delete": {
        "min_age": "30d",
        "actions": {
          "delete": {}
        }
      }
    }
  }
}

真实生产还要配合 index template、data stream 或写入 alias，让新创建的 backing index 自动继承 mapping、settings 和 ILM policy。

五、设计 ILM 时最容易忽略什么

几个关键点：

按主分片大小规划，不只是按索引总大小看。
rollover 条件要结合写入速度，避免一天生成过多小索引。
mapping 和 template 要稳定，否则不同代索引字段类型不一致会影响查询。
delete 阶段要和业务保留周期、合规要求对齐。
冷热节点不是魔法，查询旧数据依然要付出 IO 和延迟成本。
如果使用 data stream，要理解写入只进入当前 write index。

六、常见误区与追问

设计问题	不合理做法	更稳的做法
单索引无限写入	`logs` 永远一个索引	data stream 或写别名 + rollover
只看索引总大小	3 个主分片总共 150GB 就认为合适	关注单个 primary shard 大小，比如每片约 50GB
所有数据都放热节点	180 天日志都占高性能盘	按访问频率进入 warm/cold/delete
delete 随便配	只按技术成本删	对齐合规、审计、业务保留周期

日写入 300GB，6 个 primary shard
如果 rollover 条件是 max_primary_shard_size=50GB
理论上大约 1 天滚动一次，单片规模可控。

记忆钩子：ILM 管“数据年龄”，rollover 管“写入边界”，冷热分层管“钱花在哪里”。

面试时可以用日志平台举例：最近 3 天排障最频繁，留在 hot；4 到 30 天偶尔查，进 warm；30 到 180 天只是合规留存，进 cold；超过 180 天 delete。这个例子能说明你不是只背 phase 名词，而是知道生命周期来自访问频率和成本模型。

误区：ILM 就是定时删除旧索引。 删除只是一个 phase，ILM 还包括 rollover、迁移、shrink、forcemerge 等生命周期动作。
误区：rollover 只按日期切就够了。 写入量波动大时，单纯按天可能产生过大或过小索引，常要结合主分片大小、文档数和年龄。
误区：冷热分层一定能让旧查询很快。 冷数据强调低成本保存，查询延迟通常会变高，不能把它当性能优化手段。
追问：为什么推荐关注 primary shard size？ 副本会放大总大小，但真正影响单分片恢复、迁移和查询负载的是每个主分片承载的数据规模。
追问：ILM 为什么要配合 template 或 data stream？ 新生成的 backing index 需要自动继承 mapping、settings 和 lifecycle policy，否则 rollover 后新索引可能配置不一致。
追问：rollover 后旧索引还会写入吗？ 使用 data stream 或写别名时，写入会进入新的 write index，旧索引一般转入后续生命周期阶段。

七、加强记忆

记住“ILM 管生命周期，rollover 管切新索引，冷热分层管成本”。时间序列数据不要让一个索引无限长大，要用模板、data stream 或写入别名配合 ILM，让数据按大小、时间和访问频率自动流转。

简化版

详细版