Sysbase可以說是列式數(shù)據(jù)庫的先驅，Sysbase IQ 15 就是Sybase 目前***的列式數(shù)據(jù)庫。它具有強大的功能，包括數(shù)據(jù)的快速加載、超高速的分析性能、強大的業(yè)務智能分析、領先的數(shù)據(jù)建模能力等等。 Infobright是一個基于MySQL的數(shù)據(jù)倉庫系統(tǒng)，共工的不周山的blog上有挺詳細的介紹。

同樣是列式數(shù)據(jù)庫，但是Infobright和Sybase IQ系列還是有很大的不同。Infobright采用的Knowledge Grid來組織數(shù)據(jù)，Infobright內(nèi)部是沒有索引，就這點就節(jié)省了不少的空間。而Sybase IQ系列還是使用了索引，而這些索引我個人的理解就是位圖索引的改進版。白皮書上說，Infobright的數(shù)據(jù)壓縮比可以是10：1到40：1，個人拿龐大的日志數(shù)據(jù)庫做了個小小實驗，感覺壓縮也沒那么夸張。如果依據(jù)位圖索引的思想，每列數(shù)據(jù)的相似度越高就會具有越高的壓縮比。Infobright應該也是滿足這一點的，但是具體Knowledge Grid內(nèi)部如何實現(xiàn)還不清楚，有待繼續(xù)考究。  

Infobright的優(yōu)點有很多，簡單列舉如下：  

Infobright的優(yōu)點：

（1）高壓縮比率

（2）快速響應復雜的分析查詢語句

（3）隨著數(shù)據(jù)庫的逐漸增大，查詢和裝載性能基本保持穩(wěn)定

（4）沒有特殊的數(shù)據(jù)倉庫模型（比如星狀模型、雪花模型）要求

（5）無需要物化視圖、復雜的數(shù)據(jù)分區(qū)策略、索引

（6）實施和管理簡單，需要極少的管理

（7）和眾多的BI套件相容，比如Pentaho、Cognos、Jaspersoft。

Infobright有兩個版本ICE和IEE，目前ICE的版本是3.3.1，支持64位Linux和32位windows。ICE不支持DML，也就是不支持insert、update等操作。

粗糙集（Rough Sets）是Infobright的核心技術之一。Infobright在執(zhí)行查詢的時候會根據(jù)知識網(wǎng)絡（Knowledge Grid）把DP分成三類：

相關的DP（Relevant Packs），滿足查詢條件限制的DP

不相關的DP（Irrelevant Packs），不滿足查詢條件限制的DP

可疑的DP（Suspect Packs），DP里面的數(shù)據(jù)部分滿足查詢條件的限制

下面是一個案例：

如圖所示，每一列總共有5個DP，其中限制條件是A>6。所以A1、A2、A4就是不相關的DP，A3是相關的DP，A5是可疑的DP。那么執(zhí)行查詢的時候只需要計算B5中滿足條件的記錄的和然后加上Sum（B3），Sum（B3）是已知的。此時只需要解壓縮B5這個DP。從上面的分析可以知道，Infobright能夠很高效地執(zhí)行一些查詢，而且執(zhí)行的時候where語句的區(qū)分度越高越好。where區(qū)分度高可以更精確地確認是否是相關DP或者是不相關DP亦或是可以DP，盡可能減少DP的數(shù)量、減少解壓縮帶來的性能損耗。在做條件判斷的使用，一般會用到上一章所講到的Histogram和CMAP，它們能夠有效地提高查詢性能。

多表連接的的時候原理也是相似的。先是利用Pack-To-Pack產(chǎn)生join的那兩列的DP之間的關系。

比如：SELECT MAX(X.D) FROM T JOIN X ON T.B = X.C WHERE T.A > 6。Pack-To-Pack產(chǎn)生T.B和X.C的DP之間的關系矩陣M。假設T.B的***個DP和X.C的***個DP之間有元素交叉，那么M[1,1]=1，否則M[1,1]=0。這樣就有效地減少了join操作時DP的數(shù)量。

前面降到了解壓縮，順便提一提DP的壓縮。每個DP中的64K個元素被當成是一個序列，其中所有的null的位置都會被單獨存儲，然后其余的non-null的數(shù)據(jù)會被壓縮。數(shù)據(jù)的壓縮跟數(shù)據(jù)的類型有關，infobright會根據(jù)數(shù)據(jù)的類型選擇壓縮算法。infobright會自適應地調(diào)節(jié)算法的參數(shù)以達到***的壓縮比。

原文鏈接：http://blog.chinaunix.net/u2/72637/showart_2306093.html