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

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

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

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

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

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

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

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