專案中遇到的壓縮/解壓縮需求應該是很多的，比如典型的考慮網路傳輸延時而對資料進行壓縮傳輸，又或者其他各種省空間儲存需求等。這次同樣是遇到了類似需求，在做一個爬蟲時，因為抓取專案還未確定，所以考慮將整個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!