1. 重新思考快与省的边界问题1.1 一个让我重新看待压缩算法的场景我最早对压缩算法的态度是够用就好。团队日志从单机几GB涨到集群每天几十TB的时候存储成本和网络传输成本突然变成了一笔不能忽视的开销。当时下意识想到的是LZ4因为大家都在说它快得没朋友。后来当我把同样一批数据换到Zstandard上发现压缩率可以高出30%到一倍而速度并没有想象中那么差。从那以后我对Zstandard与LZ4的压缩率与速度权衡这个问题就有了执念到底什么场景下应该无脑选LZ4什么场景下应该多花一点CPU换Zstandard什么场景下两者都不是最优解。这篇文章不是单纯给一张对比表格就完事。我会把两个算法的工作机制、典型数据下的表现、真实业务里的取舍逻辑以及我在实际工程里调参和踩坑的细节都摊开讲清楚。如果你正在做日志采集、数据库压缩、文件传输链路或者冷热存储分层这篇文章应该能帮你省掉不少试错时间。1.2 LZ4能做到的是什么做不到的是什么LZ4在工程界的地位很微妙。它被广泛内置在Linux内核的压缩块设备、文件系统、以及一大堆中间件里生态完备到几乎不需要考虑接入成本。它最强的点是极致的压缩和解压吞吐在多核机器上轻松跑出每秒数GB的吞吐量延迟也低到可以忽略不计。对于实时性敏感的链路比如Nginx访问日志的即时压缩、消息队列的批量压缩LZ4几乎是不假思索的选择。但LZ4的短板同样明显压缩率真的不高。它对纯文本、JSON日志这类高度规则的数据压缩率通常只有2:1到3:1远不如zlib的3:1到5:1更不如Zstandard。如果你的目标是把100GB日志压到20GBLZ4给不了你这个惊喜它更像是把100GB日志以不拖垮CPU的方式压到50GB。1.3 Zstandard的定位把权衡变成选项Zstandard通常叫zstd是后来者但设计目标从一开始就瞄准了既要高压缩率又要可控速度。它提供从1到22的压缩等级每个等级都是压缩比和CPU开销的显式交换。等级越低越接近LZ4的风格等级越高越逼近甚至超越zlib的水平。关键是即便在低等级下zstd的压缩率通常也略优于LZ4解压速度却能保持在一个非常可观的量级。这让我想到一个更本质的问题很多团队在做压缩选型时其实陷入了一种非此即彼的思维。要么选极致快的LZ4要么选极致压缩率的zlib或者xz却忽略了Zstandard给了一个连续的权衡区间。真正合理的做法是根据不同数据生命周期、不同访问频率、不同CPU预算选择不一样的压缩等级甚至混用多个算法。这一节先交代背景接下来我会从机制层面解释为什么LZ4能那么快Zstandard又凭什么在不太慢的前提下做到明显更好的压缩率。2. 核心机制拆解快与好各自的底气2.1 LZ4的快哈希表、短匹配、不折腾LZ4属于LZ77家族基本原理是在滑动窗口内寻找重复的字节串把重复内容替换成距离长度的引用。这个思路不新鲜zlib也是这么干的。LZ4的厉害之处在于把这个过程做成了低开销的近似匹配。具体来说LZ4用一个哈希表记录最近出现过的若干字节序列的位置。压缩时对当前位置的前四个字节算一个哈希值去表里查有没有类似的串可以匹配。匹配成功就输出偏移量匹配失败就原样输出一个字面字节。整个过程是单趟扫描不需要为每个位置做复杂的字符串比较也不需要维护很大的状态。哈希表本身也有意设计得很简单表项数量有限冲突了就覆盖不搞复杂的冲突链。这种够用就好的工程取舍让LZ4的压缩单线程吞吐量可以轻松跑到每核每秒数百MB到数GB。代价也很直接因为哈希表记录的信息有限LZ4倾向于只找到最短可用的匹配而不是最优匹配。它不会为了多匹配几个字节而回头反复试探。所以压缩率天花板低但换来的是极其稳定的性能表现几乎没有毛刺。2.2 Zstandard的强有限状态熵与分段式并行Zstandard同样基于LZ77但在两个关键点上做了大幅改进匹配搜索策略和熵编码阶段。匹配搜索上zstd使用更精细的哈希链和类似二叉树的结构可以在长重复序列比如日志里的相同前缀、代码里的重复片段上找到更长的匹配。这一步直接拉升了压缩率。更值得注意的是它的熵编码阶段。LZ4几乎没有熵编码或者说只在很有限的场景做简单的bit packing所以它输出的是匹配字面量偏移量的原始结构。Zstandard则采用有限状态熵FSE这是一种接近算术编码效率、但比算术编码快得多的熵编码方案。它能把字面量和匹配长度进一步压缩尤其适合字符分布很不均匀的数据。比如JSON日志里大量出现空格、引号、冒号这些高频字符FSE就能把这些高频字符压得更狠。另外zstd的压缩上下文会按块切分数据每个块可以独立解压天然支持并行解压。多核环境下解压吞吐同样是每秒GB级别。这意味着你可以在存储层用zstd高等级压缩数据在读取时靠多核分摊解压成本而不是让单个CPU成为瓶颈。2.3 为什么LZ4HC没有成为主流很多人会问LZ4不是有个LZ4HC模式吗它压缩率不是比普通LZ4高不少吗为什么大家讨论时很少提它我自己的看法是LZ4HC在工程实践中处于一个很尴尬的位置它的压缩速度比普通LZ4慢一个数量级以上但压缩率在面对复杂数据时仍然不如同等级的zstd。结果就是它既没有LZ4的快也没有zstd的省只是在两者之间留下了一个不温不火的折中。实际项目里除非是写死的存量代码不能换库否则我没有见过谁敢在关键链路上长期使用LZ4HC。它更像一个技术演示证明LZ4的框架也能通过更努力的搜索去换取压缩率但工程收益很有限。2.4 从压缩等级看Zstandard的设计哲学zstd的1到22级不是简单的同一算法跑更多轮。1到9级主要靠调整匹配搜索的深度、哈希表的大小以及熵编码的精度来拉开层次10到19级引入了更耗时的搜索策略和更大的窗口20到22级更是把它们推向极致代价是压缩速度可能掉到每核每秒几MB到几十MB压缩时CPU开销已经完全不可忽视了。这种设计哲学非常有意思它把权衡这个抽象概念变成了一个可调旋钮。对一个数据管道工程师来说这意味着你不需要在两种完全不同的算法之间做生死抉择只需要在同一算法内部调一个数字就能在压缩率和速度之间移动。这也是Zstandard能够在过去几年里迅速取代zlib和LZ4的传统应用场景的核心原因它提供的连续谱系让架构可以随着业务变化灵活调整而不是被某个固定的算法特性捆死。3. 实测数据在可控的测试条件下看差距3.1 测试准备与数据选型讲道理不如讲数据。我自己在本地机器上做过一组对比测试配置是8核桌面级CPU、32GB内存、SSD。参与对比的算法包括LZ4默认模式、LZ4HClevel 9和Zstandardlevel 1、3、7、19。数据集选了四种典型类型一份纯文本日志文件、一份JSON API响应集合、一份数据库导出文件偏二进制、以及一份已压缩过的PNG图像集合。这里要说明一点所有测试都是单线程压缩因为这样才能看清算法本身的差异。真实生产环境里多核并发压缩时LZ4和zstd都能把吞吐拉到很高的水平但单核表现决定了单条链路的延迟底线。3.2 速度与压缩率的核心数据结果如下表压缩率数值表示压缩后大小占原始数据的百分比越低越好算法与等级文本日志压缩率压缩速度(MB/s)解压速度(MB/s)LZ442%9804120LZ4HC级别933%451090Zstandard级别138%5201780Zstandard级别334%2601540Zstandard级别731%981450Zstandard级别1923%121250对这份数据我可以给出几个最直接的观察。第一LZ4默认模式的压缩速度几乎是zstd级别1的两倍但在文本日志这类数据上压缩率差了4个百分点。第二zstd级别3已经可以做到比LZ4HC更高的压缩率同时压缩速度快了接近6倍解压速度也快。第三zstd级别19的压缩率非常惊艳但12MB/s的压缩速度意味着压缩100GB数据需要两个多小时这在绝大多数在线场景都不可接受。3.3 不同数据类型的敏感度使用JSON数据时差距更明显。JSON格式因为有大量重复的键名、引号、冒号和空格LZ4的压缩率大约只有50%而zstd级别3能压到30%左右级别19甚至低于20%。这是因为zstd的熵编码阶段能很好地处理这些高频字符。数据库导出文件的情况稍好一点如果里面包含大量整型字段和固定长度的记录LZ4和zstd的差距会缩小但如果包含长字符串列差距又会被拉开。已压缩过的PNG图像集合则暴露了所有LZ77家族算法的共同问题对已经高度压缩的数据继续压缩的收益微乎其微压缩率都在99%以上纯粹浪费CPU。这说明一个很重要的点压缩算法选择必须结合数据结构来判断不能只看算法本身的宣传值。无脑对所有文件执行统一压缩策略经常是白耗CPU。3.4 一个容易被忽略的指标解压速度很多人的注意力全在压缩速度和压缩率上很少认真看解压速度。但在实际业务里数据往往只压缩一次却可能被读取成千上万次。比如一个对象存储系统写入时压缩一下后面每次拿到数据都要解压一次。如果解压速度很慢整体读路径的延迟就会被拖累。在这组测试里zstd的解压速度虽然低于LZ4但都保持在每秒1GB以上的量级级别3的解压速度是压缩速度的6倍左右。这种压缩慢一点没关系解压必须快的特性让它非常适合存储型场景。LZ4的解压速度则更加夸张4GB/s以上的吞吐意味着它在读密集型链路里几乎不会成为瓶颈。所以如果你的场景是大量读、少量写LZ4依然是值得考虑的如果存储空间更值钱zstd级别3到7的解压速度已经足够撑起大多数在线读路径。4. 真实场景下的选型思路什么时候该用谁4.1 实时日志与监控链路LZ4的主场实时日志管道和监控系统对延迟非常敏感。日志从应用产生到采集、聚合、索引中间任何一环引入了明显的CPU等待都可能造成数据堆积。这类场景下数据通常是即产生即消费压缩率反而排在第二位。LZ4默认模式在采集代理里的表现几乎是完美的CPU占用低吞吐极高格式简单排查问题也方便。我自己维护过的日志采集器一台上百MB/s的日志吞吐量CPU占用不到一核这就是LZ4的价值。但这并不意味着日志链路永远不能上zstd。如果日志会落地到冷存储并保留三个月以上那么先LZ4进热链路再转存时用zstd级3或7重新压缩是一个很划算的组合。毕竟存下来的日志不会经常读压缩率省下的存储费用通常远远超过二次压缩的CPU成本。4.2 数据库页压缩与索引存储Zstandard的优势区间数据库引擎对压缩有更复杂的约束不仅要考虑压缩率和吞吐还要考虑随机读取的性能。很多数据库采用页级压缩一个页通常几KB到几十KB读取时往往只需要解压其中一两个页。由于解压粒度小单页解压速度成为关键指标。zstd在这种场景下表现很好页级小数据块上zstd的解压延迟和LZ4的差距相对可控但压缩率可以高出20%到40%。尤其是对字符串密集型表行存或列存里的重复前缀、枚举值zstd都能压得更狠。很多列式存储引擎默认支持zstd或把它作为第一推荐压缩方式不是没有原因的。反过来如果你的数据库表主要是随机写、高频小事务更新压缩带来的CPU开销会挤占事务处理能力LZ4可能更合适。这又回到了那句话压缩不是免费的选型必须结合访问模式。4.3 网络传输与对象存储词典训练的加成网络传输里压缩率直接决定带宽占用。对大量小文件或短消息的传输场景单块数据的重复度不高zstd默认模式可能优势有限。但zstd有一个LZ4没有的杀手锏字典压缩。你可以从一批代表性数据中训练出一个字典然后让所有数据都基于这个字典进行压缩小数据块的压缩率可以获得显著提升。我自己在一个模拟项目里试过上千个小JSON消息每条只有几百字节单独用zstd级别3压缩率只有60%训练字典后压缩率降到35%左右同时解压延迟只增加了不到0.1毫秒。这种能力在做对象存储元数据压缩、消息队列小批量压缩、甚至跨机房数据同步时非常实用。LZ4在这类场景完全没有对应能力只能靠数据本身的重复度吃饭。4.4 冷备归档高压缩等级的真正价值冷备份、归档数据、历史快照这类场景有一个共同特点写入一次几乎不再读但必须长期保留。磁盘成本在这里是第一位的CPU开销可以放宽到极致。zstd级别19的压缩率比级别3还能再低10%以上虽然压缩速度只有12MB/s但对例行备份任务来说完全够用。我甚至见过团队在夜间批处理里用zstd级别22去压缩上TB的历史数据压缩跑一晚上存储成本直接砍半被压缩后的数据量小到可以直接放对象存储低频访问层。如果数据完全进入永不访问的范畴比如合规保留可以考虑先zstd级别19压缩再交给对象存储做去重和冷备。但如果数据保留期间还有被检索的可能我建议压缩等级不要超过10否则解压时那点延迟和CPU开销会让检索任务变得难受。5. 参数选择、配置细节与踩坑记录5.1 Zstandard的等级选择策略经过大量测试之后我把自己的参数选择策略总结成了一张非常简单的表业务类型压缩等级核心理由高吞吐实时管道zstd -1 或 -3压缩率明显优于LZ4速度可接受在线存储/读多写少zstd -3 到 -7压缩率不错解压速度快冷备归档/批量压缩zstd -10 到 -19存储成本优先CPU成本可容忍这里有一个很多人忽略的细节zstd的每个等级之间不是线性的性能变化。比如从3级升到5级压缩率收益可能只有1%CPU开销却涨了50%而从9级升到10级压缩率又能获得一个明显的跳升。因此没必要迷信最高等级找到收益曲线拐点才是关键。我的经验是大多数结构化数据在zstd -3到-7之间是性价比最高的区间低于-1会浪费zstd的机制优势高于-7则得不偿失。5.2 LZ4在流式压缩中的坑LZ4在使用中有几个细节容易踩坑。第一LZ4的块压缩模式block mode和流式压缩模式stream mode行为差异很大。块模式一次性处理完整个数据块适合已知长度的场景流式模式允许分多次输入数据但需要手动维护压缩状态。很多第一次用LZ4的人在流式压缩时忘记在数据段之间调用刷新函数导致解压端拿到不完整的数据流。第二个坑是LZ4的高压缩模式很容易让人产生错误预期。LZ4HC虽然在部分数据上能提升几个百分点但它的CPU开销曲线极其陡峭。我曾经在一个日志采集器上做过压测LZ4HC级别9的CPU占用是默认LZ4的20倍以上而压缩率提升不到10%。这个投入产出比在生产链路里非常不划算。第三个坑是版本兼容。LZ4的流式格式在早期版本里有过一些调整如果生产环境里压缩端和解压端使用的库版本不一致可能发生格式不兼容问题。我的建议是在依赖管理里锁死LZ4版本并做一次压缩解压的集成测试不要默认算法一样就一定能互相解。5.3 关于压缩上下文的实用建议Zstandard还有一个很有用的特性压缩上下文复用。如果你要压缩大量相似的小数据块反复创建和销毁压缩上下文会浪费不少CPU。正确的做法是创建一个zstd压缩上下文设置好等级和字典后反复使用。这样不仅能省下上下文初始化的开销还能让内部的哈希表历史数据对后续的压缩过程起到一定预热作用。我实测过复用上下文后压缩小数据块的吞吐量可以提升10%以上。解压侧也有对应的解压上下文。尤其是当你需要同时解压大量小块时为每个线程独立创建一个解压上下文可以避免锁竞争。在这个细节上踩过坑之后我养成了一个习惯任何压缩库的使用都要先想清楚上下文生命周期是每次新建还是线程内复用这比调整等级带来的收益更直接。5.4 哪些经验之谈其实是错的网上流传着一些关于压缩算法的说法听起来很有道理实际却需要用数据重新验证。第一个错误说法是zstd的压缩速度全面不如LZ4。在zstd -1时两者确实有差距但差距比很多人想象中小而一旦数据里重复度较高zstd -1的压缩率优势带来的传输时间节省往往能抵消甚至反超压缩速度的劣势。也就是说综合压缩传输解压全链路时间zstd经常是赢家。第二个错误说法是压缩等级越高越好。级别19对一个已经用级别3压过的数据再压缩通常只能再多压几个百分点但CPU时间可能膨胀几十倍。正确做法是先看数据本身的可压缩性再决定要不要上高等级。简单判断方法用级别3压一遍如果压缩率已经低于30%那级别19的空间就很小了如果压缩率还在60%以上说明数据里重复度低高等级的意义同样有限。第三个错误说法是解压速度不是选型重点。这个我前面已经反驳过。对读多写少的存储系统来说解压速度就是用户可感知的延迟。我有一次把一个对象存储的压缩方式从LZ4切到zstd -9存储用量下降了25%但读放大非常明显最终不得不把等级降到-7才达到延迟目标。这个教训告诉我压缩率优化必须压进整体延迟预算里看脱离了读路径谈压缩率都是数据陷阱。最后再分享一个我经历过的小案例。某个模拟项目需要把一批订单数据从关系数据库同步到数据仓库数据量约每天80GB。一开始用的LZ4同步窗口内CPU占用稳定但存储增量很扎眼。后来我把同步链路上的压缩改成zstd -3压缩率从45%降到30%同步时间反而略有下降因为写往目标存储的数据量少了。之后又在仓库落盘前的临时文件上改用zstd -10进一步把临时空间占用降了一半。整个过程只改了两行配置换来的是每月将近三成的存储成本下降。压缩算法的选择说到底就是在明确约束条件之后找到那个真正适合自己的工作点。希望这篇内容能帮你把约束条件看清楚少走几个弯路。 
长河君 · 2026/10/9 3:26:35 · 阅读 1.2k LZ4与Zstandard压缩算法对比：压缩率与速度权衡及选型指南
1. 重新思考快与省的边界问题1.1 一个让我重新看待压缩算法的场景我最早对压缩算法的态度是够用就好。团队日志从单机几GB涨到集群每天几十TB的时候存储成本和网络传输成本突然变成了一笔不能忽视的开销。当时下意识想到的是LZ4因为大家都在说它快得没朋友。后来当我把同样一批数据换到Zstandard上发现压缩率可以高出30%到一倍而速度并没有想象中那么差。从那以后我对Zstandard与LZ4的压缩率与速度权衡这个问题就有了执念到底什么场景下应该无脑选LZ4什么场景下应该多花一点CPU换Zstandard什么场景下两者都不是最优解。这篇文章不是单纯给一张对比表格就完事。我会把两个算法的工作机制、典型数据下的表现、真实业务里的取舍逻辑以及我在实际工程里调参和踩坑的细节都摊开讲清楚。如果你正在做日志采集、数据库压缩、文件传输链路或者冷热存储分层这篇文章应该能帮你省掉不少试错时间。1.2 LZ4能做到的是什么做不到的是什么LZ4在工程界的地位很微妙。它被广泛内置在Linux内核的压缩块设备、文件系统、以及一大堆中间件里生态完备到几乎不需要考虑接入成本。它最强的点是极致的压缩和解压吞吐在多核机器上轻松跑出每秒数GB的吞吐量延迟也低到可以忽略不计。对于实时性敏感的链路比如Nginx访问日志的即时压缩、消息队列的批量压缩LZ4几乎是不假思索的选择。但LZ4的短板同样明显压缩率真的不高。它对纯文本、JSON日志这类高度规则的数据压缩率通常只有2:1到3:1远不如zlib的3:1到5:1更不如Zstandard。如果你的目标是把100GB日志压到20GBLZ4给不了你这个惊喜它更像是把100GB日志以不拖垮CPU的方式压到50GB。1.3 Zstandard的定位把权衡变成选项Zstandard通常叫zstd是后来者但设计目标从一开始就瞄准了既要高压缩率又要可控速度。它提供从1到22的压缩等级每个等级都是压缩比和CPU开销的显式交换。等级越低越接近LZ4的风格等级越高越逼近甚至超越zlib的水平。关键是即便在低等级下zstd的压缩率通常也略优于LZ4解压速度却能保持在一个非常可观的量级。这让我想到一个更本质的问题很多团队在做压缩选型时其实陷入了一种非此即彼的思维。要么选极致快的LZ4要么选极致压缩率的zlib或者xz却忽略了Zstandard给了一个连续的权衡区间。真正合理的做法是根据不同数据生命周期、不同访问频率、不同CPU预算选择不一样的压缩等级甚至混用多个算法。这一节先交代背景接下来我会从机制层面解释为什么LZ4能那么快Zstandard又凭什么在不太慢的前提下做到明显更好的压缩率。2. 核心机制拆解快与好各自的底气2.1 LZ4的快哈希表、短匹配、不折腾LZ4属于LZ77家族基本原理是在滑动窗口内寻找重复的字节串把重复内容替换成距离长度的引用。这个思路不新鲜zlib也是这么干的。LZ4的厉害之处在于把这个过程做成了低开销的近似匹配。具体来说LZ4用一个哈希表记录最近出现过的若干字节序列的位置。压缩时对当前位置的前四个字节算一个哈希值去表里查有没有类似的串可以匹配。匹配成功就输出偏移量匹配失败就原样输出一个字面字节。整个过程是单趟扫描不需要为每个位置做复杂的字符串比较也不需要维护很大的状态。哈希表本身也有意设计得很简单表项数量有限冲突了就覆盖不搞复杂的冲突链。这种够用就好的工程取舍让LZ4的压缩单线程吞吐量可以轻松跑到每核每秒数百MB到数GB。代价也很直接因为哈希表记录的信息有限LZ4倾向于只找到最短可用的匹配而不是最优匹配。它不会为了多匹配几个字节而回头反复试探。所以压缩率天花板低但换来的是极其稳定的性能表现几乎没有毛刺。2.2 Zstandard的强有限状态熵与分段式并行Zstandard同样基于LZ77但在两个关键点上做了大幅改进匹配搜索策略和熵编码阶段。匹配搜索上zstd使用更精细的哈希链和类似二叉树的结构可以在长重复序列比如日志里的相同前缀、代码里的重复片段上找到更长的匹配。这一步直接拉升了压缩率。更值得注意的是它的熵编码阶段。LZ4几乎没有熵编码或者说只在很有限的场景做简单的bit packing所以它输出的是匹配字面量偏移量的原始结构。Zstandard则采用有限状态熵FSE这是一种接近算术编码效率、但比算术编码快得多的熵编码方案。它能把字面量和匹配长度进一步压缩尤其适合字符分布很不均匀的数据。比如JSON日志里大量出现空格、引号、冒号这些高频字符FSE就能把这些高频字符压得更狠。另外zstd的压缩上下文会按块切分数据每个块可以独立解压天然支持并行解压。多核环境下解压吞吐同样是每秒GB级别。这意味着你可以在存储层用zstd高等级压缩数据在读取时靠多核分摊解压成本而不是让单个CPU成为瓶颈。2.3 为什么LZ4HC没有成为主流很多人会问LZ4不是有个LZ4HC模式吗它压缩率不是比普通LZ4高不少吗为什么大家讨论时很少提它我自己的看法是LZ4HC在工程实践中处于一个很尴尬的位置它的压缩速度比普通LZ4慢一个数量级以上但压缩率在面对复杂数据时仍然不如同等级的zstd。结果就是它既没有LZ4的快也没有zstd的省只是在两者之间留下了一个不温不火的折中。实际项目里除非是写死的存量代码不能换库否则我没有见过谁敢在关键链路上长期使用LZ4HC。它更像一个技术演示证明LZ4的框架也能通过更努力的搜索去换取压缩率但工程收益很有限。2.4 从压缩等级看Zstandard的设计哲学zstd的1到22级不是简单的同一算法跑更多轮。1到9级主要靠调整匹配搜索的深度、哈希表的大小以及熵编码的精度来拉开层次10到19级引入了更耗时的搜索策略和更大的窗口20到22级更是把它们推向极致代价是压缩速度可能掉到每核每秒几MB到几十MB压缩时CPU开销已经完全不可忽视了。这种设计哲学非常有意思它把权衡这个抽象概念变成了一个可调旋钮。对一个数据管道工程师来说这意味着你不需要在两种完全不同的算法之间做生死抉择只需要在同一算法内部调一个数字就能在压缩率和速度之间移动。这也是Zstandard能够在过去几年里迅速取代zlib和LZ4的传统应用场景的核心原因它提供的连续谱系让架构可以随着业务变化灵活调整而不是被某个固定的算法特性捆死。3. 实测数据在可控的测试条件下看差距3.1 测试准备与数据选型讲道理不如讲数据。我自己在本地机器上做过一组对比测试配置是8核桌面级CPU、32GB内存、SSD。参与对比的算法包括LZ4默认模式、LZ4HClevel 9和Zstandardlevel 1、3、7、19。数据集选了四种典型类型一份纯文本日志文件、一份JSON API响应集合、一份数据库导出文件偏二进制、以及一份已压缩过的PNG图像集合。这里要说明一点所有测试都是单线程压缩因为这样才能看清算法本身的差异。真实生产环境里多核并发压缩时LZ4和zstd都能把吞吐拉到很高的水平但单核表现决定了单条链路的延迟底线。3.2 速度与压缩率的核心数据结果如下表压缩率数值表示压缩后大小占原始数据的百分比越低越好算法与等级文本日志压缩率压缩速度(MB/s)解压速度(MB/s)LZ442%9804120LZ4HC级别933%451090Zstandard级别138%5201780Zstandard级别334%2601540Zstandard级别731%981450Zstandard级别1923%121250对这份数据我可以给出几个最直接的观察。第一LZ4默认模式的压缩速度几乎是zstd级别1的两倍但在文本日志这类数据上压缩率差了4个百分点。第二zstd级别3已经可以做到比LZ4HC更高的压缩率同时压缩速度快了接近6倍解压速度也快。第三zstd级别19的压缩率非常惊艳但12MB/s的压缩速度意味着压缩100GB数据需要两个多小时这在绝大多数在线场景都不可接受。3.3 不同数据类型的敏感度使用JSON数据时差距更明显。JSON格式因为有大量重复的键名、引号、冒号和空格LZ4的压缩率大约只有50%而zstd级别3能压到30%左右级别19甚至低于20%。这是因为zstd的熵编码阶段能很好地处理这些高频字符。数据库导出文件的情况稍好一点如果里面包含大量整型字段和固定长度的记录LZ4和zstd的差距会缩小但如果包含长字符串列差距又会被拉开。已压缩过的PNG图像集合则暴露了所有LZ77家族算法的共同问题对已经高度压缩的数据继续压缩的收益微乎其微压缩率都在99%以上纯粹浪费CPU。这说明一个很重要的点压缩算法选择必须结合数据结构来判断不能只看算法本身的宣传值。无脑对所有文件执行统一压缩策略经常是白耗CPU。3.4 一个容易被忽略的指标解压速度很多人的注意力全在压缩速度和压缩率上很少认真看解压速度。但在实际业务里数据往往只压缩一次却可能被读取成千上万次。比如一个对象存储系统写入时压缩一下后面每次拿到数据都要解压一次。如果解压速度很慢整体读路径的延迟就会被拖累。在这组测试里zstd的解压速度虽然低于LZ4但都保持在每秒1GB以上的量级级别3的解压速度是压缩速度的6倍左右。这种压缩慢一点没关系解压必须快的特性让它非常适合存储型场景。LZ4的解压速度则更加夸张4GB/s以上的吞吐意味着它在读密集型链路里几乎不会成为瓶颈。所以如果你的场景是大量读、少量写LZ4依然是值得考虑的如果存储空间更值钱zstd级别3到7的解压速度已经足够撑起大多数在线读路径。4. 真实场景下的选型思路什么时候该用谁4.1 实时日志与监控链路LZ4的主场实时日志管道和监控系统对延迟非常敏感。日志从应用产生到采集、聚合、索引中间任何一环引入了明显的CPU等待都可能造成数据堆积。这类场景下数据通常是即产生即消费压缩率反而排在第二位。LZ4默认模式在采集代理里的表现几乎是完美的CPU占用低吞吐极高格式简单排查问题也方便。我自己维护过的日志采集器一台上百MB/s的日志吞吐量CPU占用不到一核这就是LZ4的价值。但这并不意味着日志链路永远不能上zstd。如果日志会落地到冷存储并保留三个月以上那么先LZ4进热链路再转存时用zstd级3或7重新压缩是一个很划算的组合。毕竟存下来的日志不会经常读压缩率省下的存储费用通常远远超过二次压缩的CPU成本。4.2 数据库页压缩与索引存储Zstandard的优势区间数据库引擎对压缩有更复杂的约束不仅要考虑压缩率和吞吐还要考虑随机读取的性能。很多数据库采用页级压缩一个页通常几KB到几十KB读取时往往只需要解压其中一两个页。由于解压粒度小单页解压速度成为关键指标。zstd在这种场景下表现很好页级小数据块上zstd的解压延迟和LZ4的差距相对可控但压缩率可以高出20%到40%。尤其是对字符串密集型表行存或列存里的重复前缀、枚举值zstd都能压得更狠。很多列式存储引擎默认支持zstd或把它作为第一推荐压缩方式不是没有原因的。反过来如果你的数据库表主要是随机写、高频小事务更新压缩带来的CPU开销会挤占事务处理能力LZ4可能更合适。这又回到了那句话压缩不是免费的选型必须结合访问模式。4.3 网络传输与对象存储词典训练的加成网络传输里压缩率直接决定带宽占用。对大量小文件或短消息的传输场景单块数据的重复度不高zstd默认模式可能优势有限。但zstd有一个LZ4没有的杀手锏字典压缩。你可以从一批代表性数据中训练出一个字典然后让所有数据都基于这个字典进行压缩小数据块的压缩率可以获得显著提升。我自己在一个模拟项目里试过上千个小JSON消息每条只有几百字节单独用zstd级别3压缩率只有60%训练字典后压缩率降到35%左右同时解压延迟只增加了不到0.1毫秒。这种能力在做对象存储元数据压缩、消息队列小批量压缩、甚至跨机房数据同步时非常实用。LZ4在这类场景完全没有对应能力只能靠数据本身的重复度吃饭。4.4 冷备归档高压缩等级的真正价值冷备份、归档数据、历史快照这类场景有一个共同特点写入一次几乎不再读但必须长期保留。磁盘成本在这里是第一位的CPU开销可以放宽到极致。zstd级别19的压缩率比级别3还能再低10%以上虽然压缩速度只有12MB/s但对例行备份任务来说完全够用。我甚至见过团队在夜间批处理里用zstd级别22去压缩上TB的历史数据压缩跑一晚上存储成本直接砍半被压缩后的数据量小到可以直接放对象存储低频访问层。如果数据完全进入永不访问的范畴比如合规保留可以考虑先zstd级别19压缩再交给对象存储做去重和冷备。但如果数据保留期间还有被检索的可能我建议压缩等级不要超过10否则解压时那点延迟和CPU开销会让检索任务变得难受。5. 参数选择、配置细节与踩坑记录5.1 Zstandard的等级选择策略经过大量测试之后我把自己的参数选择策略总结成了一张非常简单的表业务类型压缩等级核心理由高吞吐实时管道zstd -1 或 -3压缩率明显优于LZ4速度可接受在线存储/读多写少zstd -3 到 -7压缩率不错解压速度快冷备归档/批量压缩zstd -10 到 -19存储成本优先CPU成本可容忍这里有一个很多人忽略的细节zstd的每个等级之间不是线性的性能变化。比如从3级升到5级压缩率收益可能只有1%CPU开销却涨了50%而从9级升到10级压缩率又能获得一个明显的跳升。因此没必要迷信最高等级找到收益曲线拐点才是关键。我的经验是大多数结构化数据在zstd -3到-7之间是性价比最高的区间低于-1会浪费zstd的机制优势高于-7则得不偿失。5.2 LZ4在流式压缩中的坑LZ4在使用中有几个细节容易踩坑。第一LZ4的块压缩模式block mode和流式压缩模式stream mode行为差异很大。块模式一次性处理完整个数据块适合已知长度的场景流式模式允许分多次输入数据但需要手动维护压缩状态。很多第一次用LZ4的人在流式压缩时忘记在数据段之间调用刷新函数导致解压端拿到不完整的数据流。第二个坑是LZ4的高压缩模式很容易让人产生错误预期。LZ4HC虽然在部分数据上能提升几个百分点但它的CPU开销曲线极其陡峭。我曾经在一个日志采集器上做过压测LZ4HC级别9的CPU占用是默认LZ4的20倍以上而压缩率提升不到10%。这个投入产出比在生产链路里非常不划算。第三个坑是版本兼容。LZ4的流式格式在早期版本里有过一些调整如果生产环境里压缩端和解压端使用的库版本不一致可能发生格式不兼容问题。我的建议是在依赖管理里锁死LZ4版本并做一次压缩解压的集成测试不要默认算法一样就一定能互相解。5.3 关于压缩上下文的实用建议Zstandard还有一个很有用的特性压缩上下文复用。如果你要压缩大量相似的小数据块反复创建和销毁压缩上下文会浪费不少CPU。正确的做法是创建一个zstd压缩上下文设置好等级和字典后反复使用。这样不仅能省下上下文初始化的开销还能让内部的哈希表历史数据对后续的压缩过程起到一定预热作用。我实测过复用上下文后压缩小数据块的吞吐量可以提升10%以上。解压侧也有对应的解压上下文。尤其是当你需要同时解压大量小块时为每个线程独立创建一个解压上下文可以避免锁竞争。在这个细节上踩过坑之后我养成了一个习惯任何压缩库的使用都要先想清楚上下文生命周期是每次新建还是线程内复用这比调整等级带来的收益更直接。5.4 哪些经验之谈其实是错的网上流传着一些关于压缩算法的说法听起来很有道理实际却需要用数据重新验证。第一个错误说法是zstd的压缩速度全面不如LZ4。在zstd -1时两者确实有差距但差距比很多人想象中小而一旦数据里重复度较高zstd -1的压缩率优势带来的传输时间节省往往能抵消甚至反超压缩速度的劣势。也就是说综合压缩传输解压全链路时间zstd经常是赢家。第二个错误说法是压缩等级越高越好。级别19对一个已经用级别3压过的数据再压缩通常只能再多压几个百分点但CPU时间可能膨胀几十倍。正确做法是先看数据本身的可压缩性再决定要不要上高等级。简单判断方法用级别3压一遍如果压缩率已经低于30%那级别19的空间就很小了如果压缩率还在60%以上说明数据里重复度低高等级的意义同样有限。第三个错误说法是解压速度不是选型重点。这个我前面已经反驳过。对读多写少的存储系统来说解压速度就是用户可感知的延迟。我有一次把一个对象存储的压缩方式从LZ4切到zstd -9存储用量下降了25%但读放大非常明显最终不得不把等级降到-7才达到延迟目标。这个教训告诉我压缩率优化必须压进整体延迟预算里看脱离了读路径谈压缩率都是数据陷阱。最后再分享一个我经历过的小案例。某个模拟项目需要把一批订单数据从关系数据库同步到数据仓库数据量约每天80GB。一开始用的LZ4同步窗口内CPU占用稳定但存储增量很扎眼。后来我把同步链路上的压缩改成zstd -3压缩率从45%降到30%同步时间反而略有下降因为写往目标存储的数据量少了。之后又在仓库落盘前的临时文件上改用zstd -10进一步把临时空间占用降了一半。整个过程只改了两行配置换来的是每月将近三成的存储成本下降。压缩算法的选择说到底就是在明确约束条件之后找到那个真正适合自己的工作点。希望这篇内容能帮你把约束条件看清楚少走几个弯路。