tl;dr（太長不讀）：我們知道，壓縮演算法的效果和效能跟被壓縮的資料型別和模式有很大的關係，光看別人的測試資料、benchmark是不夠的。正好有功能開發需要，於是結合我們的使用場景真實測試的一下。
驚喜的是，實測的結果比官方提供的還好，終於找到了我們的cup of tea。
intel(r) core(tm) i5-4570 cpu @ 3.20ghz, 8g記憶體
centos 7.0
對幾種支援流式寫入的壓縮演算法，使用對應的命令列工具進行壓縮測試。
壓縮演算法
工具名稱
預設壓縮級別
版本安裝方法
deflate
gzip
51.5
centos自帶
snzip
n/a1.0.4
編譯安裝
lz4lz4
01.7.3
yum install lz4
lzolzop
02.06
yum install lzop
zstd
zstd
31.3.8
yum install zstd
100萬行不重複的某個應用的日誌檔案，大小為977mb。
從上面可以看出：
如果從上面的比較還不是特別直觀的話，我們再引入乙個創造性的指標（從網上其他壓縮演算法對比沒有見過使用這項指標）：
代表單位處理時間可以壓縮去掉多少冗餘資料。其中壓縮效率 = 權重係數 * 壓縮去掉的冗餘資料大小 / 壓縮時間權重係數用來指定壓縮率和壓縮速度哪個更重要，這裡我們認為在我們的使用場景裡兩者同樣重要，取係數為1。對1000行、大小約為1mb的檔案進行壓縮測試，各種演算法的壓縮率跟1gb大檔案的壓縮率幾乎一樣。
下面再對更小的資料量——10行日誌資料的壓縮率進行對比。雖然我們的使用場景裡沒有對小資料量的壓縮處理，但還是比較好奇zstd字典模式的效果。
其中最後一組資料為zstd使用10000行日誌進行訓練生成字典檔案，並利用字典檔案輔助壓縮測試資料。
可以看出來，除了zstd字典模式外，各種壓縮演算法在處理更小的資料量時壓縮率都下降很多。而zstd字典模式對壓縮率帶來幫助非常明顯，與gzip對比，壓縮率從1000行時相差1倍，到10行時變為了相差接近3倍。
zstd安裝 zstd，未來可期的資料壓縮演算法
tl dr 太長不讀 zstd是facebook在2016年開源的新無失真壓縮演算法，優點是壓縮率和壓縮 解壓縮效能都很突出。zstd還有乙個特別的功能，支援以訓練方式生成字典檔案，相比傳統壓縮方式能大大的提高小資料報的壓縮率。在過去的兩年裡，新版本的linux核心 http協議 以及一系列的大資料...
mysql 資料壓縮 mysql的資料壓縮效能對比
資料魔方需要的資料，一旦寫入就很少或者根本不會更新。這種資料非常適合壓縮以降低磁碟占用。mysql本身提供了兩種壓縮方式 archive引擎以及針對myisam引擎的myisampack方式。今天對這兩種方式分別進行了測試，對比了二者在磁碟占用以及查詢效能方面各自的優劣。至於為什麼做這個，你們應該懂...
hive的資料壓縮
在實際工作當中，hive當中處理的資料，一般都需要經過壓縮，前期我們在學習hadoop的時候，已經配置過hadoop的壓縮，我們這裡的hive也是一樣的可以使用壓縮來節省我們的mr處理的網路頻寬 壓縮格式 工具演算法 副檔名 是否可切分 default 無default deflate 否gzip ...