全面解析龙之信条2神秘商店解锁方法与技巧
2026-07-23 3419549
2026-07-23 0
导读:从存算一体到存算分离,Elasticsearch如何做到变更更快、迁移更稳、资源更省?本文解析阿里云Elasticsearch的存算分离与弹性架构,并以一个综合成本下降约35%的真实客户案例拆解计算、存储与弹性三重降本。
一套Elasticsearch集群,什么时候最贵?
很多人首先想到的是业务高峰:写入攀升、查询打满,CPU和磁盘I/O接近水位上限。但真正持续推高云上成本的,往往是高峰过后仍无法释放的资源。
为了承接短时高峰,计算资源长期按峰值预留;
Primary和Replica各持完整的本地数据副本,副本越多,存储成本越高;
扩缩容、节点替换和故障恢复都要搬迁大量Shard文件、重新预热缓存,变更慢、风险高。
前两项直接增加账单;第三项则让团队不敢轻易缩容,冗余资源因此长期驻留。
这些问题的根源是同一个:数据与计算节点深度绑定。节点既负责计算,也承载完整的Shard数据;数据越多,节点就越“重”。
阿里云Elasticsearch的存算分离与弹性架构正是为了打破这一约束。它用共享存储承载持久化数据,让计算资源随业务负载灵活伸缩,从而做到变更更快、迁移更稳、资源更省。
要让资源随负载流动,先要让节点轻起来。阿里云Elasticsearch通过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还会并行加载文件元数据,进一步缩短就绪时间。
更快的关键,不是搬得更快,而是少构建、少搬迁。
在相同环境下,选取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越大,优势越明显。
轻量迁移解决了“数据就绪”,却不等于“热点就绪”。新节点的本地缓存仍然是冷的,如果立即接入查询流量,首次访问可能回源共享存储,带来查询RT抖动。
为此,阿里云Elasticsearch研发了PageReplay热点预热机制。它不复制真实查询流量,而是以Page为粒度记录近期访问热度,在迁移收尾阶段筛选活跃热页,并在Target接流前定向加载到本地缓存。整个过程只预热近期热点,而非完整Shard,在控制开销的同时降低冷启动带来的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%。
下面以同一客户迁移前后的真实资源配置为基础,统一按阿里云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%。
分时弹性让资源随业务周期灵活伸缩。面向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存储计算分离(高性能检索)引擎介绍
物理复制功能介绍