​

作者：Ravi Malhotra  2022 年 2 月 8 日

联合作者：Manoj Iyer 和 Yichen Jia

由于云中管理着大量数据，因此需要在存储数据之前对其进行压缩，以实现存储介质的高效使用。已经开发了各种算法来对飞行中的各种数据类型进行压缩和解压缩。在本博客中，我们将介绍两种广受认可的算法——Zstandard 和 Snappy，并比较它们在 Arm 服务器上的性能。

背景

有各种类型的数据压缩算法——其中一些是根据数据类型定制的——例如，视频、音频、图像/图形。然而，大多数其他类型的数据需要一种通用的无损压缩算法，并且可以跨不同的数据集提供良好的压缩比。这些压缩算法可用于多个应用程序。

• 文件或对象存储系统，如 Ceph、OpenZFS、SquashFS

• 数据库或分析应用程序，如 MongoDB、Kafka、Hadoop、Redis 等。

• Web 或 HTTP–NGINX、curl、Django 等。

• 档案软件——tar、winzip 等。

• 其他几个用例，比如 Linux 内核压缩

压缩与速度

压缩算法面临的一个关键挑战是，它们是为实现更高的压缩率而优化，还是为以更高的速度压缩/解压缩而优化。其中一个优化了存储空间，而另一个有助于节省计算周期并降低操作延迟。有些算法，例如 Zstandard[1]和 zlib[2]，提供了多个预设，允许用户/应用程序根据使用情况选择自己的权衡。而另一些（例如 Snappy[3]）则是为速度而设计的。

Zstandard 是 Facebook 开发的一种开源算法，可以提供与 DEFLATE 算法相当的最大压缩比，但针对更高的速度进行了优化，尤其是用于解压缩。自 2016 年推出以来，它在多套应用程序中非常流行，并成为 Linux 内核的默认压缩算法。

Snappy 是由 Google 开发的开源算法，旨在以合理的压缩比优化压缩速度。它在数据库和分析应用程序中非常流行。

Arm 软件团队优化了这两种算法，以在基于 Arm Neoverse 内核的 Arm 服务器平台上实现高性能。这些优化使用 Neon 矢量引擎的功能来加速算法的某些部分。

性能比较

我们采用了 Zstandard 和 Snappy 算法的最新优化版本，并在 AWS（Amazon Web Services）上的类似云实例上对它们进行了基准测试。

• 2xlarge 实例——使用基于 Arm Neoverse N1 内核的 AWS Graviton2 

• 2xlarge 实例–使用 Intel Cascade Lake

两种算法都在两种不同的场景中进行了基准测试：

• 关注原始算法性能——我们使用 lzbench 工具对包含不同行业标准数据类型的 Silesia corpus 进行了测试。

• 流行的 NoSQL 数据库 MongoDB 的应用程序级性能——使用 YCSB 工具测试使用这些压缩算法对数据库操作吞吐量和延迟的影响，并测量数据库的整体压缩。

原始算法性能

带宽（速度）比较

该测试主要关注不同数据集的 16 个并行进程的原始聚合压缩/反压缩吞吐量。对于 Zstandard，我们观察到 C6g 实例压缩时的总体性能提升了 30-67%，解压缩时的整体性能提升了 11-35%。

考虑到 C6g 实例的价格降低了 20%，每 MB 压缩数据最多可节省 52%。

​

图 1:Zstd8 压缩吞吐量比较——C5 与 G6g

​

图 2:Zstd8 解压缩吞吐量比较——C5 与 G6g

使用 Snappy 作为压缩算法，我们观察到，与预期的 Zstandard 相比，Snappy 具有更高的压缩和相对类似的解压缩速度。总体而言，与 C5 相比，Snappy 在 C6g 实例的各种数据集上的表现要好 40-90%。

考虑到 C6g 实例的价格降低了 20%，每 MB 压缩数据可以节省 58%。

​

图 3：Snappy 压缩-C5 与 C6g

​

图 4：Snappy 解压缩-C5 与 C6g

压缩率

我们还比较了两种算法在 C6g 和 C5 实例上对不同数据集的压缩比。在这两种情况下，都获得了相同的压缩比，这表明该算法的运行效率达到了预期。

应用程序级性能

MongoDB WiredTiger 存储引擎支持几种压缩模式：snappy、zstd、zlib 等。这里我们正在测试压缩模式 snappy，zstd none。我们使用了一个由 10000 句英语文本组成的数据集，该数据集是使用 Python faker 随机生成的。

单独的 AWS 实例被用作测试对象和测试主机。文档被插入 MongoDB 数据库，占 5GB（近似值）的数据。使用的测试对象实例是 Arm（c6g.2xlarge）和 Intel（c5.2xlarge）。在 MongoDB 数据库中填充了 5GB 的数据后，我们使用“dbstat”命令来获取存储大小。

Snappy vs Zstandard –速度 vs 压缩

在 Snappy 和 Zstandard 之间，我们观察到 Zstandard 在压缩总体数据库大小方面比预期的更好。

​

图 5:MongoDB:数据库压缩比

Snappy 在插入操作中提供了更好的吞吐量，这是一种写（压缩）密集型操作。然而，涉及压缩和解压缩混合的读/修改/写操作在这两种算法之间几乎没有差异

​

图 6:MongoDB：插入吞吐量——Snappy 与 Zstd

​

图 7:MongoDB：读/修改/写吞吐量——Snappy 与 Zstd

结论

Zstandard 和 Snappy 等通用压缩算法可用于各种应用程序，在压缩不同类型的通用数据集方面非常通用。Zstandard 和 Snappy 都针对 Arm Neoverse 和 AWS Graviton2 进行了优化，与基于 Intel 的实例相比，我们观察到了两个关键结果。首先，与类似的基于 Intel 的实例类型相比，基于 Graviton2 的实例可以实现 11-90%的更好的压缩和解压缩性能。第二，基于 Graviton2 的实例可以将数据压缩成本降低一半。对于像 MongoDB 这样的实际应用程序，这些压缩算法只会给典型操作增加很少的开销，同时显著减少数据库大小。