我們知道壓縮算法的效果和性能與壓縮數據的類型和模式有很大關系，光看別人的測試數據和基準測試是不夠的。功能開發有剛需，結合我們的使用場景來測試壹下。
令人驚訝的是，測量結果比政府提供的結果更好，我們終於找到了我們的那杯茶。
英特爾酷睿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 & gt；lzo & gt爽快& gt& gt其他人。
對壹個1000行、大小約為1MB的文件的壓縮測試表明，各種算法的壓縮比與壹個1GB的大文件的壓縮比幾乎相同。
讓我們比較較小的數據量-10行日誌數據的壓縮率。雖然在我們的使用場景中沒有對小數據進行壓縮，但我們仍然對zstd字典模式的效果感到好奇。
最後壹組數據是zstd，它使用10000行日誌生成字典文件，並使用字典文件壓縮測試數據。
可以看到，除了zstd字典模式外，各種壓縮算法在處理較小數據時的壓縮率都大大降低。但是，zstd字典模式對壓縮比非常有幫助。與gzip相比，壓縮比從1000行的1倍提高到10行的近3倍。
下壹篇文章將比較golang開源庫的這些算法的性能和壓縮比。敬請關註。