共计 2362 个字符,预计需要花费 6 分钟才能阅读完成。
作者: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 这样的理论应用程序,这些压缩算法只会给典型操作减少很少的开销,同时显著缩小数据库大小。