我們知道，壓縮算法的效果和性能跟被壓縮的數據類型和模式有很大的關系，光看別人的測試數據、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開源庫的性能和壓縮率。敬請期待。