Infobright號稱數據壓縮比率是10:1到40:1。前面我們已經說過了Infobright的壓縮是根據DP里面的數據類型，系統自動選擇壓縮算法，并且自適應地調節算法的參數以達到最優的壓縮比。

先看看在我的實驗環境下的壓縮比率，如下圖所示：

相信讀者可以很清楚地看到，整體的壓縮比率是20.302。但是這里有一個誤區，這里的壓縮比率指的是數據庫中的原始數據大小/壓縮后的數據大小，而不是文本文件的物理數據大小/壓縮后的數據大小。很明顯前者會比后者大出不少。在我的實驗環境下，后者是7:1左右。一般來說文本數據存入數據庫之后大小會比原來的文本大不少，因為有些字段被設置了固定長度，占用了比實際更多的空間。還有就是數據庫里面會有很多的統計信息數據，其中就包括索引，這些統計信息數據占據的空間絕對不小。Infobright雖然沒有索引，但是它有KN數據，通常情況下KN數據大小占數據總大小的1%左右。

既然Infobright會根據具體的數據類型進行壓縮，那我們就看看不同的數據類型具有什么樣的壓縮比率。如下表所示：

首先看看Int類型的壓縮比率，結果是壓縮比率上Int<mediumint<smallint。細心地讀者會很容易發現tinyint的壓縮比率怎么會比int還小。數據壓縮比率除了和數據類型有關之外，還和數據的差異性有特別大關系，這是顯而易見。posFlag只有0，1，-1三種可能，這種數據顯然不可能取得很好的壓縮比率。

再看看act字段，act字段使用了comment lookup，比簡單的char類型具有更佳的壓縮比率和查詢性能。comment lookup的原理其實比較像位圖索引。對于comment lookup的使用下一章節將細細講述。

在所有的字段當中date字段的壓縮比率是最高的，最后數據的大小只有0.1M。varchar的壓縮比率就比較差了，所以除非必要，不然不建議使用varchar。

上面的數據很清楚地展示了Infobright強大的壓縮性能。在此再次強調，數據的壓縮不只是和數據類型有關，數據的差異程度起了特別大的作用。在選擇字段數據類型的時候，個人覺得性能方面的考慮應該擺在第一位。比如上面表中一些字段的選擇就可以優化，ip可以改為bigint類型，date甚至可以根據需要拆分成year/month/day三列。