開源MySQL高效數據倉庫處理計劃：Infobright具體引見。本站提示廣大學習愛好者：（開源MySQL高效數據倉庫處理計劃：Infobright具體引見）文章只能為提供參考，不一定能成為您想要的結果。以下是開源MySQL高效數據倉庫處理計劃：Infobright具體引見正文
Infobright是一款基於奇特的專利常識網格技巧的列式數據庫。Infobright是開源的MySQL數據倉庫處理計劃，引入了列存儲計劃，高強度的數據緊縮，優化的統計盤算(相似sum/avg/group by之類)，infobright 是基於mysql的，但不裝mysql亦可，由於它自己就自帶了一個。mysql可以粗分為邏輯層和物理存儲引擎，infobright重要完成的就是一個存儲引擎，但由於它本身存儲邏輯跟關系型數據庫基本分歧，所以，它不克不及像InnoDB那樣直接作為插件掛接到mysql，它的邏輯層是mysql的邏輯層加上它本身的優化器。
Infobright特點
長處：
Infobright的價值
Infobright的實用場景
限制：
與MySQL比較
infobright有兩個宣布版：開源的ICE及閉源商用的IEE。ICE供給了足夠用的功效，但不克不及 INSERT，DELETE，UPDATE，只能LOAD DATA INFILE。IEE除供給更充足的功效外，聽說查詢速度也要更快。
社區ICE版，國際各年夜企業均有測試，投入生成體系的較少，重要有以下緣由：
ICE與IEE版本差別
IEE包括針對年夜多半企業任務需求的附加特征，如：更好的查詢機能、DML語句支撐、散布式導入等。別的，IEE版本還包括了必定級其余Infobright原廠或署理商的支撐救濟辦事、產物培訓等。
架構
基於MySQL的外部架構 – Infobright采用與MySQL類似的外部架構，上面是Infobright的架構圖：
灰色部門是mysql原本的模塊，白色與藍色部門則是 infobright本身的。
Infobright跟mysql一樣的兩層構造：
Infobright的模塊
Data Pack（數據塊）緊縮層
存儲引擎最底層是一個個的Data Pack（數據塊）。每個Pack裝著某一列的64K個元素，一切數據依照如許的情勢打包存儲，每個數據塊停止類型相干的緊縮（即依據分歧數據類型采取分歧的緊縮算法），緊縮比很高。它下層的緊縮器與解緊縮器就做了這個工作。
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三列。
Knowledge Grid（常識網格）
緊縮層再向上就是infobright最主要的概念：Knowledge Grid（常識網格）這也是infobright廢棄索引卻能運用於年夜量數據查詢的基本。Knowledge Grid構架是Infobright高機能的主要緣由。它包括兩類結點：
Knowledge Grid可分為四部門，DPN、Histogram、CMAP、P-2-P。
DPN如上所述。
Histogram用來進步數字類型（好比date，time，decimal）的查詢的機能。Histogram是裝載數據的時刻就發生的。DPN中有mix、max，Histogram中把Min-Max分紅1024段，假如Mix_Max規模小於1024的話，每段就是就是一個零丁的值。這個時刻KN就是一個數值能否在以後段的二進制表現。
Histogram的感化就是疾速斷定以後DP能否知足查詢前提。如上圖所示，好比select id from customerInfo where id>50 and id<70。那末很輕易便可以獲得以後DP不知足前提。所以Histogram關於那種數字限制的查詢可以或許很有用地削減查詢DP的數目。
CMAP是針關於文本類型的查詢，也是裝載數據的時刻就發生的。CMAP是統計以後DP內，ASCII在1-64地位湧現的情形。以下圖所示
好比下面的圖解釋了A在文本的第二個、第三個、第四個地位歷來沒有湧現過。0表現沒有湧現，1表現湧現過。查詢中文本的比擬歸根究底照樣依照字節停止比擬，所以依據CMAP可以或許很好地進步文本查詢的機能。
Pack-To-Pack是Join操作的時刻發生的，它是表現join的兩個DP中操作的兩個列之間關系的位圖，也就是二進制表現的矩陣。
粗拙集（Rough Sets）是Infobright的焦點技巧之一。Infobright在履行查詢的時刻會依據常識收集（Knowledge Grid）把DP分紅三類：
案例：
SELECT COUNT(*) FROM employees WHERE salary > 100000 AND age < 35 AND job = ‘IT' AND city = ‘San Mateo';
從下面的剖析可以曉得，Infobright可以或許很高效地履行一些查詢，並且履行的時刻where語句的辨別度越高越好。where辨別度高可以更准確地確認能否是相干DP或許是不相干DP亦或是可以DP，盡量削減DP的數目、削減解緊縮帶來的機能消耗。在做前提斷定的應用，普通會用到上一章所講到的Histogram和CMAP，它們可以或許有用地進步查詢機能。多表銜接的時刻道理也是類似的。先是應用Pack-To-Pack發生join的那兩列的DP之間的關系。好比：SELECT MAX(X.D) FROM T JOIN X ON T.B = X.C WHERE T.A > 6。Pack-To-Pack發生T.B和X.C的DP之間的關系矩陣M。假定T.B的第一個DP和X.C的第一個DP之間有元故舊叉，那末M[1,1]=1，不然M[1,1]=0。如許就有用地削減了join操作時DP的數目。後面降到懂得緊縮，趁便提一提DP的緊縮。每一個DP中的64K個元素被當做是一個序列，個中一切的null的地位都邑被零丁存儲，然後其他的non-null的數據會被緊縮。數據的緊縮跟數據的類型有關，infobright會依據數據的類型選擇緊縮算法。infobright會自順應地調理算法的參數以到達最優的緊縮比。
Knowledge Grid照樣比擬龐雜的，外面還有許多細節的器械，可以參考官方的白皮書和Brighthouse: an analytic data warehouse for ad-hoc queries這篇論文。
comment lookup的應用
後面曾經剖析了Infobright的構架，扼要引見了Infobright的緊縮進程和任務道理。如今來評論辯論查詢優化的成績。
1）設置裝備擺設情況：在Linux上面，Infobright情況的設置裝備擺設可以依據README裡的請求，設置裝備擺設brighthouse.ini文件。
2）拔取高效的數據類型
Infobright外面支撐一切的MySQL原本的數據類型。個中Integer類型比其他數據類型加倍高效。盡量應用以下的數據類型：
效力比擬低的、不推舉應用的數據類型有：
Infobright數據類型應用的一些經歷和留意點：
3）應用comment lookup
comment lookup只能顯式地應用在char或許varchar下面。Comment Lookup可以削減存儲空間，進步緊縮率，對char和varchar字段采取comment lookup可以進步查詢效力。Comment Lookup完成機制很像位圖索引，完成上應用冗長的數值類型替換char字段已獲得更好的查詢機能和緊縮比率。Comment Lookup的應用除對數據類型有請求，對數據也有必定的請求。普通請求數據種別的總數小於10000而且以後列的單位數目/種別數目年夜於10。Comment Lookup比擬合適年紀，性別，省分這一類型的字段。
comment lookup應用很簡略，在創立數據庫表的時刻以下界說便可：
act char(15) comment 'lookup',
part char(4) comment 'lookup',
4）盡可能有序地導入數據
後面剖析過Infobright的構架，每列分紅n個DP，每一個DPN列面存儲著DP的一些統計信息。有序地導入數據可以或許使分歧的DP的DPN內的數據差別化更顯著。好比按時光date次序導入數據，那末前一個DP的max（date）<=下一個DP的min(date)，查詢的時刻就可以夠削減可疑DP，進步查詢機能。換句話說，有序地導入數據就是使DP外部數據加倍集中，而不再那末疏散。
5）應用高效的查詢語句。
這裡觸及的內容比擬多了，總結以下：
Infobright履行查詢語句的時刻，年夜部門的時光都是花在優化階段。Infobright優化器固然曾經很壯大，然則編寫查詢語句的時刻許多的細節成績照樣須要法式員留意。
Infobright導入對象
參考鏈接：
