讲个真实发生的存储账本。我把一组业务日志索引原样迁移到 Elasticsearch 9.5，重建索引后主分片加副本的整体占用，从 22.61GB 掉到了 15.63GB。差不多省出三分之一的硬盘空间，约等于 7GB。对单机日志场景，省下的空间还能再撑一轮日志周期。省空间的思路，不是靠删数据，而是混合存储 —— 把热数据留在本地高速存储，把冷数据按策略迁到低成本层级，再配合编码压缩的合理配置。这篇文章我会把 ELasticsearch 9.5 里这套玩法完整拆开，讲清楚为什么日志数据库的存储会比你想的更费钱，以及怎么用混合存储把它重新梳理一遍。
日志场景是 ELasticsearch 用得最泛的方向，ELK/EFK 已经成为很多公司查日志默认组合。可越用越会发现，日志不是写进来就完事，真正让人头疼的是存储成本。ELasticsearch 9.5 里分层存储已经比较成熟，很多人在网上搜安装方法、搜组合方案，但对混合存储能省多少、怎么省、配置在哪动手，大多没有一个完整的操作视图。这篇按我的实测路径来讲，适合刚上手 ELasticsearch 的新手，也适合已经跑在 8.x、9.x 上但存储水位天天报警的运维。
1. 日志数据库的存储账本：为什么 ES 吃硬盘这么狠
1.1 日志场景的三个存储杀手
日志类数据在 ELasticsearch 里的存储开销，比多数人预想的更复杂。就拿一条 Nginx 访问日志来说，原始文本可能只有三四百字节，但进入 ES 后会被解析成 JSON 文档，默认情况下会保留一份完整的_source原文，然后是倒排索引、列存 doc_values、分词后的词项字典，再加上副本分片。四五份数据一起写进磁盘，一条原始日志在物理存储上被放大四到六倍是很正常的事。这就是第一个存储杀手：写入放大。
第二个是副本。很多人建索引图省事，默认number_of_replicas为 1，每个主分片带一个副本。如果主分片数量又多，副本数量就跟着翻倍。集群高可用当然需要副本，但日志这种海量写入且容忍一定丢失的数据，不能跟订单表同样对待。我在本地测试环境用三主一副的配置跑了一个月日志，副本占掉的磁盘几乎跟主分片一样多，这还只是单节点上的测试。
第三个是热数据存储的奢靡。把平时根本不会有人查的三四个月前的日志，跟当天的日志放在同一套高速存储上，这在成本上是纯粹的浪费。很多人没意识到，ELasticsearch 的索引并不会因为一直放着不动就变小，相反，它会在后台做 merge，把 segment 合并成大块，占用空间还会出现峰值。如果一开始没有规划滚动策略和冷热迁移，索引就一直躺在原路径里，磁盘只会越来越紧。
1.2 22.61GB 和 15.63GB 是怎么来的
我的测试数据是一个电商系统的后台日志集合，包含应用日志、接口访问日志、部分慢查询日志，时间跨度大约三十天。数据来源是几个微服务通过 Filebeat 写入的，索引按天滚动，每天一个索引，主分片设置为 3，副本为 1。
迁移前三天的索引总占用量刚好是 22.61GB。这说明什么？说明如果只是按默认方式一路写下去，这批日志占用的空间基本就是这个量级。调整之后，我对索引模板重做了配置，应用 ILM 生命周期策略，将超过三天的数据迁移到冷热分层架构中的冷层，同时改用了best_compression压缩编码，并在部分索引上启用了synthetic _source。三天后重新统计，整个索引集合的总占用降到了 15.63GB。省出来的空间大概 31%，实际效果非常直观。
这个数字不是夸张的实验室数据。混合存储里最关键的一步，是把不常用的索引迁移到冷节点或可搜索快照，冷层的存储成本低，再加上压缩对日志文本的高效削减，最终叠加出接近三分之一的空间节省。弄清楚这个逻辑，后面的配置才有意义。
2. 混合存储的底层逻辑：分层不是压缩那么简单
2.1 数据热度分级与 tier 架构
很多人一听到"混合存储"就觉得是要买新的存储设备，其实在 ELasticsearch 9.5 里，它是一个节点角色和数据分层概念。数据热度被拆成几个层级：hot 层、warm 层、cold 层，以及 frozen 层。每个层级的物理存储介质、容量和性能诉求都不同。
- hot 层：一般用本地 SSD，承载最新写入和频繁查询的数据，对 IOPS 和延迟要求最高。
- warm 层：通常是普通 SSD 或高速 HDD，承载几天到几周内的数据，查询频率明显下降。
- cold 层：普通 HDD 或低成本存储，承载几周到几个月的数据，极少查询但偶尔需要回溯。
- frozen 层：ELasticsearch 9.x 推出的可搜索快照，可以理解成把索引打包成快照存到对象存储，查询时按需加载，几乎不占用集群本地磁盘。
这个体系的本质是把数据按访问热度分开放，热度高的用贵的高速盘，热度低的用便宜的大容量盘，热点迁移完全由 ILM 自动完成。如果我一开始就把全量日志塞在本地 SSD 上，那么 22.61GB 这个数字就是纯 SSD 成本；但混合存储之后，只有最近三天的日志落在 SSD 上，更早的数据全部迁到低成本冷层，存储单价直接降了一个量级。
2.2 从 SSD 到对象存储：可搜索快照的原理
ES 9.x 里的 frozen 层不是简单地把索引关掉，而是用searchable snapshots实现只读索引的快照化。快照本身存放在远程仓库，比如对象存储、S3 兼容存储、共享文件系统。快照化的索引在本地不保留完整的 Lucene 文件，只保留一部分元数据，搜索的时候按需拉取数据块。
这个过程在架构上很好理解：索引的每个 segment 实际上是一个个 Lucene 文件，可搜索快照会把 segment 文件打包到仓库，本地留着少量缓存和元数据。当有 query 命中，ES 会从仓库拉取对应 segment 的数据块到本地缓存并执行搜索。靠这个机制，一个 TB 级日志索引可以做到只在本地占用很小一部分磁盘，大量数据沉到对象存储里。
在 Windows 单机环境里，可以把远程仓库指到一块独立的机械硬盘或者 NAS 挂载目录，效果等同于把冷数据"移出去"。我的实测里，七天前的日志索引迁移到 cold 层后，本地磁盘占用立刻少了很多，而查询还是可用的，只是首次查询会有几秒的加载延迟，完全在可接受范围内。
2.3 压缩编码与 _source 的取舍
混合存储能在容量上产生这么大的变化，除了分层迁移，还有一个隐藏功臣是压缩编码。ES 默认的index.codec是default，压缩速度和压缩比偏均衡。如果改成best_compression，Lucene 会改用压缩率更高的算法处理存储文件。日志文本通常有大量重复模式，比如时间戳前缀、固定格式的 URL、状态码，压缩收益非常明显。
另一个关键点是_source字段。ES 默认会把整个 JSON 原文存在_source里，方便后续 update 和重放索引。但对日志数据来说，_source的存在主要就是为了查看原始日志内容。如果日志里有大量打点数据、调试信息，_source会膨胀得很快。9.x 提供了index.mapping.source.mode: synthetic，可以生成合成形式的_source，按字段倒排后重新组合，而不是完整保存原始 JSON，在多数只读日志场景下能省下大量空间。
这里要提醒一件事：开启synthetic _source有前提条件。索引里如果包含text类型的字段且没有 fielddata，或者存在某些多字段聚合配置，就无法使用合成模式。我的处理方式是在索引模板层面对日志索引单独开启，并且提前把不需要参与 doc_values 的字段做映射优化。
3. 实操：在 Windows 上配出"省一半硬盘"的 ES 9.5
3.1 Windows 安装与日志目录规划
先解决怎么把 ES 9.5 跑起来的问题。很多人卡在 Windows 安装这一步，其实比想象中简单。ES 9.5 的 Windows 发行版是 zip 包，下载后直接解压到指定目录，比如D:\elasticsearch-9.5.3。官方要求环境里有 JDK，ES 9.x 内置了捆绑的 OpenJDK，如果没有特殊需要，直接用自带的 JDK 就能跑，这点对新手非常友好。
解压后在命令行进入 bin 目录，执行elasticsearch.bat。这时如果直接启动，会提示一些初始化配置问题，比如xpack.security.enabled需要显式设置，以及单节点模式需要指定discovery.type。我用的是最小化配置，config/elasticsearch.yml里写这几项：
cluster.name: log-cluster node.name: log-node-1 path.data: D:/es-data path.logs: D:/es-logs discovery.type: single-node xpack.security.enabled: false日志目录值得单独说一下。数据库场景里，日志目录结构化很重要，我习惯把业务日志输出到统一目录，比如D:/app-logs，下面按 service 和日期分子目录；ES 自己的数据日志放在path.data和path.logs指定的路径，两者混在一起会非常痛苦。
启动完成后，访问http://localhost:9200，能看到集群基本信息。ES 从 9.x 开始在浏览器里提供了更友好的内置控制台入口，也可以装 Kibana，但本地测试用自带的查询接口就够了。这一步踩过的坑是防火墙，Windows 下如果浏览器访问不了 9200，先检查 Windows 防火墙有没有放行对应端口。
3.2 索引模板与 ILM 策略配置实录
ES 运行起来之后，混合存储的第二步就是配置生命周期策略。我用的是一套按天滚动日志的模板加 ILM 策略，这里把完整的配置贴出来。
先创建 ILM 策略，主要动作是 hot 阶段保留 3 天，达到条件后滚动到 warm 或 cold 阶段：
PUT _ilm/policy/log_archive_policy { "policy": { "phases": { "hot": { "min_age": "0ms", "actions": { "rollover": { "max_primary_shard_size": "5gb", "max_age": "1d" } } }, "warm": { "min_age": "2d", "actions": { "allocate": { "number_of_replicas": 1 } } }, "cold": { "min_age": "3d", "actions": { "searchable_snapshot": { "snapshot_repository": "cold_repo" } } } } } }策略里rollover按分片大小和天数双条件触发。searchable_snapshot动作会把这个阶段的数据转成可搜索快照，并迁移到之前配好的快照仓库。没有配仓库会直接报错，后面我会讲怎么建仓库。
接下来设置索引模板，让所有eks-log-*索引都继承这套配置：
PUT _index_template/eks_log_template { "index_patterns": ["eks-log-*"], "template": { "settings": { "number_of_shards": 3, "number_of_replicas": 1, "index.codec": "best_compression", "index.mapping.source.mode": "synthetic", "index.lifecycle.name": "log_archive_policy", "index.routing.allocation.require._tier": "data_hot" } } }两个地方容易出问题。一个是index.mapping.source.mode如果和某些字段类型冲突，索引会创建失败；另一个是index.routing.allocation.require._tier指定了数据层，如果集群里没有对应 node 角色，索引会一直停留在 yellow 状态。我本地就是单节点，给节点配置里同时加了data_hot、data_warm、data_cold角色，确保迁移自动执行。
3.3 验证效果：从 22.61GB 到 15.63GB 的关键开关
配置完成后，如何确认那些容量变化是真实发生的？第一步，用_cat/indices查看索引详细信息，尤其关注 store 大小和 pri.store.size：
GET _cat/indices/eks-log-*?v&s=index&h=index,pri,store.size,pri.store.size迁移前我看到每个三主一副的索引总 store 大约在 800MB 左右，三十天累积到 22.61GB。迁移后同样的索引列表里，老索引的 store 明显下降，因为 cold 阶段已经用可搜索快照替换了本地 Lucene 文件，本地保留的只有少量缓存。
第二步，确认 ILM 是否真的把索引迁到了 cold 层。用 explain 接口最直观：
GET eks-log-2025.01.12/_ilm/explain返回结果里phase字段如果显示cold，说明策略生效。如果一直停在hot，最常见原因是快照仓库没配好，或者未满足 rollover 条件。
第三步，查看快照仓库的占用。如果配置了 cold 仓库，老索引的 segment 数据会出现在仓库里，本地的 store 自然瘦身。到这里，22.61GB 到 15.63GB 的变化就完全可复现、可追踪了。整个过程中，我被卡得最久的其实是best_compression对既有索引不生效的问题，因为压缩编码只能在索引创建时指定，老索引如果直接改 settings，会被拒绝。解决办法也简单：写成新的索引模板后，把旧索引 reindex 到新索引，或者用 ILM 的 rollover 自然滚动到新配置。
4. 常见问题与排查技巧实录
4.1 问题速查表
把这段时间实际操作中遇到的高频问题整理成一张表，方便排查：
| 现象 | 可能原因 | 处理方式 |
|---|---|---|
| 索引一直 yellow | 数据层角色不匹配 | 给节点加data_warm、data_cold角色后重启 |
| ILM 策略不生效 | 索引没有关联生命周期策略 | 在索引模板里配置index.lifecycle.name |
| 老索引改压缩配置失败 | 压缩编码只对新索引生效 | 用 rollover 或 reindex 生成新索引 |
| cold 阶段报错 | 快照仓库不存在 | 先建仓库，再配置 searchable snapshot |
| Windows 上无法访问 9200 | 防火墙未放行 | 检查防火墙入站规则，放行 9200 端口 |
| 存储占用不降反升 | 索引未迁移，仍在本地保留副本 | 观察 ILM explain 的 phase 是否为 cold |
| 查询冷索引首次很慢 | 可搜索快照需要按需加载 | 预留合理缓存，避免高频访问冷层 |
4.2 查看 tier 分配状态与水位线
集群里数据到底落在哪一层，用_cat/allocation一眼就能看出来。这个接口会列出每个节点的分片数量和磁盘占用情况。如果某个节点的磁盘使用率已经很高，超过cluster.routing.allocation.disk.watermark.low默认的 85%，ES 会停止往该节点分配新分片；超过 90% 的高水位线，ES 还会尝试把部分分片挪到其他节点。
日志场景下水位线问题特别容易踩。因为日志一天天涨，磁盘占用越来越多，一旦达到高水位线，ES 会把索引设置为只读，然后出现写入报错，很多人第一反应以为是自己代码出了问题，实际是磁盘不够了。我的建议是给日志集群预留一点冗余，同时把冷数据及时迁移到便宜存储。如果磁盘确实紧张，临时可以调高水位线，但一定要清楚这只是应急，不是根治。
排查时我常用的命令是：
GET _cluster/allocation/explain如果索引有分片没法分配，这个接口会直接给出原因，未分配的具体理由会被清楚地展示出来。
4.3 特别提醒 Windows 上的坑
Windows 上跑 ES 9.5，有几个容易踩的小细节。第一是路径不能有中文，path.data如果放在带中文的目录下，启动时大概率报错。第二是 JDK 版本。ES 9.x 对 JDK 版本有要求，如果系统环境变量里配了旧版 JDK，可能和 ES 内置的 JDK 冲突，稳妥做法是直接把JAVA_HOME指到 ES 安装目录下的jdk目录。
另一个很多人忽略的问题是 Windows 的计划任务或服务方式运行 ES。直接开命令行窗口启动，关掉窗口 ES 就停了，日志数据可能没 flush。我用的是 NSSM 把elasticsearch-service-x64.exe注册成系统服务，好处是开机自启，异常退出还能自动拉起。不过要留意，Windows 服务模式下 ES 的日志路径和工作目录跟手动启动会有些差别，设置的时候把path.logs写绝对路径最省心。
再说说浏览器控制台。ES 9.x 启动后，如果装了对应的插件，在http://localhost:9200/_plugin/之类路径可以打开简易控制台，适合快速做查询验证。Kibana 功能更全，但对单机日志环境来说偏重，而且自身也吃内存。测试机上我更喜欢直接用 curl 或者 Python 脚本调用 REST API，看数据更透明。
5. 最后再说几句私货
混合存储这套玩法折腾下来，我的体会是：日志数据库的存储，从来都不只是硬盘大小的问题，而是把"什么数据放在什么存储上"这个问题的工程化。ES 9.5 里 ILM、可搜索快照、分层节点、压缩编码这些功能单拆出来都不算新，但组合成一套自动执行的策略后，对整个日志系统的存储成本控制，效果是肉眼可见的。
另外，不要只盯着节省了多少 GB。从 22.61GB 到 15.63GB，节省的不只是硬盘容量，它意味着同等的存储预算下可以容纳更长的日志周期，意味着未来扩容的时间点可以往后推，也意味着构建日志数据库时不必一开始就堆大量的高速盘。对个人开发者来说，一台普通电脑就能跑通这件事；对团队来说，这套策略直接关系到日志平台的可持续性。
最后分享一个小技巧：给日志索引做混合存储规划的时候，先把"数据应该在哪一层"想清楚，再动手配置。很多配置问题表面上是参数错了，深层原因其实是没想清楚数据生命周期。我自己的默认格式是：当天和昨天的日志在 hot 层，一周内的在 warm 层，超过一周的进 cold 或 frozen。按这个思路，每天只要关注 ILM 状态，存储基本不用操心。这套办法，我现在每天都在用，目前磁盘水位一直很平稳。
