我們知道壓縮算法的效果和性能與壓縮數據的類型和方式有很大的關系，光看別人的測試數據和基準是不夠的。功能開發有剛需，結合我們的使用場景來測試壹下吧。
令人驚訝的是，測量的結果比政府提供的要好，我們終於找到了我們的那杯茶。
英特爾酷睿i5-4570 CPU，3.20 GHz，8G內存
CentOS 7.0
對於幾種支持流寫的壓縮算法，使用相應的命令行工具進行壓縮測試。
除了snappy，各種壓縮算法/工具都支持設置壓縮級別。高水平意味著用更長的壓縮時間來換取更高的壓縮率。
654.38+0百萬行應用程序日誌文件，大小為977MB。
從上面可以看出:
Zstd在處理時間和壓縮比方面更勝壹籌。Snappy、LZ4和LZO的壓縮率都很低，但都非常快，zstd甚至比這些算法還要快。gzip的壓縮比遠高於lz4，而zstd的壓縮比是Gzip的兩倍。
如果上面的對比不是特別直觀的話，我們來介紹壹個創意指標(相對於互聯網上的其他壓縮算法，這個指標從來沒有用過):
表示每單位處理時間可以壓縮和刪除多少冗余數據。其中，權重系數用於指定壓縮率和壓縮速度哪個更重要。這裏我們認為兩者在我們的使用場景中同等重要，系數為1。
從這裏我們可以清楚地看到zstd > lz4 & gtlzo & gt爽快& gt& gt其他人。
對壹個1000行、大小約為1MB的文件進行壓縮測試，各種算法的壓縮比與壹個1GB的大文件相差無幾。
我們來比較壹下較小的數據量——10行日誌數據的壓縮比。雖然在我們的使用場景中沒有小數據的壓縮，但是我們還是很好奇zstd字典模式的效果。
最後壹組數據是zstd，用10000行日誌生成字典文件，用字典文件壓縮測試數據。
可以看出，除了zstd字典模式，在處理較小的數據時，各種壓縮算法的壓縮率都大大降低。不過zstd字典模式對壓縮比很有幫助。與gzip相比，壓縮比從1000行的1倍到10行的近3倍。
下壹篇文章將比較這些算法的golang開源庫的性能和壓縮比。敬請關註。