Google Snappy string 壓縮/解壓縮（Java）__Java

項目中遇到的壓縮/解壓縮需求應該是很多的，比如典型的考慮網路傳輸延時而對資料進行壓縮傳輸，又或者其他各種省空間儲存需求等。這次同樣是遇到了類似需求，在做一個爬蟲時，因為抓取項目還未確定，所以考慮將整個html頁面壓縮儲存於資料庫，於是又是各種google，最後不出意外的google到了google家的Snappy :-) 簡介

Snappy：Google開發的一個非常流行的壓縮演算法，它旨在提供速度與壓縮比都相對較優的壓縮演算法。雖然只是一個資料壓縮庫，它卻被Google用於許多內部項目，其中就包括BigTable，MapReduce和RPC。Google宣稱它在這個庫本身及其演算法做了資料處理速度上的最佳化，作為代價，並沒有考慮輸出大小以及和其他類似工具的相容性問題。Snappy特地為64位x86處理器做了最佳化，在單個Intel Core i7處理器核心上能夠達到至少每秒250MB的壓縮速率和每秒500MB的解壓速率。
總結copy過來的這一堆：Snappy不是壓縮率最高的，但是速度和效能表現很優秀，over。 使用

其實可用的壓縮演算法很多，而且壓縮率與速度比Snappy高的也大有人在，典型的如：lz4，常用的壓縮解壓縮演算法對比參見這兒。
至於我為什麼選擇了Snappy，就兩個字：簡單。哈哈。。
相比已經很簡單的lz4，Snappy的API更簡單，而且關鍵在解壓縮環節，Snappy使用直觀，不需要考慮壓縮包大小或是壓縮前大小，在某些環節更省心一些，當然細處並未評估，所以也就不做過多引導性的描述，還是應該根據具體項目需求選擇。
具體使用：

   public static  byte[] compressHtml(String html){        try {            return Snappy.compress(html.getBytes("UTF-8"));        } catch (IOException e) {            e.printStackTrace();            return null;        }    }    public static  String decompressHtml(byte[] bytes){        try {            return new String(Snappy.uncompress(bytes));        } catch (IOException e) {            e.printStackTrace();            return null;        }    }

丫的好像太簡單扼，都是一行，罷了罷了，大家還是到這兒來自己看API吧，尤其是file stream相關操作都有，又是一篇水文，謝謝點擊。

補充：實測Snappy與lz4： 待壓縮字串長度約50000 壓縮後：
Snappy 約19000 lz4 約16000 lz4 fast 約19000

The end!