导读：从存算一体到存算分离，Elasticsearch如何做到变更更快、迁移更稳、资源更省？本文解析阿里云Elasticsearch的存算分离与弹性架构，并以一个综合成本下降约35%的真实客户案例拆解计算、存储与弹性三重降本。

开篇：ES集群最贵的时刻，往往不在高峰

一套Elasticsearch集群，什么时候最贵？

很多人首先想到的是业务高峰：写入攀升、查询打满，CPU和磁盘I/O接近水位上限。但真正持续推高云上成本的，往往是高峰过后仍无法释放的资源。

• 为了承接短时高峰，计算资源长期按峰值预留；

• Primary和Replica各持完整的本地数据副本，副本越多，存储成本越高；

• 扩缩容、节点替换和故障恢复都要搬迁大量Shard文件、重新预热缓存，变更慢、风险高。

前两项直接增加账单；第三项则让团队不敢轻易缩容，冗余资源因此长期驻留。

这些问题的根源是同一个：数据与计算节点深度绑定。节点既负责计算，也承载完整的Shard数据；数据越多，节点就越“重”。

阿里云Elasticsearch的存算分离与弹性架构正是为了打破这一约束。它用共享存储承载持久化数据，让计算资源随业务负载灵活伸缩，从而做到变更更快、迁移更稳、资源更省。

一、先让集群轻起来：存算分离，算力随需而动

要让资源随负载流动，先要让节点轻起来。阿里云Elasticsearch通过OpenStore解除数据与计算的绑定，再以共享计算资源池和弹性管控完成算力供给与容量调度。

OpenStore：让数据与计算解耦

写入侧，Primary仍负责接收和处理写入。OpenStore通过自研Engine重构索引构建与持久化流程，将Translog和索引文件直接写入共享存储，并通过精准的时序控制，确保已写入的数据持久、完整、可恢复。共享存储由此成为集群数据的SSOT（SingleSourceofTruth），计算节点不再长期承载持久化状态。

存算分离并不改变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大小的迁移耗时对比

在相同环境下，选取5GB、20GB和200GB三种大小的Shard，对比OpenStore迁移与Elasticsearch标准Recovery（限速/不限速）的耗时：

Shard大小	OpenStore迁移	标准Recovery（40MB/s/节点）	标准Recovery（不限速）
5GB	3.8s	133s	20.6s
20GB	4.9s	505s	82s
200GB	10.1s	5290s	1116s

以200GBShard为例，OpenStore的迁移耗时为10.1秒，仅约为标准Recovery（不限速）的1/110。Shard越大，优势越明显。

三、迁移更稳：PageReplay定向预热，平稳承接流量

轻量迁移解决了“数据就绪”，却不等于“热点就绪”。新节点的本地缓存仍然是冷的，如果立即接入查询流量，首次访问可能回源共享存储，带来查询RT抖动。

为此，阿里云Elasticsearch研发了PageReplay热点预热机制。它不复制真实查询流量，而是以Page为粒度记录近期访问热度，在迁移收尾阶段筛选活跃热页，并在Target接流前定向加载到本地缓存。整个过程只预热近期热点，而非完整Shard，在控制开销的同时降低冷启动带来的RT抖动。

实测：蓝绿变更时长与查询RT

测试数据来自某检索业务，规模约3TB，包含208个业务索引和3000+Shard。在相同查询压力下，分别测试传统存算一体Elasticsearch集群、关闭PageReplay的OpenStore集群和开启PageReplay的同一OpenStore集群；三轮变更前的平均RT均处于约10ms的同一量级。

核心指标	存算一体集群	OpenStore（PageReplay关闭）	OpenStore（PageReplay开启）
变更时长	95分52秒	15分26秒	17分41秒
Shard迁移时长	82分02秒	1分46秒	3分29秒
迁移过程中平均RT	104.35ms	42.66ms	20.86ms
迁移过程中P99RT	1.34s	496.18ms	262.85ms
迁移过程中P999RT	3.29s	1.34s	622.65ms

为便于比较，图中三轮曲线均以“节点全部加入”为T0；表中耗时仍按各轮原始生命周期事件统计。

相比存算一体集群，OpenStore+PageReplay将全流程变更时长缩短约82%，Shard迁移时长缩短约96%；迁移过程中平均RT下降约80%，P999RT下降约81%。

在同一OpenStore集群上，开启PageReplay虽使整体变更多用约2分15秒，但迁移过程中的平均RT、P99RT和P999RT分别下降约51%、47%和53%。这组对比拆开了两层收益：OpenStore让迁移更快，PageReplay用一段可控的预热时间，让接流更稳。

