作者:大圓那些事| 文章可以轉載，請以超鏈接形式標明文章原始出處和作者信息

網址:http://www.cnblogs.com/panfeng412/archive/2012/12/24/applications-scenario-summary-of-compression-algorithms.html

GZIP、LZO、Zippy/Snappy是常用的幾種壓縮算法，各自有其特點，因此適用的應用場景也不盡相同。這里結合相關工程實踐的情況，做一次小結。

壓縮算法的比較

以下是Google幾年前發布的一組測試數據（數據有些老了，有人近期做過測試的話希望能共享出來）：

Algorithm	% remaining	Encoding	Decoding
GZIP	13.4%	21 MB/s	118 MB/s
LZO	20.5%	135 MB/s	410 MB/s
Zippy/Snappy	22.2%	172 MB/s	409 MB/s

注：來自《HBase: The Definitive Guide》

其中：

1）GZIP的壓縮率最高，但是其實CPU密集型的，對CPU的消耗比其他算法要多，壓縮和解壓速度也慢；

2）LZO的壓縮率居中，比GZIP要低一些，但是壓縮和解壓速度明顯要比GZIP快很多，其中解壓速度快的更多；

3）Zippy/Snappy的壓縮率最低，而壓縮和解壓速度要稍微比LZO要快一些。

BigTable和HBase中壓縮算法的選擇

BigTable中采用的是Zippy算法，目標是達到盡可能快的壓縮和解壓速度，同時減少對CPU的消耗。

HBase中，在Snappy發布之前（Google 2011年對外發布Snappy），采用的LZO算法，目標和BigTable類似；在Snappy發布之后，建議采用Snappy算法（參考《HBase: The Definitive Guide》），具體可以根據實際情況對LZO和Snappy做過更詳細的對比測試后再做選擇。

實際項目中的實踐經驗

項目中使用clearspring公司開源的基數估計的概率算法：stream-lib，用于解決去重計算問題，如UV計算等，它的特點在于：

1）一個UV的計算，可以限制在一個固定大小的位圖空間內完成（不同大小，對應不同的誤差率），如8K，64K；

2）不同的位圖可以進行合并操作，得到合并后的UV。

當系統中維護的位圖越多的時候，不管是在內存中，還是在存儲系統（MySQL、HBase等）中，都會占用相當大的存儲空間。因此，需要考慮采取合適的算法來壓縮位圖。這里分為以下兩類情況：

1）當位圖在內存中時，此時壓縮算法的選擇，必須有盡可能快的壓縮和解壓速度，同時不能消耗過多CPU資源，因此，適合使用LZO或Snappy這樣的壓縮算法，做到快速的壓縮和解壓；

2）當位圖存儲到DB中時，更關注的是存儲空間的節省，要有盡可能高的壓縮率，因此，適合使用GZIP這樣的壓縮算法，同時在從內存Dump到DB的過程也可以減少網絡IO的傳輸開銷。

總結的話

以上是對GZIP、LZO、Zippy/Snappy壓縮算法特點的概括比較，以及一些實踐上的方法。如有不對之處，歡迎大家指正，討論。

分享到：QQ空間新浪微博騰訊微博人人網更多0

分類:HBase,開發經驗
標簽:GZIP,LZO,Zippy/Snappy

作者：Leo_wl
　　　　出處：http://www.cnblogs.com/Leo_wl/
　　　　本文版權歸作者和博客園共有，歡迎轉載，但未經作者同意必須保留此段聲明，且在文章頁面明顯位置給出原文連接，否則保留追究法律責任的權利。
版權信息

總結

以上是生活随笔為你收集整理的GZIP、LZO、Zippy/Snappy压缩算法应用场景小结的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。