导读：从存算一体到存算分离，Elasticsearch 如何做到变更更快、迁移更稳、资源更省？本文解析阿里云 Elasticsearch 的存算分离与弹性架构，并以一个综合成本下降约 35% 的真实客户案例拆解计算、存储与弹性三重降本。
开篇：ES 集群最贵的时刻，往往不在高峰
一套 Elasticsearch 集群，什么时候最贵？
很多人首先想到的是业务高峰：写入攀升、查询打满，CPU 和磁盘 I/O 接近水位上限。但真正持续推高云上成本的，往往是高峰过后仍无法释放的资源。
-
为了承接短时高峰，计算资源长期按峰值预留；
-
Primary 和 Replica 各持完整的本地数据副本，副本越多，存储成本越高；
-
扩缩容、节点替换和故障恢复都要搬迁大量 Shard 文件、重新预热缓存，变更慢、风险高。
前两项直接增加账单；第三项则让团队不敢轻易缩容，冗余资源因此长期驻留。
这些问题的根源是同一个：数据与计算节点深度绑定。 节点既负责计算，也承载完整的 Shard 数据；数据越多，节点就越“重”。
阿里云 Elasticsearch 的存算分离与弹性架构正是为了打破这一约束。它用共享存储承载持久化数据，让计算资源随业务负载灵活伸缩，从而做到变更更快、迁移更稳、资源更省。
一、先让集群轻起来：存算分离，算力随需而动
要让资源随负载流动，先要让节点轻起来。阿里云 Elasticsearch 通过 OpenStore 解除数据与计算的绑定，再以共享计算资源池和弹性管控完成算力供给与容量调度。
OpenStore：让数据与计算解耦
写入侧，Primary 仍负责接收和处理写入。OpenStore 通过自研 Engine 重构索引构建与持久化流程，将 Translog 和索引文件直接写入共享存储，并通过精准的时序控制，确保已写入的数据持久、完整、可恢复。共享存储由此成为集群数据的 SSOT（Single Source of Truth），计算节点不再长期承载持久化状态。
存算分离并不改变 Elasticsearch 原有的 Primary / Replica 语义。OpenStore 通过物理复制同步索引数据及其可见性状态，使二者按照一致的可见性语义提供索引视图；故障切换时，Replica 仍可快速接替服务，业务无需改变原有使用方式。
查询侧，OpenStore 通过智能多级缓存将热点数据块保留在计算节点。命中时直接从本地读取，未命中时再从共享存储并行加载，既无需让完整数据长期驻留本地，又保留了热点访问效率。
共享计算资源池与弹性管控：让算力跟着业务变化
共享计算资源池屏蔽底层机型差异，对上提供统一算力，并为水平扩缩（调整节点数量）和垂直扩缩（调整计算规格）提供稳定的算力供给与库存保障。弹性管控会实时监测集群运行情况，根据弹性策略自动调整节点数量和规格，让集群资源更好地匹配业务负载。
当前已支持分时水平弹性，用户可按照业务周期预设策略，在高峰前增加资源、低峰时释放容量。基于 CPU 使用率的自动弹性即将上线，后续还将扩展更多负载指标。
由此，数据统一承载，算力按需调度。
二、变更更快：少构建，少搬迁
ES 集群变更，真正耗时的不是拉起一台新节点，而是让 Shard 在新节点上恢复到可服务状态。
传统存算一体 Elasticsearch 集群采用操作复制模式，Primary 和 Replica 都要执行写入，并分别构建 Lucene 索引。新的目标节点（Target）加入时，还要从源节点（Source）获取完整的 Shard 数据。Shard 越大、文件越多，恢复就越慢。
OpenStore 则通过重构索引构建与 Shard 恢复路径，让 Shard 大小不再主导恢复耗时。
一处构建，避免副本重复构建。 开启物理复制后，Primary 仍写索引文件和 Translog，Replica 不再构建索引。Primary 按需将增量索引文件同步给 Replica，同一份 Lucene 索引无需在每个副本上重复构建。
轻量恢复，避免完整搬迁。 Shard 迁移时，Target 直接加载共享存储中已持久化的索引状态，无需从 Source 复制完整数据；OpenStore还会并行加载文件元数据，进一步缩短就绪时间。
更快的关键，不是搬得更快，而是少构建、少搬迁。
实测：不同 Shard 大小的迁移耗时对比
在相同环境下，选取 5 GB、20 GB 和 200 GB 三种大小的 Shard，对比 OpenStore 迁移与 Elasticsearch 标准 Recovery（限速/不限速）的耗时：
| Shard 大小 | OpenStore 迁移 | 标准 Recovery（40 MB/s/节点） | 标准 Recovery（不限速） |
|---|---|---|---|
| 5 GB | 3.8 s | 133 s | 20.6 s |
| 20 GB | 4.9 s | 505 s | 82 s |
| 200 GB | 10.1 s | 5290 s | 1116 s |
以 200 GB Shard 为例，OpenStore 的迁移耗时为 10.1 秒，仅约为标准 Recovery（不限速）的 1/110。Shard 越大，优势越明显。
三、迁移更稳：PageReplay 定向预热，平稳承接流量
轻量迁移解决了“数据就绪”，却不等于“热点就绪”。新节点的本地缓存仍然是冷的，如果立即接入查询流量，首次访问可能回源共享存储，带来查询 RT 抖动。
为此，阿里云 Elasticsearch 研发了 PageReplay 热点预热机制。它不复制真实查询流量，而是以 Page 为粒度记录近期访问热度，在迁移收尾阶段筛选活跃热页，并在 Target 接流前定向加载到本地缓存。整个过程只预热近期热点，而非完整 Shard，在控制开销的同时降低冷启动带来的 RT 抖动。
实测：蓝绿变更时长与查询 RT
测试数据来自某检索业务，规模约 3 TB，包含 208 个业务索引和 3000+ Shard。在相同查询压力下，分别测试传统存算一体 Elasticsearch 集群、关闭 PageReplay 的 OpenStore 集群和开启 PageReplay 的同一 OpenStore 集群；三轮变更前的平均 RT 均处于约 10 ms 的同一量级。
| 核心指标 | 存算一体集群 | OpenStore（PageReplay 关闭） | OpenStore（PageReplay 开启） |
|---|---|---|---|
| 变更时长 | 95 分 52 秒 | 15 分 26 秒 | 17 分 41 秒 |
| Shard 迁移时长 | 82 分 02 秒 | 1 分 46 秒 | 3 分 29 秒 |
| 迁移过程中平均 RT | 104.35 ms | 42.66 ms | 20.86 ms |
| 迁移过程中 P99 RT | 1.34 s | 496.18 ms | 262.85 ms |
| 迁移过程中 P999 RT | 3.29 s | 1.34 s | 622.65 ms |
为便于比较，图中三轮曲线均以“节点全部加入”为 T0；表中耗时仍按各轮原始生命周期事件统计。
相比存算一体集群，OpenStore + PageReplay 将全流程变更时长缩短约 82%，Shard 迁移时长缩短约 96%；迁移过程中平均 RT 下降约 80%，P999 RT 下降约 81%。
在同一 OpenStore 集群上，开启 PageReplay 虽使整体变更多用约 2 分 15 秒，但迁移过程中的平均 RT、P99 RT 和 P999 RT 分别下降约 51%、47% 和 53%。这组对比拆开了两层收益：OpenStore 让迁移更快，PageReplay 用一段可控的预热时间，让接流更稳。
四、资源更省：计算、存储、弹性三重降本
OpenStore 的降本不是单点优化，而是对计算、存储和容量供给方式的系统重构。
计算降本：副本不再重复构建
“一处构建”也直接转化为计算收益。在相同写入压力下，Primary CPU 与存算一体集群基本持平，收益主要来自 Replica：1 Replica 时数据节点平均 CPU 相对下降约 35%，写入平均 RT 下降约 78%；2 Replica 时 CPU 相对下降约 47%，写入平均 RT 下降约 74%。
存储降本：本地盘只需覆盖热点
存算一体集群使用本地数据盘保存完整 Shard 数据。要缩减本地盘，不能只改变数据落点，还要保证小容量缓存下的查询效率。为此，OpenStore 同时重构写入和查询路径：写入侧，Translog 和索引文件绕过本地盘 I/O，直接写入共享存储；查询侧，智能多级缓存保留热点，并针对倒排索引、Doc Values、_source 等文件类型采用差异化的准入、预读和淘汰策略。
两条路径协同后，计算节点的本地盘从完整数据副本变为热点缓存。在典型检索场景中，本地缓存盘可以按照节点内存约 3 倍起配。
弹性降本：从固定容量到按需扩缩
对于峰谷明显的业务，可以按小时配置容量，在高峰前调高、低峰后调低。下图基于某已完成 OpenStore 迁移客户的典型日监控数据匿名化重绘：数据节点平均 CPU 在上午和下午形成双峰，容量按时段提前切换。按图中的相对成本模型计算，从全天峰值容量改为三档分时后，计算成本由 2400 降至 1800，下降约 25%。
客户案例：三笔收益叠加，综合成本下降约 35%
下面以同一客户迁移前后的真实资源配置为基础，统一按阿里云 Elasticsearch 华东 1 目录价测算月度成本。双方本地盘均按 PL1 计价，OpenStore 计算成本叠加上述三档分时模型。
| 资源项 | 存算一体 | OpenStore |
|---|---|---|
| 峰值数据节点 | 28 个 | 26 个 |
| 节点规格 | 32C 128 GB | 32C 128 GB |
| 单节点本地盘 | 3072 GB PL1 | 460 GB PL1 缓存盘 |
| 本地盘总量 | 约 84 TB | 约 11.7 TB |
| OpenStore 共享存储空间 | — | 21 TB |
| 容量策略 | 28 个节点全天运行 | 按业务峰谷分时伸缩 |
计算收益。 物理复制降低副本侧的重复构建开销，峰值数据节点从 28 个降至 26 个，先压低峰值计算基线。
存储收益。 迁移前，为容纳完整副本并预留安全空间，集群共配置约 84 TB 本地盘。迁移到 OpenStore 后，持久化数据由 21 TB 共享存储统一承载，计算节点仅保留约 11.7 TB 本地缓存，存储成本下降约 45%。
弹性收益。 在 26 个峰值数据节点的基础上，通过上图所示的三档分时释放低峰容量，弹性部分的计算成本下降约 25%。
目录价月成本对比
| 成本项 | 存算一体 | OpenStore + 分时弹性 |
|---|---|---|
| 数据节点计算 | 约 14.95 万元 | 约 10.41 万元 |
| 本地数据盘 | 约 8.60 万元 | — |
| 本地缓存盘 | — | 约 1.20 万元 |
| OpenStore 共享存储空间 | — | 约 3.51 万元 |
| 其他固定资源 | 约 0.35 万元 | 约 0.35 万元 |
| 总成本 | 约 23.90 万元 | 约 15.46 万元 |
三项收益叠加后，计算成本下降约 30%，存储成本下降约 45%；总成本从约 23.90 万元降至约 15.46 万元，综合下降约 35%。
以上不含商务折扣；实际价格以阿里云 Elasticsearch 售卖页为准。
五、面向未来：从资源弹性到 Agent Ready
分时弹性让资源随业务周期灵活伸缩。面向 RAG 与 Agent，算力将进一步从“按计划扩缩”走向“随负载而动”。
阿里云 Elasticsearch 将沿着三个方向继续演进：
-
从分时弹性到自动弹性。 弹性管控实时感知 CPU 等负载指标，自动调整节点数量和规格，让资源更贴近业务负载。
-
从资源供给到有效算力。 通过 Shard 热点均衡与参数自适应，动态调整 Shard、Replica 和线程池等配置，让资源从“分配到位”走向“算力到位”。
-
从读写混合到独立扩缩。 写入与查询算力按各自负载独立伸缩，高峰侧按需扩容，低峰侧及时释放。
从存算一体到存算分离，从固定资源到按需算力，OpenStore 正在推动 Elasticsearch 向 Agent Ready 搜索底座演进。数据常驻，算力流动；请求到来时按需供给，高峰过去后及时释放。
目前，阿里云 Elasticsearch 7.10、8.17 和 9.4 版本均已支持存算分离与分时弹性，欢迎前往阿里云控制台体验。其中，8.17 和 9.4 版本还可结合阿里云 Elasticsearch 云原生内核 FalconSeek，进一步降低约 30% 的查询侧 CPU 开销。更多原理与实测，敬请关注后续专题文章。
业务可以有高峰，但资源不必永远停在高峰。
附录：测试环境
| 项目 | OpenStore 集群 | 存算一体集群 |
|---|---|---|
| Elasticsearch 版本 | 8.17.0 | 8.17.0 |
| 数据节点 | 6 × 16C 64 GB | 6 × 16C 64 GB |
| Master 节点 | 3 × 4C 16 GB | 3 × 4C 16 GB |
| 数据盘 | 256 GB PL1 | 768 GB PL1 |
| DFS 共享存储 | 5120 GB | — |
两套集群使用相同计算规格，在相同写入压力下进行对比。蓝绿变更测试使用 3 TB 数据，包含 208 个业务索引、3000+ Shard。
相关链接
