zstd压缩算法的一些使用案例
2019-03-25 15:16:51 
阿炯
Arch Linux 计划将 zstd 作为默认压缩算法
Linux 5.7 F2FS 文件系统添加对 Zstd 压缩算法的支持
AWS 压缩算法从 gzip 切换到 zstd，节约 30% 存储空间
Linux内核自2017年11月以来就包含了Zstandard (4.14版本) ，作为btrfs和squashfs文件系统的压缩方法。
2017年，Allan Jude将Zstandard集成到FreeBSD内核中，用于概念验证OpenZFS压缩方法。随后它被集成为核心转储（英语：Core dump，用户程序和内核崩溃）的压缩器选项。AWS Redshift和RocksDB数据库支持使用Zstandard进行字段压缩。
2018年3月，Canonical在Ubuntu Linux发行版中测试了默认使用zstd作为deb包压缩方法。与deb包的xz压缩相比，级别19的zstd解压缩速度要快得多，但代价是包文件大小增加了6%。Debian开发者Ian Jackson希望再等几年再官方采用zstd来打包。
2018年，该算法被发布为 RFC 8478，它还定义了相关的媒体类型“application/zstd”、文件扩展名“zst”和HTTP内容编码“zstd”。
2019年10月，随着pacman 5.2包管理器的发布，Arch Linux增加了对zstd包压缩方法的支持，2020年1月，官方仓库中的包从xz转换为zstd。Arch采用zstd -c -T0 --ultra -20 -，与xz相比，所有压缩包的大小增加了0.8%，解压速度提高了1300%；当使用多个线程时，解压内存增加了50 MiB，压缩内存会增加，但会随着使用的线程数而扩展。在.NSZ / .XCZ文件格式中完整实现了该算法以及多种压缩等级，由任天堂Switch混合游戏机的自制社区开发。
Arch Linux 计划将 zstd 作为默认压缩算法
Arch Linux 维护人员比较了不同的压缩算法，基于速度的大幅提升，最终计划使用 zstd 取代 devtools 中的默认压缩算法。
当前的压缩方法是`xz -c -z -`，它是单线程的，速度很慢，所以团队希望用更快的算法来将其替换。
虽然多线程 xz 早已出现，但是在一些意外情况下无法完成功能，所以很快就被淘汰了。 新的想法是使用 Facebook 的 zstd 算法，zstd 又叫 Zstandard，它是一种快速无损压缩算法，主要应用于 zlib 级别的实时压缩场景，并且具有更好的压缩比。
zstd 还可以以压缩速度为代价提供更强的压缩比，速度与压缩权衡可通过小增量进行配置。经过一系列测试后 Arch 团队得出结论，理想的 zstd 级别将是'-18'，`zstd -c -T0 -18 -`相比`xz -c -z -`的优势是：
压缩时速度大幅提高
解压速度大幅提高
稳定、可重复的多线程
解压速度的提高将大大提高 pacman 的包安装速度。目前 zstd 已经处在项目主干上，等待发布。详情查看邮件说明。
Linux 5.7 F2FS 文件系统添加对 Zstd 压缩算法的支持
Linux 5.6 引入了可选的 F2FS 透明数据压缩支持，并通过 LZO 和 LZ4 压缩算法实现，2020年3月，Linux 5.7内核正在支持 Zstd 压缩算法。F2FS 的维护者 Jaegeuk Kim 合并了一个由华为工程师提交的用于支持 Zstd 压缩算法的补丁，以及对文件系统级别的压缩支持。这就意味着在 Linux Kernel 5.7 及更高版本上，在挂载 F2FS 文件系统时设置 compress_algorithm=zstd 可以启用 Zstd 压缩功能。
对 Zstd 的支持是华为提交的许多补丁之一，在这些补丁中，值得关注的是默认压缩算法已从 LZO 转换为 LZ4。也就是说，目前仍支持 LZO 算法，但默认情况下使用的是 LZ4。因为开发者发现 LZ4 可提供类似 LZO 的压缩率，但解压速度要快得多。最后Linux 5.7合并窗口将在4月初启动，而目前这项工作已作为 F2FS 开发树的一部分在排队中。
Zstd 显著提升 Linux 内核镜像压缩效率，从 5.9 开始有望将其合并进主线
Facebook 工程师 Nick Terrell 在2020年7月向 Linux 内核提交了使用 Zstd 压缩 Linux 内核镜像的补丁，这些补丁显示了使用 Zstd 对内核、ramdisk 和 initramfs 进行压缩操作具备巨大潜力。Nick 发现在 x86_64 硬件上，当初始 RAM 文件系统将压缩算法从 XZ 切换到 Zstd 时，解压时间从 12 秒下降到只需 3 秒，此次切换整体上还给系统的引导时间带来了两秒的改进。同样看到较大改进的场景包括从 LZMA 切换到 Zstd，Nick 在切换至 Zstd 的 Facebook 服务器上发现解压时间从 12 秒下降到了 8 秒。相关基准测试结果可查看这里。
至于压缩率，Zstd 的压缩率要比内核使用的 Gzip 低，但比 XZ 和 LZMA 高，Zstd 是除了 LZ4 之外，解压速度最快的算法。根据目前的情况来看，内核对 Zstd 的支持有望在下一个版本中(Linux Kernel 5.9)实现。一旦 Zstd 进入内核主线，Nick 的后续计划是放弃对 BZ2 和 LZMA(1) 的支持；这将有助于清理更多的内核代码，因为 Bzip2 和 LZMA 目前并没有在内核树之外的其他地方使用。相关的总结如下：
- compression level, predictably, has a huge impact on compression time.
- compression level has virtually no impact on decompression time for lz4, zstd, and some effect on others. interestingly, xz decompresses slightly faster at higher compression levels (perhaps cache-related).
- gzip compresses slightly faster than zstd at medium compression levels.
- bzip2 sucks: slow compression, very slow decompression, poor ratio.
- lzma decompresses slightly faster than xz, but is also slightly larger.
- xz is smallest but with very slow compression and decompression.
- lz4 decompresses fastest.
- zstd is a good balanced default.
- 7z is much faster than xz, even with wine overhead.
2021年9月末消息，虽然 Linux 内核越来越多地支持使用 Zstd 进行各种压缩，但目前内核中的 Zstd 代码属于比较古老的版本。例如 Linux 内核使用 Zstd 压缩模块、固件和内核镜像，甚至像 Btrfs Zstd 文件系统这样的实现。来自 Facebook 的 Zstd 维护者 Nick Terrell 积极从上游为 Linux 内核使用的 Zstd 更新代码，让内核的实现可以更接近上游并且更易于维护。但这项工作实在过于棘手，最终结果是停滞不前。所以从现在的情况来看，从 Zstd 上游重新构建代码的工作已暂停。
不过 Nick Terrell 最近分享了他正在开发一个新的补丁系列，表示很快就会在这方面采取行动，可能会及时赶上下一个内核合并窗口。如果 Nick Terrell 能够按他计划的时间完成此项任务，Linux 内核代码至少会达到基于 Zstd 1.5 的状态，并且能够为利用这种压缩算法的功能提供一个良好的性能升级。
AWS 压缩算法从 gzip 切换到 zstd，节约 30% 存储空间
亚马逊前副总裁 Adrian cockcroft 于2022年8月下旬在推特上爆料，称 AWS 的压缩算法从 gzip 切换到 zstd 后，节省了海量内存，压缩后的 S3 存储减少了大约 30% ，节省的空间可达 EB 规模（1 EB = 1024 PB = 1024 * 1024 TB）。其员工对该发言进行了补充，称亚马逊改变的不是客户存储的数据的压缩方式，而是 S3 自身存储服务数据（主要是日志）的方式 —— S3 自身从 gzip 日志切换到 ztsd 日志，使得存储成本降低 30% 。
但亚马逊并没有发布变更压缩技术相关的公告，有细心的网友发现了亚马逊 S3 在 2021 年 11 月末曾有过一次降价 31% 的操作，与降低的 30% 存储成本刚好可以对应上，看来这些不知耻的云厂商也开始留意这些小的工具实现来为其赚取更多的利润了。
Linux 5.7 F2FS 文件系统添加对 Zstd 压缩算法的支持
AWS 压缩算法从 gzip 切换到 zstd，节约 30% 存储空间
Linux内核自2017年11月以来就包含了Zstandard (4.14版本) ，作为btrfs和squashfs文件系统的压缩方法。
2017年，Allan Jude将Zstandard集成到FreeBSD内核中，用于概念验证OpenZFS压缩方法。随后它被集成为核心转储（英语：Core dump，用户程序和内核崩溃）的压缩器选项。AWS Redshift和RocksDB数据库支持使用Zstandard进行字段压缩。
2018年3月，Canonical在Ubuntu Linux发行版中测试了默认使用zstd作为deb包压缩方法。与deb包的xz压缩相比，级别19的zstd解压缩速度要快得多，但代价是包文件大小增加了6%。Debian开发者Ian Jackson希望再等几年再官方采用zstd来打包。
2018年，该算法被发布为 RFC 8478，它还定义了相关的媒体类型“application/zstd”、文件扩展名“zst”和HTTP内容编码“zstd”。
2019年10月，随着pacman 5.2包管理器的发布，Arch Linux增加了对zstd包压缩方法的支持，2020年1月，官方仓库中的包从xz转换为zstd。Arch采用zstd -c -T0 --ultra -20 -，与xz相比，所有压缩包的大小增加了0.8%，解压速度提高了1300%；当使用多个线程时，解压内存增加了50 MiB，压缩内存会增加，但会随着使用的线程数而扩展。在.NSZ / .XCZ文件格式中完整实现了该算法以及多种压缩等级，由任天堂Switch混合游戏机的自制社区开发。
Arch Linux 计划将 zstd 作为默认压缩算法
Arch Linux 维护人员比较了不同的压缩算法，基于速度的大幅提升，最终计划使用 zstd 取代 devtools 中的默认压缩算法。
当前的压缩方法是`xz -c -z -`，它是单线程的，速度很慢，所以团队希望用更快的算法来将其替换。
虽然多线程 xz 早已出现，但是在一些意外情况下无法完成功能，所以很快就被淘汰了。 新的想法是使用 Facebook 的 zstd 算法，zstd 又叫 Zstandard，它是一种快速无损压缩算法，主要应用于 zlib 级别的实时压缩场景，并且具有更好的压缩比。
zstd 还可以以压缩速度为代价提供更强的压缩比，速度与压缩权衡可通过小增量进行配置。经过一系列测试后 Arch 团队得出结论，理想的 zstd 级别将是'-18'，`zstd -c -T0 -18 -`相比`xz -c -z -`的优势是：
压缩时速度大幅提高
解压速度大幅提高
稳定、可重复的多线程
解压速度的提高将大大提高 pacman 的包安装速度。目前 zstd 已经处在项目主干上，等待发布。详情查看邮件说明。
Linux 5.7 F2FS 文件系统添加对 Zstd 压缩算法的支持
Linux 5.6 引入了可选的 F2FS 透明数据压缩支持，并通过 LZO 和 LZ4 压缩算法实现，2020年3月，Linux 5.7内核正在支持 Zstd 压缩算法。F2FS 的维护者 Jaegeuk Kim 合并了一个由华为工程师提交的用于支持 Zstd 压缩算法的补丁，以及对文件系统级别的压缩支持。这就意味着在 Linux Kernel 5.7 及更高版本上，在挂载 F2FS 文件系统时设置 compress_algorithm=zstd 可以启用 Zstd 压缩功能。
对 Zstd 的支持是华为提交的许多补丁之一，在这些补丁中，值得关注的是默认压缩算法已从 LZO 转换为 LZ4。也就是说，目前仍支持 LZO 算法，但默认情况下使用的是 LZ4。因为开发者发现 LZ4 可提供类似 LZO 的压缩率，但解压速度要快得多。最后Linux 5.7合并窗口将在4月初启动，而目前这项工作已作为 F2FS 开发树的一部分在排队中。
Zstd 显著提升 Linux 内核镜像压缩效率，从 5.9 开始有望将其合并进主线
Facebook 工程师 Nick Terrell 在2020年7月向 Linux 内核提交了使用 Zstd 压缩 Linux 内核镜像的补丁，这些补丁显示了使用 Zstd 对内核、ramdisk 和 initramfs 进行压缩操作具备巨大潜力。Nick 发现在 x86_64 硬件上，当初始 RAM 文件系统将压缩算法从 XZ 切换到 Zstd 时，解压时间从 12 秒下降到只需 3 秒，此次切换整体上还给系统的引导时间带来了两秒的改进。同样看到较大改进的场景包括从 LZMA 切换到 Zstd，Nick 在切换至 Zstd 的 Facebook 服务器上发现解压时间从 12 秒下降到了 8 秒。相关基准测试结果可查看这里。
至于压缩率，Zstd 的压缩率要比内核使用的 Gzip 低，但比 XZ 和 LZMA 高，Zstd 是除了 LZ4 之外，解压速度最快的算法。根据目前的情况来看，内核对 Zstd 的支持有望在下一个版本中(Linux Kernel 5.9)实现。一旦 Zstd 进入内核主线，Nick 的后续计划是放弃对 BZ2 和 LZMA(1) 的支持；这将有助于清理更多的内核代码，因为 Bzip2 和 LZMA 目前并没有在内核树之外的其他地方使用。相关的总结如下：
- compression level, predictably, has a huge impact on compression time.
- compression level has virtually no impact on decompression time for lz4, zstd, and some effect on others. interestingly, xz decompresses slightly faster at higher compression levels (perhaps cache-related).
- gzip compresses slightly faster than zstd at medium compression levels.
- bzip2 sucks: slow compression, very slow decompression, poor ratio.
- lzma decompresses slightly faster than xz, but is also slightly larger.
- xz is smallest but with very slow compression and decompression.
- lz4 decompresses fastest.
- zstd is a good balanced default.
- 7z is much faster than xz, even with wine overhead.
2021年9月末消息，虽然 Linux 内核越来越多地支持使用 Zstd 进行各种压缩，但目前内核中的 Zstd 代码属于比较古老的版本。例如 Linux 内核使用 Zstd 压缩模块、固件和内核镜像，甚至像 Btrfs Zstd 文件系统这样的实现。来自 Facebook 的 Zstd 维护者 Nick Terrell 积极从上游为 Linux 内核使用的 Zstd 更新代码，让内核的实现可以更接近上游并且更易于维护。但这项工作实在过于棘手，最终结果是停滞不前。所以从现在的情况来看，从 Zstd 上游重新构建代码的工作已暂停。
不过 Nick Terrell 最近分享了他正在开发一个新的补丁系列，表示很快就会在这方面采取行动，可能会及时赶上下一个内核合并窗口。如果 Nick Terrell 能够按他计划的时间完成此项任务，Linux 内核代码至少会达到基于 Zstd 1.5 的状态，并且能够为利用这种压缩算法的功能提供一个良好的性能升级。
AWS 压缩算法从 gzip 切换到 zstd，节约 30% 存储空间
亚马逊前副总裁 Adrian cockcroft 于2022年8月下旬在推特上爆料，称 AWS 的压缩算法从 gzip 切换到 zstd 后，节省了海量内存，压缩后的 S3 存储减少了大约 30% ，节省的空间可达 EB 规模（1 EB = 1024 PB = 1024 * 1024 TB）。其员工对该发言进行了补充，称亚马逊改变的不是客户存储的数据的压缩方式，而是 S3 自身存储服务数据（主要是日志）的方式 —— S3 自身从 gzip 日志切换到 ztsd 日志，使得存储成本降低 30% 。
但亚马逊并没有发布变更压缩技术相关的公告，有细心的网友发现了亚马逊 S3 在 2021 年 11 月末曾有过一次降价 31% 的操作，与降低的 30% 存储成本刚好可以对应上，看来这些不知耻的云厂商也开始留意这些小的工具实现来为其赚取更多的利润了。