本文目錄一覽：
zstd，未來可期的數據壓縮演算法
最近了解到了 zstd 這種新的壓縮演算法。不像lz4，lzo，snappy等近幾年流行的壓縮演算法專註於壓縮和解壓縮性能，zstd在性能不錯的同時號稱壓縮率跟Deflate（zip/gzip的演算法）相當。下面是 官網 列出的數據：
我們知道，壓縮演算法的效果和性能跟被壓縮的數據類型和模式有很大的關係，光看別人的測試數據、benchmark是不夠的。正好有功能開發需要，於是結合我們的使用場景真實測試的一下。
驚喜的是，實測的結果比官方提供的還好，終於找到了我們的cup of tea。
Intel(R) Core(TM) i5-4570 CPU @ 3.20GHz, 8G內存
CentOS 7.0
對幾種支持流式寫入的壓縮演算法，使用對應的命令行工具進行壓縮測試。
除了snappy，各種壓縮演算法/工具都支持設置壓縮級別，高級別意味著以更長的壓縮時間換取更高的壓縮率。
100萬行不重複的某個應用的日誌文件，大小為977MB。
從上面可以看出：
zstd無論從處理時間還是壓縮率來看都佔優。snappy, lz4, lzo的壓縮率較低，但壓縮速度都很快，而zstd甚至比這些演算法更快。Gzip的壓縮率比lz4等高不少，而zstd的壓縮率比gzip還提升一倍。
如果從上面的比較還不是特別直觀的話，我們再引入一個創造性的指標（從網上其他壓縮演算法對比沒有見過使用這項指標）：
代表單位處理時間可以壓縮去掉多少冗餘數據。其中 權重係數 用來指定壓縮率和壓縮速度哪個更重要，這裡我們認為在我們的使用場景里兩者同樣重要，取係數為1。
從這裡我們可以明顯看出， zstd lz4 lzo snappy 其他 。
對1000行、大小約為1MB的文件進行壓縮測試，各種演算法的壓縮率跟1GB大文件的壓縮率幾乎一樣。
下面再對更小的數據量——10行日誌數據的壓縮率進行對比。雖然我們的使用場景里沒有對小數據量的壓縮處理，但還是比較好奇zstd字典模式的效果。
其中最後一組數據為zstd使用10000行日誌進行訓練生成字典文件，並利用字典文件輔助壓縮測試數據。
可以看出來，除了zstd字典模式外，各種壓縮演算法在處理更小的數據量時壓縮率都下降很多。而zstd字典模式對壓縮率帶來幫助非常明顯，與gzip對比，壓縮率從1000行時相差1倍，到10行時變為了相差接近3倍。
下一篇文章將給大家對比這幾種演算法的golang開源庫的性能和壓縮率。敬請期待。
原創文章，作者：小藍，如若轉載，請註明出處：https://www.506064.com/zh-tw/n/279844.html
微信掃一掃 
支付寶掃一掃 