ElasticSearch 冷热分离
冷热分离 是 ES 针对“不同生命周期的数据”在 “不同性能、不同成本的节点” 上存储和查询的架构设计。
核心目的只有两个：
- 提高性能（热数据放在高性能节点）
- 降低成本（冷数据放在低成本节点）
ES 是分布式搜索数据库：
- 写入成本由 CPU、SSD、内存、IOPS 决定
- 搜索成本由 CPU、内存、缓存、SSD 决定
随着时间推移：
| 数据类型 | 查询频率 | 写入频率 | 性能要求 | 成本 |
|---|---|---|---|---|
| 热数据 | 高 | 高频写 | 强性能 | 高 |
| 温数据 | 中 | 无写 | 中 | 中 |
| 冷数据 | 低 | 无写 | 低 | 低 |
| 冻结数据 | 几乎无查询 | 无写 | 最低 | 最低（对象存储） |
👉 所以集群通常按 Hot -> Warm -> Cold -> Frozen 分层。
用于：
- 高并发写入（logstash、beats、ingest pipeline）
- 高频搜索
- indexing、refresh、merge 操作
节点特征：
- 🔥 高 CPU
- 🔥 大内存
- 🔥 SSD（NVMe 最佳）
- 🔥 较少 shard 数量
用于：
- 已写入完成的数据
- 查询较少，但偶尔会查询
节点特征：
- 中等 CPU
- 普通 SSD 或 SATA SSD
- 更多磁盘容量
用于：
- 基本不会查询的历史数据
- 只在偶尔需要归档查询时访问
节点特征：
- 机械硬盘（HDD）
- 较少 CPU/内存
- 大容量磁盘（例如 8TB/12TB）
用于：
- 几乎永远不查，但需要保留（法规/审计）
- 数据存放在对象存储：
- S3
- MinIO
- OSS
好处：
- 成本最低
- ES 通过 searchable snapshot 方式访问
ES 使用 节点角色（Node Roles） + ILM（Index Lifecycle Management） 来实现。
在 elasticsearch.yml 中添加：
🔥 热节点
node.roles: ["data_hot", "ingest"]
🟡 温节点
node.roles: ["data_warm"]
🧊 冷节点
node.roles: ["data_cold"]
❄️ 冻结节点
node.roles: ["data_frozen"]
一个典型的生命周期如下：
Hot（7 天）-> Warm（30 天）-> Cold（180 天）-> Frozen（1 年）-> Delete（1 年+）
示例：
PUT _ilm/policy/logs_policy
{
"policy": {
"phases": {
"hot": {
"actions": {
"rollover": {
"max_size": "30gb",
"max_age": "7d"
}
}
},
"warm": {
"actions": {
"allocate": {
"include": { "data": "warm" }
},
"shrink": { "number_of_shards": 1 },
"forcemerge": { "max_num_segments": 1 }
}
},
"cold": {
"actions": {
"allocate": {
"include": { "data": "cold" }
}
}
},
"frozen": {
"actions": {
"searchable_snapshot": {
"snapshot_repository": "s3_repo"
}
}
},
"delete": {
"actions": {
"delete": {}
}
}
}
}
}
🔥 Hot
┌────────────────────────┐
NVMe SSD / 强 CPU
写入 + 高频搜索
└──────────┬─────────────┘
↓ rollover
┌────────────────────────┐
Warm（SSD）
偶尔查询，低写入
└──────────┬─────────────┘
↓ move
┌────────────────────────┐
Cold（HDD 大容量）
偶尔归档查询
└──────────┬─────────────┘
↓ snapshot
┌────────────────────────┐
│ Frozen（S3 / MinIO） │
│ 最低成本，几乎不查 │
└────────────────────────┘
否则写入和 refresh 会非常慢。
推荐：
- 1 个 primary（日志类）
- 副本数 1
- rollover 控制 shard 大小 ≤ 30GB（最佳）
避免 segment 太多导致查询变慢。
效率会下降，但历史查询可接受。
非常适合长期归档。
| 问题 | 原因 | 解决 |
|---|---|---|
| shard 在热、暖节点乱跑 | 没设置 node roles 或 ILM | 配置 allocate |
| 索引没有自动 rollover | 没绑定 ILM | 设置 index template |
| Warm 节点查询慢 | segment 多 | force_merge |
| Cold 节点压力大 | 查询太多 | 增加 warm 节点或缩短 warm 时间 |
| Frozen 索引打开特别慢 | S3 拉数据 | 合理设置 retention |