infobright是開源的MySQL數據倉庫解決方案，引入了列存儲方案，高強度的數據壓縮，最佳化的統計計算。
基本介紹
- 中文名：Infobright
- 外文名：Infobright
- 基於：mysql
- 粗分為：邏輯層和物理存儲引擎
- 優點：高壓縮比率
- 數據類型：TINYINT
概述,優點,架構,數據類型,
概述
Infobright是開源的MySQL數據倉庫解決方案，引入了列存儲方案，高強度的數據壓縮，最佳化的統計計算(類似sum/avg/group by之類)，
infobright 是基於mysql的，但不裝mysql亦可，因為它本身就自帶了一個。mysql可以粗分為邏輯層和物理存儲引擎，infobright主要實現的就是一個存儲引擎，但因為它自身存儲邏輯跟關係型資料庫根本不同，所以，它不能像InnoDB那樣直接作為外掛程式掛接到mysql，它的邏輯層是mysql的邏輯 層加上它自身的最佳化器。
優點
1、高壓縮比率，平均壓縮比可達10：1，甚至可以達到40:1，我用infobright把3.1G的數據存成不足300M。
2、列存儲，即使數據量十分巨大，查詢速度也很快。用於數據倉庫，處理海量數據沒一套可不行。
3、不需要建索引，就避免了維護索引及索引隨著數據膨脹的問題。把每列數據分塊壓縮存放，每塊有知識格線節點記錄塊內的統計信息，代替索引，加速搜 索。
4、單一台伺服器可以高效地讀寫30T數據。具有可擴展性，這裡是指對於同樣的查詢，當數據量是10T時，它耗費的時間不應該比1T數據量時慢太 多，基本是一個數量級內。
架構
下面是Infobright的架構圖：
infobright架構圖灰色部分是mysql原有的模組，白色與藍色部分則是 infobright自身的。
系統結構分析：
Infobright與其他分散式大數據產品，譬如Yonghong Z-DataMart一樣是採用MPP分散式架構，可以有多節點組成集群。節點內是跟mysql一樣的兩層結構，上面的邏輯層處理查詢邏輯，下面的是存儲引擎。邏輯層右端的loader與unloader是infobright的數據導入導出模組，也即處理SQL語句里LOAD DATA INFILE … 與SELECT … INTO FILE任務，由於infobright面向的是海量數據環境，所以這個數據導入導出模組是一個獨立的服務，並非直接使用mysql的模組。邏輯層的infobright最佳化器包在mysql查詢最佳化器的外面，如下面將會提到的，因為它的存儲層有一些特殊結構，所以查詢最佳化方式也跟 mysql有很大差異。存儲層最底層是一個個的Data Pack（數據塊）。每一個Pack裝著某一列的64K個元素，所有數據按照這樣的形式打包存儲，每一個數據塊進行類型相關的壓縮（即根據不同數據類型采 用不同的壓縮算法），壓縮比很高。它上層的壓縮器與解壓縮器就做了這個事情。壓縮層再向上就是infobright最重要的概念：Knowledge Grid（知識格線），這也是infobright放棄索引卻能套用於大量數據查詢的基礎。它包含兩類結點：每個Data Pack Node（知識節點）對應於一個Data Pack，存儲該Data Pack的一些統計信息，如min, max, avg, null的個數，甚至不同值的量等等；Knowledge Node則存儲了一些更高級的統計信息，以及與其它表的連線信息，這裡面的信息有些是數據載入時已經算好的，有些是隨著查詢進行而計算的，所以說是具備一 定的“智慧型”的。
數據類型
Infobright裡面支持所有的MySQL原有的數據類型。其中Integer類型比其他數據類型更加高效。儘可能使用以下的數據類型：
TINYINT，SMALLINT，MEDIUMINT，INT，BIGINT
DECIMAL（儘量減少小數點位數）
DATE ，TIME
效率比較低的、不推薦使用的數據類型有：
BINARY VARBINARY
FLOAT
DOUBLE
VARCHAR
TINYTEXT TEXT
Infobright數據類型使用的一些經驗和注意點：
（1）Infobright的數值類型的範圍和MySQL有點不一樣，比如Infobright的Int的最小值是-2147483647，而MySQl的Int最小值應該是-2147483648。其他的數值類型都存在這樣的問題。
（2）能夠使用小數據類型就使用小數據類型，比如能夠使用SMALLINT就不適用INT，這一點上Infobright和MySQL保持一致。
（3）避免效率低的數據類型，像TEXT之類能不用就不用，像FLOAT儘量用DECIMAL代替，但是需要權衡畢竟DECIMAL會損失精度。
（4）儘量少用VARCHAR，在MySQL裡面動態的Varchar性能就不強，所以儘量避免VARCHAR。如果適合的話可以選擇把VARCHAR改成CHAR存儲甚至轉成INTEGER類型。VARCHAR的優勢在於分配空間的長度可變，既然Infobright具有那么優秀的壓縮性能，個人認為完全可以把VARCHAR轉成CHAR。CHAR會具有更好的查詢和壓縮性能。
（5）能夠使用INT的情況儘量使用INT，很多時候甚至可以把一些CHAR類型的數據往整型轉化。比如搜尋日誌裡面的客戶永久id、客戶id等等數據就可以用BIGINT存儲而不用CHAR存儲。其實把時間分割成year、month、day三列存儲也是很好的選擇。在我能見到的系統裡面時間基本上是使用頻率最高的欄位，提高時間欄位的查詢性能顯然是非常重要的。當然這個還是要根據系統的具體情況，做數據分析時有時候很需要MySQL的那些時間函式。
（6）varchar和char欄位還可以使用comment lookup，comment lookup能夠顯著地提高壓縮比率和查詢性能。
