snappy - 如何在 LZ4 和 Snappy 压缩之间做出决定？

Question

关闭。这个问题是opinion-based .它目前不接受答案。












想改善这个问题吗？更新问题，以便可以通过 editing this post 用事实和引文回答问题.

4 个月前关闭。




Improve this 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。忘记活泼。
一个异常(exception)可能是某些 Java 软件，它可能支持 snappy 但不支持 lz4。
一点历史和软件考古学
java软件有一个边缘情况。 Snappy 有一个更长时间的优化 Java 实现，特别是由 Kafka 驱动。您很有可能最终看到这篇文章，因为您正在研究调整 Kafka 压缩。
Kafka 很早就决定采用 snappy 压缩，并要求所有 kafka 客户端(所有语言)都支持 snappy。它插入了快速采用和进一步优化。
如果您看到旧的比较使活泼领先，例如这个 extensive Kafka benchmark from CloudFlare from 2018 .这样做的原因是因为文章很旧，而且当时 LZ4 没有得到同等支持/优化(CloudFlare 最终无法使用 lz4，因为当时并非所有客户端都支持它)。
将更多的压缩算法改造到现有系统中是一项艰巨的工作。现在应该支持 LZ4(和 ZSTD)，但您的里程可能会有所不同。您可能需要升级集群并升级客户端库。您可能会发现某些客户端库不支持它。 snappy 与 lz4 之间的区别很薄，如果您的任何一个工作正常，都不值得费心调整。
在侧节点上。如果您在多个数据中心运行并发现自己受到网络的严重限制，您应该查看 ZSTD，它具有更强的压缩能力(可以将网络流量减少 2 或 3)。
LZ4 现在已经成熟并且可以广泛使用，它在 2020 年之前没有那么多(与 java 之外的 snappy 相同)。许多软件通过采用 LZ4 获得了显着的性能改进，然后随着库的深度优化进一步改进。