日志存储介质选型应按热、温、冷三层数据特性匹配：热数据用NVMe SSD保障毫秒响应；温数据用SATA HDD+ZSTD压缩降本；冷数据归档至S3兼容对象存储并转列存格式；深度归档适用于合规场景。
日志存储的介质选型，核心不是“挑最快的”或“挑最便宜的”，而是按数据访问频率和业务要求，把每类数据放到成本效益最高的地方。热数据要快，冷数据要省，温数据求平衡——选型逻辑就藏在这三层节奏里。
热数据：SSD 是当前最务实的选择
最近 1–7 天的日志属于热数据，写入密集、查询高频（如告警、实时排查），必须保障毫秒级响应。NVMe SSD 是首选，SATA SSD 可作为次选，但要注意：
- 避免混用不同型号/寿命的 SSD，否则 ILM 自动迁移时容易触发节点失衡
- ES 热节点建议单节点配 2–4 块 NVMe 盘，RAID 0 或 JBOD 模式，不建议 RAID 5/6（写放大+重建风险）
- 若用云厂商托管 ES（如 OpenSearch），直接选用 io2 或 gp3 类型卷，注意开启 EBS 优化与多队列支持
温数据：HDD + 合理压缩，性价比突出
7–30 天的数据查询变少，但仍有聚合分析、周期性巡检等需求。此时 SATA HDD（如 16TB+ 容量盘）搭配高压缩比格式，单位成本可压到 SSD 的 1/5 以下：
- ES warm 节点建议关闭副本（设置 number_of_replicas: 0），靠跨机架/可用区部署保障容错
- 使用 best_compression 编码 + zstd 压缩（ES 8.10+ 默认），实测日志压缩比可达 3.5:1～4:1
- 避免在 warm 层启用 fielddata 或大量 keyword 字段，防止 heap 溢出
冷数据：对象存储（OSS/S3）是降本关键突破口
30 天以上的日志，95% 场景下全年查询不超过 10 次。继续留在 ES 集群里，等于用 ¥1.8/GB·月的价格存 ¥0.03/GB·月的数据。对象存储是更自然的归宿：
- 优先选兼容 S3 API 的对象存储（阿里云 OSS、腾讯云 COS、MinIO 自建），便于 ILM 快照策略复用
- 冷数据建议转为列存格式再归档：Parquet（带 ZSTD 压缩）或 ORC，比原始 JSON 日志再省 40%～60% 空间
- ES ILM 不宜直接挂载对象存储，推荐用 Snapshot Repository + 自定义脚本 实现“索引冻结→快照→删除本地分片→保留元数据指向快照”的闭环
归档层：Glacier / 归档存储适合合规强约束场景
金融、医疗等行业要求 7 年以上留存，且允许小时级取回延迟，这时可启用深度归档：
- 阿里云归档存储、AWS Glacier Deep Archive 单价低至 ¥0.003/GB·月，比标准 OSS 便宜 80%+
- 注意：归档数据需先“解冻”才能读，一次解冻有效期最长 12 小时，不适合偶发查询，仅适用于审计抽查、司法调证等明确触发场景
- 建议对归档索引做统一元数据登记（如用 MySQL 记录 index_name + snapshot_id + 存储位置 + 解冻状态），避免“有库无据”
