基于 geonames / http_logs / nyc_taxis 三组标准数据集的存储压缩比与读写性能深度评测
上海悦高软件股份有限公司
2026 年 8 月 18 日
目录
目录
[一、为什么你应该关心一个数据库的 "压缩比"？](#一、为什么你应该关心一个数据库的 "压缩比"？ "#t2")
[LogsDB：行式存储 ------ 图书馆的 "按书架摆"](#LogsDB：行式存储 —— 图书馆的 "按书架摆" "#t4")
[Columnar：列式存储 ------ 图书馆的 "按类别分"](#Columnar：列式存储 —— 图书馆的 "按类别分" "#t5")
[LogsDB_Columnar：混合存储 ------ 两全其美？](#LogsDB_Columnar：混合存储 —— 两全其美？ "#t6")
[场景一：海量实时日志入库，存储成本优先 → 选 ES9 LogsDB_Columnar](#场景一：海量实时日志入库，存储成本优先 → 选 ES9 LogsDB_Columnar "#t15")
[场景二：小体量数据，高并发简单查询 → 选 ES9 原生 LogsDB](#场景二：小体量数据，高并发简单查询 → 选 ES9 原生 LogsDB "#t16")
[场景三：离线批量导入，几乎无实时写入，查询简单 → 可选 ES9 纯列存 Columnar](#场景三：离线批量导入，几乎无实时写入，查询简单 → 可选 ES9 纯列存 Columnar "#t17")
[九、从 ES8 升级到 ES9：值不值？](#九、从 ES8 升级到 ES9：值不值？ "#t18")
一、为什么你应该关心一个数据库的 "压缩比"？
想象你经营一家图书馆。每天有数十万本书入库，你的书架永远不够用。你被迫不断买新书架、租新仓库 ------ 直到有人告诉你：换一种图书编码方式，同样的书只需要原来三分之二的货架。
这就是 Elasticsearch （以下简称 ES）用户面临的现实问题。作为全球使用最广泛的 开源 搜索和分析引擎之一，ES 每天吞下海量的日志、轨迹和结构化数据。数据在膨胀，磁盘在尖叫，运维在加班。每一次版本升级，所有人最关心的问题只有一个：能不能存得更省、写得更快？
2026 年，ES 9.5 版本带着一个名为 Columnar 的列式存储引擎和一种叫 logsdb_columnar 的混合存储模式亮相。上海悦高软件的工程师用三组标准数据集做了严苛的对比测试，结果令人惊讶：在最有利的场景下，磁盘占用直降 30.8%，写入 吞吐量 翻倍，而代价是 ------ 复杂查询变慢了。
这是一场存储、写入与查询之间的 "三角博弈"。本文将带你读懂这场博弈的全貌。
二、三个名词，三种"存法"
在进入数据之前，我们需要搞懂三个关键概念。不必紧张，它们并不复杂。
LogsDB：行式存储 ------ 图书馆的 "按书架摆"
传统 ES 使用行式存储（row-oriented），每一条记录就像一本书，完整地摆在一个书架上。LogsDB 是 ES 为日志场景优化的行存模式，它按行保存整条日志记录，查询时能快速取出完整的一行数据。
类比：就像超市的购物小票，每一张小票上完整记录了 "时间、商品名、价格、数量"。你要看某次购物的全部信息，直接抽出那张小票即可。
Columnar：列式存储 ------ 图书馆的 "按类别分"
Columnar 是 ES 9.5 新引入的纯列式存储引擎。它不再按 "行" 存数据，而是按 "字段"（列）存。所有记录的同一个字段被打包在一起，就像把所有小票上的 "价格" 剪下来，集中放到一个盒子里。
类比：你要统计"今天所有商品的总销售额"，不需要翻每张小票，直接打开"价格"盒子加总即可。列存在聚合统计时效率极高，因为只需读取相关列，而非整行。
LogsDB_Columnar：混合存储 ------ 两全其美？
这是 ES 9.5 的 "杀手锏"。它同时使用行存和列存：日志主体走 LogsDB 行存，结构化字段走 Columnar 列存。相当于一个图书馆既按书架摆完整书籍（方便借阅整本），又按类别建了索引卡（方便统计某类信息）。
设计哲学：用行存保障实时写入和单条记录读取的效率，用列存获得结构化字段的压缩优势和聚合能力。
三、测试是怎么做的？
工程师选了三组业界公认的标准测试数据集，它们代表了三种典型数据特征：
| 数据集 | 特征 | 代表场景 |
|---|---|---|
| geonames | 小体量、字段少 | 轻量级元数据 |
| http_logs | 中等体量、半结构化 | 经典 Web 日志 |
| nyc_taxis | 大体量、高度结构化、字段多 | 重型结构化数据 |
测试覆盖了四种存储模式：
- ES 8.18 的原生 LogsDB（作为升级前基准）
- ES 9.5 的 LogsDB
- ES 9.5 的 Columnar
- ES 9.5 的 LogsDB_Columnar
三把尺子量到底 ------ 磁盘压缩比、写入吞吐与延迟、查询吞吐与延迟。
| 配置项 | 配置值 |
|---|---|
| ES 版本 | ES 8.x / ES 9.5 |
| 存储类型 | LogsDB / Columnar / LogsDB_Columnar |
| 测试数据集 | nyc_taxis / http_logs / geonames |
| 测试指标 | 存储压缩比、写入吞吐量、写入延迟、磁盘 IO 开销 |
四、存储压缩：省了多少磁盘？
先看最直观的指标 ------ 磁盘占用（数值越小越省）。所有测试场景的 ES 存储大小与原始数据集大小完全一致，磁盘占用无额外膨胀。
| 数据集 | ES8 LogsDB | ES9 LogsDB | ES9 Columnar | ES9 LogsDB_Columnar |
|---|---|---|---|---|
| geonames | 2.24 | 2.23 | 1.98 | 1.97 |
| http_logs | 8.85 | 7.57 | 8.04 | 7.50 |
| nyc_taxis | 22.61 | 21.80 | 17.82 | 15.63 |
三个规律一目了然：
- 混合存储（LogsDB_Columnar）压缩最优，纯列存（Columnar）次之，原生行存（LogsDB）最差。 三类数据集无一例外。
- ES9 原生 LogsDB 比 ES8 仅有小幅优化。 升级到 ES9 标准行存后，磁盘占用只是"轻微下降"。这说明 ES9 底层编码和合并逻辑做了微调，但行存架构的压缩天花板就在那里。
- 数据量越大、结构化程度越高，混合列存的压缩收益越惊人。 nyc_taxis 数据集从 22.61 降至 15.63，降幅高达 30.8% ；http_logs 降幅 15.2% ；geonames 降幅约 12%。
为什么？ 因为 nyc_taxis 字段最多、结构化程度最高。列存的核心优势在于：同一列的数据类型一致，压缩算法可以针对该类型做极致优化。字段越多、数据量越大，列存打包压缩的增益就越突出。而混合存储比纯列存还要好一点，说明"行存日志 + 列存字段"的分层设计比纯列存更精细------该行存的部分行存，该列存的部分列存，各取所长。
五、写入性能：快了多少？
如果说压缩比决定了 "存不存得下"，写入性能则决定了 "来不来得及" ------ 在海量实时日志场景下，写入跟不上数据生产速度，系统就会积压乃至雪崩。
| 数据集 | 存储模式 | 写入速率 (docs/s) | 写入延迟 (ms) |
|---|---|---|---|
| geonames | ES8 LogsDB | 12,827 | 22,602 |
| geonames | ES9 Columnar | 41,828 | 12,460 |
| geonames | ES9 LogsDB_Columnar | 35,536 | 15,178 |
| http_logs | ES8 LogsDB | 72,967 | 5,956 |
| http_logs | ES9 Columnar | 60,634 | 4,603 |
| http_logs | ES9 LogsDB_Columnar | 75,655 | 3,036 |
| nyc_taxis | ES8 LogsDB | 16,905 | 47,868 |
| nyc_taxis | ES9 Columnar | 18,163 | 35,174 |
| nyc_taxis | ES9 LogsDB_Columnar | 37,463 | 19,461 |
关键发现
-
混合存储（LogsDB_Columnar）是写入性能的 "全能冠军"。 三类数据集中写入吞吐全面领先 ES8 原生 LogsDB，写入延迟显著降低。最亮眼的是 nyc_taxis：写入吞吐从 16,905 飙升到 37,463 docs/s，直接翻倍；写入延迟从 47,868ms 降至 19,461ms，降幅超过 59%。
-
纯列存（Columnar）写入性能分化明显。 小数据集（geonames）写入吞吐 41,828 docs/s 全场最高；但中大数据集（http_logs、nyc_taxis）的写入吞吐低于混合列存，延迟更高。原因不难理解：纯列存需要为每个字段单独构建列块并定期刷新合并，大批量实时写入时构建开销成为瓶颈。混合存储把日志主体交给行存（写入快），只对结构化字段做列存转换，负担更轻。
-
ES8 原生 LogsDB 全面垫底。 所有数据集下 ES8 的写入吞吐最低、长尾写入延迟最高。ES9 对索引、刷新、段合并、translog 写入链路做了系统性优化，实时入库能力有了质的飞跃。
写入延迟的核心规律可以概括为一条排序：
LogsDB_Columnar > Columnar > ES9 LogsDB > ES8 LogsDB（从优到劣）
混合存储兼顾了行日志的写入效率和列字段的压缩优势，在实时写入场景下综合表现最优。
六、查询性能：代价在哪里？
天下没有免费的午餐。混合存储在压缩和写入上大获全胜，但查询性能------尤其是复杂查询------出现了明显的分化。
| 数据集 | 存储模式 | 查询速率 (ops/s) | 查询延迟 (ms) |
|---|---|---|---|
| geonames | ES8 LogsDB | 49.99 | 65 |
| geonames | ES9 Columnar | 49.84 | 70 |
| geonames | ES9 LogsDB_Columnar | 49.99 | 419 |
| http_logs | ES8 LogsDB | 20.02 | 17 |
| http_logs | ES9 Columnar | 20.03 | 19 |
| http_logs | ES9 LogsDB_Columnar | 20.01 | 23 |
| nyc_taxis | ES8 LogsDB | 3.03 | 23 |
| nyc_taxis | ES9 Columnar | 3.03 | 29 |
| nyc_taxis | ES9 LogsDB_Columnar | 3.03 | 477 |
关键发现
-
基础过滤查询：各存储模式几乎没有差距。 三类数据集的基础查询吞吐量（ops/s）在所有版本和存储模式下基本持平：geonames 约 50 ops/s、http_logs 约 20 ops/s、nyc_taxis 约 3 ops/s。简单字段过滤、少量匹配的场景，存储格式和 ES 版本对查询吞吐的影响极小。
-
复杂聚合查询：列存格式长尾延迟显著升高。 这是混合存储的主要代价。所有数据集都出现了同一规律------Columnar 和 LogsDB_Columnar 的 99 分位查询延迟显著高于原生 LogsDB：
- geonames ：原生 LogsDB 仅 65ms，混合列存高达 419ms，差距约 6.4 倍
- http_logs：列存格式延迟小幅上涨，差距不大
- nyc_taxis ：差距最悬殊------ES8 LogsDB 仅 23ms，LogsDB_Columnar 高达 477ms，差距超过 20 倍
为什么会这样？ 因为列存读取时，需要从多个独立的列块中分别取数据，再在内存中重新拼装成完整的行记录。对于"查一个字段"的简单查询，列存只需要读一列，效率很高。但对于"同时过滤多个字段 + 多维度聚合"的复杂查询，列存需要读取大量列块并在内存中重组，IO 和内存重组开销急剧上升，长尾延迟因此被放大。
-
纯列存与混合列存的查询差异不大。 Columnar 和 LogsDB_Columnar 的查询延迟接近，两者都劣于传统行存 LogsDB。
七、三个维度，一张全景图
把存储、写入、查询三个维度放在一起，ES 9.5 四种存储模式的实力排序清晰可见：
| 维度 | 最优 | 次优 | 第三 | 最末 |
|---|---|---|---|---|
| 存储压缩 | LogsDB_Columnar | Columnar | ES9 LogsDB | ES8 LogsDB |
| 实时写入 | LogsDB_Columnar | Columnar | ES9 LogsDB | ES8 LogsDB |
| 复杂查询 | ES8/ES9 LogsDB | --- | Columnar ≈ LogsDB_Columnar | --- |
一句话总结：LogsDB_Columnar 在存储和写入上全面领先，代价是复杂查询的长尾延迟升高；原生 LogsDB 在查询上最优，但存储和写入表现最弱。
八、该选哪一种？三个场景三条路
测试数据的价值在于指导选型。根据不同的业务场景，工程师给出了明确的建议：
场景一：海量实时日志入库，存储成本优先 → 选 ES9 LogsDB_Columnar
适用场景包括实时日志、轨迹追踪、海量结构化流水数据（如 nyc_taxis、http_logs 类型）。混合存储在这个场景下优势碾压级：磁盘压缩比最优，写入吞吐最高，写入长尾延迟大幅降低。唯一的短板是多字段复杂聚合查询延迟会明显上升，可以通过索引分层、预聚合、查询缓存等手段弥补。
场景二：小体量数据，高并发简单查询 → 选 ES9 原生 LogsDB
适用场景包括维度基础查询、简单过滤、少量聚合（如 geonames 小数据集）。原生行存查询延迟最低，读写均衡，无列存重组开销，运维简单。代价是磁盘压缩收益极低，大数据量下存储成本高。
场景三：离线批量导入，几乎无实时写入，查询简单 → 可选 ES9 纯列存 Columnar
适用场景包括离线全量导入、只读分析、单字段统计。纯列存压缩优于原生 LogsDB，小批量写入吞吐极高。但实时大批量写入性能弱，复杂查询延迟高，不适合在线服务。
九、从 ES8 升级到 ES9：值不值？
测试给出了明确答案------值得。ES9 对比 ES8 具备三重核心提升：
- 磁盘压缩能力提升：尤其是列存混合模式，收益巨大（最高 30.8%）
- 写入吞吐翻倍、写入长尾延迟大幅下降：实时入库能力实现质变
- 基础简单查询吞吐持平：没有性能退化，升级不会"伤及无辜"
唯一需要注意的是：如果业务重度依赖多字段复杂聚合查询，且对延迟极其敏感，那么列存模式（Columnar / LogsDB_Columnar）的查询短板需要通过工程手段来补偿。但对于绝大多数以日志写入和存储成本为核心诉求的场景，ES9 的收益远大于代价。
十、结语：存储、写入与查询的永恒博弈
数据库的世界里，存储、写入和查询构成了一组不可能同时最优的 "三角约束"。ES 9.5 的 LogsDB_Columnar 模式用混合存储的策略给出了一个精妙的回答：用行存保障写入效率，用列存获取压缩优势，在两者之间找到平衡点。代价是查询性能的部分让渡，但这笔交易对于海量日志场景来说是划算的。
技术选型从来不是选"最好"的，而是选"最合适"的。理解数据特征、明确业务优先级，然后对号入座------这才是测试报告留给我们最有价值的遗产。
数据来源：上海悦高软件股份有限公司，《ES 9.5 存储压缩比与写入性能测试报告》，2026 年 8 月 11 日。测试基于 geonames、http_logs、nyc_taxis 三组标准数据集，覆盖 ES 8.18 与 ES 9.5 两个版本、LogsDB / Columnar / LogsDB_Columnar 三种存储模式。