AWS Graviton2上数据压缩算法性能比较

作者: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%。

AWS Graviton2上数据压缩算法性能比较_第1张图片

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

AWS Graviton2上数据压缩算法性能比较_第2张图片

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

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

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

AWS Graviton2上数据压缩算法性能比较_第3张图片

图3:Snappy 压缩-C5与C6g

AWS Graviton2上数据压缩算法性能比较_第4张图片

图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在压缩总体数据库大小方面比预期的更好。

AWS Graviton2上数据压缩算法性能比较_第5张图片

图5:MongoDB:数据库压缩比

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

AWS Graviton2上数据压缩算法性能比较_第6张图片

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

AWS Graviton2上数据压缩算法性能比较_第7张图片

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

结论

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

你可能感兴趣的:(数据应用性能)