作者：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这样的理论应用程序，这些压缩算法只会给典型操作减少很少的开销，同时显著缩小数据库大小。