悦高软件带你体验 ES9.5 的性能跃升之路

你的日志数据正在以每天 TB 级的速度增长，磁盘越来越贵、报表越算越慢、深夜写入高峰还频频告警 —— 这几乎是每个做数据平台的人都经历过的成长烦恼。

今天，悦高软件带你走进Elasticsearch 9.5（简称 ES9.5）的真实测试现场，用一场看得懂、记得住、能落地的 “体验之旅”，领略新一代搜索引擎是如何把存储、分析与写入这三大难题逐一击破的。

一、出发之前：先认识两位主角

这场测试的主角有两位：

测试环境非常朴素，也很贴近真实生产：两套各 3 节点的标准集群，每节点 4 核 8G 内存、40G 磁盘。用的数据也是大家熟悉的三种业务形态：

• http_logs：海量网络访问日志（典型的“日志”场景）
• geonames：全球地理点位数据（典型的“小维度数据”场景）
• nyc_taxis：纽约出租车订单流水（典型的“海量结构化数据”场景）

三套数据，恰好覆盖了日志、查询、结构化流水三大典型业务。

二、入门第一课：ES9.5 的 “三个储物间”

想听懂后面的故事，只需要弄懂一个概念：ES9.5 提供了三种数据存储模式，相当于三个装修风格不同的 “储物间”。

打个比方：你要算 “一年打车花了多少钱”。行存模式要把每张打车小票从头翻到尾，列存模式则直接把 “金额” 这一栏抽出来加总——快得不止一个数量级。而混合模式最聪明：日志原文按行存记（写起来顺畅），金额这类结构化字段同时放进列存（算起来飞快）。

记住这三个储物间，后面的 “性能跃升” 就都解释得通了。

三、体验第一站：存储成本“断崖式”下降

存储是所有大数据平台的第一大开销。测试用磁盘占用来衡量压缩效果：数值越低，说明同样的数据占的磁盘越少，钱花得越省。

以 ES8.18 LogsDB 作为原始基线，ES9.5 各模式磁盘占用对比如下（单位：GB）：

三条规律，一读就懂：

1. 三种模式全面优于 ES8：即使不换存储模式，ES9.5 原生 LogsDB 也因底层编码与段合并优化小幅省盘；
2. 混合模式全场景最省：三个数据集上，logsdb_columnar都是磁盘占用最低的方案；
3. 数据越大、省得越多：小数据省 12%，日志省 15%，海量结构化流水直接省下近 31%——体量越大，收益越夸张。

换成钱来看：海量结构化日志业务磁盘占用下降超 30%，意味着扩容和归档备份的硬件采购成本同步降低 30% 以上；常规日志业务也能省下约 15%。省下的磁盘，就是实打实的利润。

四、体验第二站：ES|QL 统一分析栈，查询快了 85 倍

如果说省存储是 “节流”，那么查询提速就是 “开源”。

ES9.5 内置了ES|QL——一套统一的查询分析语法，检索、过滤、多维聚合一套语句搞定。测试用两条典型分析查询（人口维度聚合、时间维度聚合）对比新旧版本，结果令人震撼（单并发平均耗时）：

为什么能快这么多？ 关键在列存的**“按需取数”**：

• ES8 行存执行聚合要读取完整文档，大量无效 IO、逐行计算，CPU 被拖到 39% 稳态占用，报表稍一复杂就卡顿；
• ES9 列存按需加载聚合所需字段，跳过无关数据的磁盘 IO，并采用存储层向量化批量计算、分组聚合下推，把同样的分析查询 CPU 占用压到 15%——只有 ES8 的 38%。

换算成业务价值：同样的分析查询负载，现有集群可以承载约 2.6 倍的分析并发。更重要的是，ES|QL 一套语法统一了检索与统计，替代过去“聚合 + DSL 多套语法”的写法，报表开发从“几周”缩短到“几天”，运维人力也随之下降。

💡小贴士：简单 SUM 聚合收益（85 倍）远大于复杂多字段聚合（3 倍），但即便最复杂的场景也有 3 倍提升——方向上全面领先。

五、体验第三站：写入能力全面升级，吞吐直接翻倍

日志平台最怕什么？深夜业务高峰，写入顶不住、延迟飙升。测试同样给出了答案——logsdb_columnar混合模式是当之无愧的 “写入冠军”：

三个值得记住的数字：

1. 吞吐翻倍：海量结构化数据nyc_taxis写入吞吐从 16,906 docs/s 跃升至 37,464 docs/s，提升 221.6%；
2. 延迟大降：写入长尾延迟 P99 从 47,869ms 降到 19,462ms，降幅高达 59%（最低仅为基线的 40.65%）；
3. 全链路重构：translog、刷新、段合并写入链路全面优化，混合存储兼顾了 “日志行写入效率” 与 “列字段压缩”。

业务含义很直接：同样的写入量，集群节点规模可以缩减 50%；同样的集群，能扛住更高峰值的写入洪峰。

六、实事求是的体检报告：两个已知短板

任何技术选型都要“看清全貌”。测试也如实记录了两个短板，都不影响整体升级价值，但必须提前知晓：

短板一：列存模式复杂实时查询存在长尾延迟

logsdb_columnar和纯Columnar在执行“多字段复合过滤 + 多层嵌套聚合”的实时查询时，需要重组行数据，IO 与内存开销上升，P99 查询延迟明显高于原生 LogsDB。

• 缓解手段成熟：预聚合、索引分层、查询缓存，三者叠加可有效抵消损耗。

短板二：纯 Columnar 大批量实时写入性能不足

纯列存构建列块、刷新合并的开销大，高并发实时日志写入吞吐低于混合存储。

• 定位建议：纯列存不适合承载实时写入业务，它的定位在离线场景。

同时请放心一件事：基础简单查询零退化。全数据集基础过滤查询吞吐量与 ES8 持平——geonames 稳定约 50 ops/s、http_logs 约 20 ops/s、nyc_taxis 约 3 ops/s，升级不会伤害现有检索能力。

七、选型地图：三个场景，三套方案

没有“万能方案”，只有“最合适的方案”。结合业务读写特征，报告给出了清晰的分场景选型建议：

一句话总结选型逻辑：实时写入和存储省钱选混合、高频简单查询选行存、离线分析选列存——按业务特征对号入座。

八、终点站：一次看得见的 “性能跃升”

回到文章开头：日志天天涨、磁盘越来越贵、报表越算越慢——这些烦恼，ES9.5 都给出了实测答案。

三大核心收益，一张 KPI 表收尾：

最终结论（来自悦高软件测试报告）：

1. ES9.5 全方位优于 ES8.18，升级具备明确的业务与成本收益，且无基础检索性能退化风险；
2. 三大存储模式适用边界清晰，不存在通用万能方案，需按业务读写特征选型；
3. 核心短板仅集中在列存模式的复杂实时查询，均有成熟优化手段抵消，不影响整体升级价值。

给决策者的一句话：如果你的业务是海量日志、时序数据或结构化流水，直接升级 ES9.5 并启用logsdb_columnar混合存储，是最省心、最省钱、最稳的选择。

本文全部数据与结论均来源于《ES 9.5 技术调研与测试评估汇总报告》（上海悦高软件股份有限公司，2026年8月12日），未引用任何外部数据源。测试环境为两套 3 节点 4 核 8G 标准集群，单节点 40G 磁盘，master+data 混合角色。