作者：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 這樣的實際應用程式，這些壓縮演算法只會給典型操作增加很少的開銷，同時顯著減少資料庫大小。