zstd，未来可期的数据压缩算法

Posted 2023-04-17

参考技术A 最近了解到了 zstd 这种新的压缩算法。不像lz4，lzo，snappy等近几年流行的压缩算法专注于压缩和解压缩性能，zstd在性能不错的同时号称压缩率跟Deflate（zip/gzip的算法）相当。下面是 官网 列出的数据：

我们知道，压缩算法的效果和性能跟被压缩的数据类型和模式有很大的关系，光看别人的测试数据、benchmark是不够的。正好有功能开发需要，于是结合我们的使用场景真实测试的一下。

惊喜的是，实测的结果比官方提供的还好，终于找到了我们的cup of tea。

Intel(R) Core(TM) i5-4570 CPU @ 3.20GHz, 8G内存

CentOS 7.0

对几种支持流式写入的压缩算法，使用对应的命令行工具进行压缩测试。

除了snappy，各种压缩算法/工具都支持设置压缩级别，高级别意味着以更长的压缩时间换取更高的压缩率。

100万行不重复的某个应用的日志文件，大小为977MB。

从上面可以看出：

zstd无论从处理时间还是压缩率来看都占优。snappy, lz4, lzo的压缩率较低，但压缩速度都很快，而zstd甚至比这些算法更快。Gzip的压缩率比lz4等高不少，而zstd的压缩率比gzip还提升一倍。

如果从上面的比较还不是特别直观的话，我们再引入一个创造性的指标（从网上其他压缩算法对比没有见过使用这项指标）：

代表单位处理时间可以压缩去掉多少冗余数据。其中 权重系数 用来指定压缩率和压缩速度哪个更重要，这里我们认为在我们的使用场景里两者同样重要，取系数为1。

从这里我们可以明显看出， zstd > lz4 > lzo > snappy >> 其他 。

对1000行、大小约为1MB的文件进行压缩测试，各种算法的压缩率跟1GB大文件的压缩率几乎一样。

下面再对更小的数据量——10行日志数据的压缩率进行对比。虽然我们的使用场景里没有对小数据量的压缩处理，但还是比较好奇zstd字典模式的效果。

其中最后一组数据为zstd使用10000行日志进行训练生成字典文件，并利用字典文件辅助压缩测试数据。

可以看出来，除了zstd字典模式外，各种压缩算法在处理更小的数据量时压缩率都下降很多。而zstd字典模式对压缩率带来帮助非常明显，与gzip对比，压缩率从1000行时相差1倍，到10行时变为了相差接近3倍。

下一篇文章将给大家对比这几种算法的golang开源库的性能和压缩率。敬请期待。

压缩算法性能对比

参考技术A 看一个压缩算法的优劣，有两个重要的指标：一个指标是压缩比，原先占 100 份空间的东西经压缩之后变成了占 20 份空间，那么压缩比就是 5，显然压缩比越高越好；另一个指标就是压缩 / 解压缩吞吐量，比如每秒能压缩或解压缩多少 MB 的数据。同样地，吞吐量也是越高越好。

从表中我们可以发现 zstd 算法有着最高的压缩比，而在吞吐量上的表现只能说中规中矩。

反观 LZ4 算法，它在吞吐量方面则是毫无疑问的执牛耳者。

GZIP、Snappy、LZ4 甚至是 zstd 的表现各有千秋。

但对于 Kafka 而言，它们的性能测试结果却出奇得一致，即在吞吐量方面：LZ4 > Snappy > zstd 和 GZIP；

而在压缩比方面，zstd > LZ4 > GZIP > Snappy。 如果网络不好且 CPU 资源够的话,建议使用 zstd 压缩

具体到物理资源，使用 Snappy 算法占用的网络带宽最多，zstd 最少，这是合理的，毕竟 zstd 就是要提供超高的压缩比；

在 CPU 使用率方面，各个算法表现得差不多，只是在压缩时 Snappy 算法使用的 CPU 较多一些，而在解压缩时 GZIP 算法则可能使用更多的 CPU。

https://blog.csdn.net/zhanglong_4444/article/details/103679803