如何在 LZ4 和 Snappy 压缩之间做出选择？

Question

我需要在配置“众所周知的应用程序”时选择压缩算法。

此外，作为我日常工作的一部分，我的公司正在开发处理大量数据的分布式应用程序。我们一直在研究压缩数据以尝试减少网络带宽，但我们在使用什么算法方面遇到了困难。有太多的选择。

我如何在 LZ4 和 Snappy 之间做出选择？

Answer 1

TL;DR 答案始终是 LZ4。

首先我们来讨论一下它们的共同点

它们都是设计为在压缩和解压缩时以“线”速度（每核 1 GB/s 的量级）运行的算法。

主要用例是在将数据写入磁盘或网络（通常运行速度远低于 GB/s）之前应用压缩。压缩数据以减少 IO，这是透明的，因为压缩算法非常快 - 比从介质读取/写入更快 -。

这两种算法均出现于 2010 年代初，可以认为是相对较新的算法。新技术的普及和优化的稳定库在所有流行语言中的出现都需要十年的时间。

它们现在都已广泛使用，并且拥有优秀的库（我是在 2021 年写这篇文章），但几年前情况并非如此。

它们都以相似的速度和相似的压缩比进行压缩（LZ4 的解压速度要快得多）。

作为历史参考，还有第三种算法，称为 LZO，它在同一联盟中发挥作用，它要老得多（1996 年的论文）并且没有广泛使用。

其次，我们来讨论一下差异。

虽然它们都非常快，但 LZ4（稍微）更快更强，因此应该是首选。

尤其是在解压速度方面，LZ4更是快了数倍。

LZ 算法的解压缩速度通常非常快（它们可以在恒定时间内运行），这是它们受欢迎的原因之一。LZ4 的构建是为了充分利用该属性并使 CPU/内存带宽饱和。

另外，LZ4是可调的，压缩级别可以从1到16微调，如果你有空闲的CPU，这可以让你有更强的压缩。如果所有支持 LZ4 的软件都将压缩级别公开为设置，那就太好了，但并非所有软件都这样做。

当然，“越快越好”，但是，您可能会想问，在这样的速度下，这真的很重要吗？我们愿意为每个核心提供 1 GB/s 还是 2 GB/s？

答案是肯定的，因为效果很明显，并且在线压缩应该与其运行的硬件保持同步，包括 NVMe SSD（750+ MB/s）和本地网络（1.25+ GB/s）。

对于客户端-服务器应用程序，服务器将从许多客户端接收和解压缩许多流，解压缩的成本可能会很快增加。一个实际的例子是像 Kafka 这样的分布式队列，它必须动态解压缩/重新压缩数据，以适应许多客户端可以发送/接收的任何格式。

另一个主要用例是数据库，数据可以在存储到磁盘之前进行压缩。一个著名的例子是 ElasticSearch，当您对最后一个月的日志运行查询时，数据使用开箱即用的 LZ4 进行压缩（内部数据是不可变的/仅附加的，这与压缩和日志配合得很好）它可以动态解压缩 TB 级的数据（1 GB/s 听起来不再那么快了;)）

三、库的兼容性和可用性

最后但并非最不重要的一点是，您需要找到一些库来支持您打算使用的任何压缩。

或者，如果我们正在讨论调整第三方应用程序/数据库，您将需要查看可以配置哪些算法。

截至 2021 年，当我撰写此答案时，LZ4（和 snappy（和 ZSTD））的所有流行语言都有成熟的库可用。

如果您正在开发可以从线速压缩中受益的软件，那么您应该使用 LZ4。如果您正在寻找更强的压缩（尽管速度较慢），您可以考虑 ZSTD。忘记敏捷吧。

一个例外可能是某些 Java 软件，它可能支持 snappy 但不支持 lz4。

一些历史和软件考古学

java 软件存在一种边缘情况。Snappy 拥有优化的 Java 实现时间更长，特别是由 Kafka 驱动。您很有可能会写这篇文章，因为您正在研究调整 Kafka 压缩。

Kafka 很早就决定采用 snappy 压缩，并要求所有 kafka 客户端（所有语言）都支持 snappy。它推动了快速采用和进一步优化。

如果您看到旧的比较，例如2018 年 CloudFlare 的广泛 Kafka 基准测试。这样做的原因是因为这篇文章很旧，并且当时 LZ4 没有得到同等的支持/优化（CloudFlare 最终无法使用 lz4，因为当时并非所有客户端都支持它）。

在现有系统中改造更多的压缩算法是一项艰巨的工作。现在应该支持 LZ4（和 ZSTD），但您的里程可能会有所不同。您可能需要升级集群并升级客户端库。您可能会发现某些客户端库不支持它。snappy 和 lz4 之间的区别很薄，如果你的任何一个都能正常工作，那么就不值得费力去调整。

在侧面节点上。如果您运行多个数据中心并发现自己受到网络的严重限制，您应该看看 ZSTD，它具有更强的压缩能力（可以减少 2 或 3 倍的网络流量）。

LZ4 现在已经成熟并广泛使用，2020 年之前还没有那么多（与 java 之外的 snappy 相同）。许多软件通过采用 LZ4 看到了显着的性能改进，然后随着库的深度优化而进一步改进。