四、资源更省：计算、存储、弹性三重降本

OpenStore的降本不是单点优化，而是对计算、存储和容量供给方式的系统重构。

计算降本：副本不再重复构建

“一处构建”也直接转化为计算收益。在相同写入压力下，PrimaryCPU与存算一体集群基本持平，收益主要来自Replica：1Replica时数据节点平均CPU相对下降约35%，写入平均RT下降约78%；2Replica时CPU相对下降约47%，写入平均RT下降约74%。

存储降本：本地盘只需覆盖热点

存算一体集群使用本地数据盘保存完整Shard数据。要缩减本地盘，不能只改变数据落点，还要保证小容量缓存下的查询效率。为此，OpenStore同时重构写入和查询路径：写入侧，Translog和索引文件绕过本地盘I/O，直接写入共享存储；查询侧，智能多级缓存保留热点，并针对倒排索引、DocValues、_source等文件类型采用差异化的准入、预读和淘汰策略。

两条路径协同后，计算节点的本地盘从完整数据副本变为热点缓存。在典型检索场景中，本地缓存盘可以按照节点内存约3倍起配。

弹性降本：从固定容量到按需扩缩

对于峰谷明显的业务，可以按小时配置容量，在高峰前调高、低峰后调低。下图基于某已完成OpenStore迁移客户的典型日监控数据匿名化重绘：数据节点平均CPU在上午和下午形成双峰，容量按时段提前切换。按图中的相对成本模型计算，从全天峰值容量改为三档分时后，计算成本由2400降至1800，下降约25%。

客户案例：三笔收益叠加，综合成本下降约35%

下面以同一客户迁移前后的真实资源配置为基础，统一按阿里云Elasticsearch华东1目录价测算月度成本。双方本地盘均按PL1计价，OpenStore计算成本叠加上述三档分时模型。

资源项	存算一体	OpenStore
峰值数据节点	28个	26个
节点规格	32C128GB	32C128GB
单节点本地盘	3072GBPL1	460GBPL1缓存盘
本地盘总量	约84TB	约11.7TB
OpenStore共享存储空间	—	21TB
容量策略	28个节点全天运行	按业务峰谷分时伸缩

计算收益。物理复制降低副本侧的重复构建开销，峰值数据节点从28个降至26个，先压低峰值计算基线。

存储收益。迁移前，为容纳完整副本并预留安全空间，集群共配置约84TB本地盘。迁移到OpenStore后，持久化数据由21TB共享存储统一承载，计算节点仅保留约11.7TB本地缓存，存储成本下降约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%。

五、面向未来：从资源弹性到AgentReady

分时弹性让资源随业务周期灵活伸缩。面向RAG与Agent，算力将进一步从“按计划扩缩”走向“随负载而动”。

阿里云Elasticsearch将沿着三个方向继续演进：

• 从分时弹性到自动弹性。弹性管控实时感知CPU等负载指标，自动调整节点数量和规格，让资源更贴近业务负载。

• 从资源供给到有效算力。通过Shard热点均衡与参数自适应，动态调整Shard、Replica和线程池等配置，让资源从“分配到位”走向“算力到位”。

• 从读写混合到独立扩缩。写入与查询算力按各自负载独立伸缩，高峰侧按需扩容，低峰侧及时释放。

从存算一体到存算分离，从固定资源到按需算力，OpenStore正在推动Elasticsearch向AgentReady搜索底座演进。数据常驻，算力流动；请求到来时按需供给，高峰过去后及时释放。

目前，阿里云Elasticsearch7.10、8.17和9.4版本均已支持存算分离与分时弹性，欢迎前往阿里云控制台体验。其中，8.17和9.4版本还可结合阿里云Elasticsearch云原生内核FalconSeek，进一步降低约30%的查询侧CPU开销。更多原理与实测，敬请关注后续专题文章。

业务可以有高峰，但资源不必永远停在高峰。

附录：测试环境

项目	OpenStore集群	存算一体集群
Elasticsearch版本	8.17.0	8.17.0
数据节点	6×16C64GB	6×16C64GB
Master节点	3×4C16GB	3×4C16GB
数据盘	256GBPL1	768GBPL1
DFS共享存储	5120GB	—

两套集群使用相同计算规格，在相同写入压力下进行对比。蓝绿变更测试使用3TB数据，包含208个业务索引、3000+Shard。

相关链接

• OpenStore存储计算分离（高性能检索）引擎介绍

• 物理复制功能介绍