Infobright是一款基于獨(dú)特的專利知識網(wǎng)格技術(shù)的列式數(shù)據(jù)庫。Infobright是開源的MySQL數(shù)據(jù)倉庫解決方案，引入了列存儲方案，高強(qiáng)度的數(shù)據(jù)壓縮，優(yōu)化的統(tǒng)計(jì)計(jì)算(類似sum/avg/group by之類)，infobright 是基于mysql的，但不裝mysql亦可，因?yàn)樗旧砭妥詭Я艘粋€(gè)。mysql可以粗分為邏輯層和物理存儲引擎，infobright主要實(shí)現(xiàn)的就是一個(gè)存儲引擎，但因?yàn)樗陨泶鎯壿嫺P(guān)系型數(shù)據(jù)庫根本不同，所以，它不能像InnoDB那樣直接作為插件掛接到mysql，它的邏輯層是mysql的邏輯層加上它自身的優(yōu)化器。

Infobright特征

優(yōu)點(diǎn)：

1. 大數(shù)據(jù)量查詢性能強(qiáng)勁、穩(wěn)定：百萬、千萬、億級記錄數(shù)條件下，同等的SELECT查詢語句，速度比MyISAM、InnoDB等普通的MySQL存儲引擎快5～60倍。高效查詢主要依賴特殊設(shè)計(jì)的存儲結(jié)構(gòu)對查詢的優(yōu)化，但這里優(yōu)化的效果還取決于數(shù)據(jù)庫結(jié)構(gòu)和查詢語句的設(shè)計(jì)。
2. 存儲數(shù)據(jù)量大：TB級數(shù)據(jù)大小，幾十億條記錄。數(shù)據(jù)量存儲主要依賴自己提供的高速數(shù)據(jù)加載工具（百G/小時(shí)）和高數(shù)據(jù)壓縮比（>10:1）
3. 高數(shù)據(jù)壓縮比：號稱平均能夠達(dá)到 10:1 以上的數(shù)據(jù)壓縮率。甚至可以達(dá)到40:1，極大地節(jié)省了數(shù)據(jù)存儲空間。高數(shù)據(jù)壓縮比主要依賴列式存儲和 patent-pending 的靈活壓縮算法.
4. 基于列存儲：無需建索引，無需分區(qū)。即使數(shù)據(jù)量十分巨大，查詢速度也很快。用于數(shù)據(jù)倉庫，處理海量數(shù)據(jù)沒一套可不行。不需要建索引，就避免了維護(hù)索引及索引隨著數(shù)據(jù)膨脹的問題。把每列數(shù)據(jù)分塊壓縮存放，每塊有知識網(wǎng)格節(jié)點(diǎn)記錄塊內(nèi)的統(tǒng)計(jì)信息，代替索引，加速搜 索。
5. 快速響應(yīng)復(fù)雜的聚合類查詢：適合復(fù)雜的分析性SQL查詢，如SUM, COUNT, AVG, GROUP BY

Infobright的價(jià)值

1. 節(jié)約設(shè)計(jì)開銷。沒有復(fù)雜的數(shù)據(jù)倉庫模型設(shè)計(jì)要求(比如星狀模型、雪花模型)，無需要物化視圖、數(shù)據(jù)分區(qū)、索引建立
2. 節(jié)省存儲資源。高壓縮比率通常是10:1，某些應(yīng)用可能達(dá)到40:1
3. 集成利用廣泛。和眾多的BI套件相容，比如Pentaho、Cognos、Jaspersof
4. 降低運(yùn)維成本。隨著數(shù)據(jù)庫的逐漸增大，查詢和裝載性能持續(xù)保持穩(wěn)定，實(shí)施和管理簡單，需要極少的管理
5. 商業(yè)保證。第一個(gè)商業(yè)支持的開源倉儲分析數(shù)據(jù)庫，是Oracle/MySQL 官方推薦的倉儲集成架構(gòu)

Infobright的適用場景

1. 大數(shù)據(jù)量的分析應(yīng)用。網(wǎng)頁/在線分析、移動(dòng)分析、客戶行為分析、分析營銷和廣告
2. 日志/事件管理系統(tǒng)。電信詳單分析和報(bào)告、系統(tǒng)/網(wǎng)絡(luò) 安全認(rèn)證記錄
3. 數(shù)據(jù)集市。企事業(yè)單位特定數(shù)據(jù)倉庫、為中小企業(yè)提供數(shù)據(jù)倉庫
4. 嵌入式分析。為獨(dú)立軟件供應(yīng)商/ SaaS供應(yīng)商提供嵌入式分析應(yīng)用

限制：

1. 不支持?jǐn)?shù)據(jù)更新：社區(qū)版Infobright只能使用“LOAD DATA INFILE”的方式導(dǎo)入數(shù)據(jù)，不支持INSERT、UPDATE、DELETE。這使對數(shù)據(jù)的修改變得很困難，這樣就限制了它作為實(shí)時(shí)數(shù)據(jù)服務(wù)的數(shù)據(jù)倉庫來使用。
2. 不支持高并發(fā)：只能支持10多個(gè)并發(fā)查詢，雖然單庫 10 多個(gè)并發(fā)對一般的應(yīng)用來說也足夠了，但較低的機(jī)器利用率對投資者來說總是一件不爽的事情，特別是在并發(fā)小請求較多的情況下。
3. 沒有提供主從備份和橫向擴(kuò)展的功能。如果沒有主從備份，想做備份的話，也可以主從同時(shí)加載數(shù)據(jù)，但只能校驗(yàn)最終的數(shù)據(jù)一致性，使得從機(jī)在數(shù)據(jù)加載時(shí)停服務(wù)的時(shí)間較長；橫向擴(kuò)展方面，它本身就不是分布式的存儲系統(tǒng)。

與MySQL對比

1. infobright適用于數(shù)據(jù)倉庫場合：即非事務(wù)、非實(shí)時(shí)、非多并發(fā)；分析為主；存放既定的事實(shí)，例如日志，或匯總的大量的數(shù)據(jù)。所以它并不適合于應(yīng)對來自網(wǎng)站用戶的請求。實(shí)際上它取一條記錄比mysql要慢很多，但它取100W條記錄會(huì)比mysql快。
2. mysql的總數(shù)據(jù)文件占用空間通常會(huì)比實(shí)際數(shù)據(jù)多，因?yàn)樗€有索引。infobright的壓縮能力很強(qiáng)大，按列按不同類型的數(shù)據(jù)來壓縮。
3. 服務(wù)形式與接口跟mysql一致，可以用類似mysql的方式啟用infobright服務(wù)，然后原來連接mysql的應(yīng)用程序都可以以類似的方式連接與查詢infobright。這對熟練mysql者來說是個(gè)福音，學(xué)習(xí)成本基本為0。

infobright有兩個(gè)發(fā)布版：開源的ICE及閉源商用的IEE。ICE提供了足夠用的功能，但不能 INSERT，DELETE，UPDATE，只能LOAD DATA INFILE。IEE除提供更充分的功能外，據(jù)說查詢速度也要更快。

社區(qū)ICE版，國內(nèi)各大企業(yè)均有測試，投入生成系統(tǒng)的較少，主要有以下原因：

1. 對DML、alter語句限制
2. 需定時(shí)增量load導(dǎo)出導(dǎo)入
3. 自帶的MyISAM難以支持高并發(fā)，若想充分利用服務(wù)器資源，需開啟另外的MySQL實(shí)例
4. 對中文等多字節(jié)文字支持不好
5. 僅支持單核調(diào)度
6. 缺少原廠的支持

ICE與IEE版本區(qū)別

IEE包含針對大多數(shù)企業(yè)工作需求的附加特性，如：更好的查詢性能、DML語句支持、分布式導(dǎo)入等。另外，IEE版本還包含了一定級別的Infobright原廠或代理商的支持救援服務(wù)、產(chǎn)品培訓(xùn)等。

1. 明顯的查詢性能差異。雖然IEE和ICE版本均具有明顯超出例如Oracle、SQL Server、MySQL等行式數(shù)據(jù)庫的查詢性能，但I(xiàn)EE還要比ICE版本快50-500%。這個(gè)明顯差距來自于IEE核心引擎中特有的——多線程調(diào)度模塊(自IEE3.5引入).而在ICE中，一個(gè)獨(dú)立的查詢只能使用單個(gè)CPU核心，其他的查詢進(jìn)程只能使用其他核心。對于需要篩選和區(qū)分大量數(shù)據(jù)的復(fù)雜查詢，使用IEE多線程調(diào)度模塊可以顯著地節(jié)約查詢時(shí)間。
2. 支持DML語句。IEE支持標(biāo)準(zhǔn)的SQL 數(shù)據(jù)操作語言，使用insert、update、delete操控?cái)?shù)據(jù)。而ICE只支持Load data infile進(jìn)行數(shù)據(jù)導(dǎo)入，任何數(shù)據(jù)的變化都需要重新導(dǎo)入全部數(shù)據(jù)。DML語句的使用會(huì)降低數(shù)據(jù)查詢性能，隨次數(shù)遞增。
3. 支持DDL語句。包括alter table rename,add column,drop column（但是列操作只能對最后列生效）
4. 支持Hadoop接口（通過DLP）
5. 高級復(fù)制和高可用。IEE版本包含主從功能，基于SQL statement
6. 更簡易的導(dǎo)入和更快的導(dǎo)入速度。IEE支持分布式導(dǎo)入工具-DLP；且包含標(biāo)準(zhǔn)的MySQL原生loader，用于處理一些復(fù)雜數(shù)據(jù)的導(dǎo)入，另一方面也說明IBloader的容錯(cuò)性較差
7. Load或DML同時(shí)的一致性查詢
8. 支持臨時(shí)表
9. 其他商業(yè)授權(quán)，售后支持等

架構(gòu)

基于MySQL的內(nèi)部架構(gòu) – Infobright采取與MySQL相似的內(nèi)部架構(gòu)，下面是Infobright的架構(gòu)圖：

灰色部分是mysql原有的模塊，白色與藍(lán)色部分則是 infobright自身的。

Infobright跟mysql一樣的兩層結(jié)構(gòu)：

• 邏輯層：處理查詢邏輯（服務(wù)及應(yīng)用管理）,邏輯層右端的loader與unloader是infobright的數(shù)據(jù)導(dǎo)入導(dǎo)出模塊，也即處理SQL語句里L(fēng)OAD DATA INFILE … 與SELECT … INTO FILE任務(wù)，由于infobright面向的是海量數(shù)據(jù)環(huán)境，所以這個(gè)數(shù)據(jù)導(dǎo)入導(dǎo)出模塊是一個(gè)獨(dú)立的服務(wù)，并非直接使用mysql的模塊。邏輯層的infobright優(yōu)化器包在mysql查詢優(yōu)化器的外面，如下面將會(huì)提到的，因?yàn)樗拇鎯佑幸恍┨厥饨Y(jié)構(gòu)，所以查詢優(yōu)化方式也跟 mysql有很大差異。
• 存儲引擎：Infobright的默認(rèn)存儲引擎是brighthouse，但是Infobright還可以支持其他的存儲引擎，比如MyISAM、MRG_MyISAM、Memory、CSV。Infobright通過三層來組織數(shù)據(jù)，分別是DP(Data Pack)、DPN（Data Pack Node）、KN（Knowledge Node）。而在這三層之上就是無比強(qiáng)大的知識網(wǎng)絡(luò)（Knowledge Grid）。

Infobright的模塊

1. Optimizer優(yōu)化器。最小化的解壓縮數(shù)據(jù)，有效提高執(zhí)行計(jì)劃。
2. Knowledge Grid知識網(wǎng)格。存儲元數(shù)據(jù)、列信息、表關(guān)系，數(shù)據(jù)塊分布狀態(tài)統(tǒng)計(jì)信息，同等查詢狀態(tài)緩存信息
3. Data Pack數(shù)據(jù)塊。真實(shí)數(shù)據(jù)壓縮存放位置，按照數(shù)據(jù)存儲塊保存

Data Pack（數(shù)據(jù)塊）壓縮層

存儲引擎最底層是一個(gè)個(gè)的Data Pack（數(shù)據(jù)塊）。每一個(gè)Pack裝著某一列的64K個(gè)元素，所有數(shù)據(jù)按照這樣的形式打包存儲，每一個(gè)數(shù)據(jù)塊進(jìn)行類型相關(guān)的壓縮（即根據(jù)不同數(shù)據(jù)類型采用不同的壓縮算法），壓縮比很高。它上層的壓縮器與解壓縮器就做了這個(gè)事情。

Infobright號稱數(shù)據(jù)壓縮比率是10:1到40:1。前面我們已經(jīng)說過了Infobright的壓縮是根據(jù)DP里面的數(shù)據(jù)類型，系統(tǒng)自動(dòng)選擇壓縮算法，并且自適應(yīng)地調(diào)節(jié)算法的參數(shù)以達(dá)到最優(yōu)的壓縮比。先看看在實(shí)驗(yàn)環(huán)境下的壓縮比率，如下圖所示：

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

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

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

再看看act字段，act字段使用了comment lookup，比簡單的char類型具有更佳的壓縮比率和查詢性能。comment lookup的原理其實(shí)比較像位圖索引。對于comment lookup的使用下一章節(jié)將細(xì)細(xì)講述。在所有的字段當(dāng)中date字段的壓縮比率是最高的，最后數(shù)據(jù)的大小只有0.1M。varchar的壓縮比率就比較差了，所以除非必要，不然不建議使用varchar。

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

Knowledge Grid（知識網(wǎng)格）

壓縮層再向上就是infobright最重要的概念：Knowledge Grid（知識網(wǎng)格）這也是infobright放棄索引卻能應(yīng)用于大量數(shù)據(jù)查詢的基礎(chǔ)。Knowledge Grid構(gòu)架是Infobright高性能的重要原因。它包含兩類結(jié)點(diǎn)：

1. Data Pack Node（數(shù)據(jù)塊節(jié)點(diǎn)）：Data Pack Node和Data Pack是一一對應(yīng)的關(guān)系。DPN記錄著每一個(gè)DP里面存儲和壓縮的一些統(tǒng)計(jì)數(shù)據(jù)，包括最大值（max）、最小值（min）、null的個(gè)數(shù)、單元總數(shù)count、sum。avg等等。至不同值的量等等；Knowledge Node則存儲了一些更高級的統(tǒng)計(jì)信息，以及與其它表的連接信息，這里面的信息有些是數(shù)據(jù)載入時(shí)已經(jīng)算好的，有些是隨著查詢進(jìn)行而計(jì)算的，所以說是具備一 定的“智能”的。
2. Knowledge Node里面存儲著指向DP之間或者列之間關(guān)系的一些元數(shù)據(jù)集合，比如值發(fā)生的范圍（MIin_Max）、列數(shù)據(jù)之間的關(guān)聯(lián)。大部分的KN數(shù)據(jù)是裝載數(shù)據(jù)的時(shí)候產(chǎn)生的，另外一些事是查詢的時(shí)候產(chǎn)生。

Knowledge Grid可分為四部分，DPN、Histogram、CMAP、P-2-P。

DPN如上所述。

Histogram用來提高數(shù)字類型（比如date，time，decimal）的查詢的性能。Histogram是裝載數(shù)據(jù)的時(shí)候就產(chǎn)生的。DPN中有mix、max，Histogram中把Min-Max分成1024段，如果Mix_Max范圍小于1024的話，每一段就是就是一個(gè)單獨(dú)的值。這個(gè)時(shí)候KN就是一個(gè)數(shù)值是否在當(dāng)前段的二進(jìn)制表示。

Histogram的作用就是快速判斷當(dāng)前DP是否滿足查詢條件。如上圖所示，比如select id from customerInfo where id>50 and id<70。那么很容易就可以得到當(dāng)前DP不滿足條件。所以Histogram對于那種數(shù)字限定的查詢能夠很有效地減少查詢DP的數(shù)量。

CMAP是針對于文本類型的查詢，也是裝載數(shù)據(jù)的時(shí)候就產(chǎn)生的。CMAP是統(tǒng)計(jì)當(dāng)前DP內(nèi)，ASCII在1-64位置出現(xiàn)的情況。如下圖所示

比如上面的圖說明了A在文本的第二個(gè)、第三個(gè)、第四個(gè)位置從來沒有出現(xiàn)過。0表示沒有出現(xiàn)，1表示出現(xiàn)過。查詢中文本的比較歸根究底還是按照字節(jié)進(jìn)行比較，所以根據(jù)CMAP能夠很好地提高文本查詢的性能。

Pack-To-Pack是Join操作的時(shí)候產(chǎn)生的，它是表示join的兩個(gè)DP中操作的兩個(gè)列之間關(guān)系的位圖，也就是二進(jìn)制表示的矩陣。

• 存儲在memory中，作用域在一個(gè)Sission中
• 提高JOIN查詢性能，無論是新建還是復(fù)用的

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

1. 相關(guān)的DP（Relevant Packs），滿足查詢條件限制的DP
2. 不相關(guān)的DP（Irrelevant Packs），不滿足查詢條件限制的DP
3. 可疑的DP（Suspect Packs），DP里面的數(shù)據(jù)部分滿足查詢條件的限制

案例：

1. 查找包含salary > 100000的數(shù)據(jù)包
2. 查找包含age < 35的數(shù)據(jù)包
3. 查找包含job = 'IT'的數(shù)據(jù)包
4. 查找包含city = ‘San Mateo'的數(shù)據(jù)包
5. 去除所有與檢索條件不相干的標(biāo)記
6. 最后在確定的數(shù)據(jù)包內(nèi)解壓縮相關(guān)數(shù)據(jù)
7. 執(zhí)行檢索

從上面的分析可以知道，Infobright能夠很高效地執(zhí)行一些查詢，而且執(zhí)行的時(shí)候where語句的區(qū)分度越高越好。where區(qū)分度高可以更精確地確認(rèn)是否是相關(guān)DP或者是不相關(guān)DP亦或是可以DP，盡可能減少DP的數(shù)量、減少解壓縮帶來的性能損耗。在做條件判斷的使用，一般會(huì)用到上一章所講到的Histogram和CMAP，它們能夠有效地提高查詢性能。多表連接的時(shí)候原理也是相似的。先是利用Pack-To-Pack產(chǎn)生join的那兩列的DP之間的關(guān)系。比如：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之間的關(guān)系矩陣M。假設(shè)T.B的第一個(gè)DP和X.C的第一個(gè)DP之間有元素交叉，那么M[1,1]=1，否則M[1,1]=0。這樣就有效地減少了join操作時(shí)DP的數(shù)量。前面降到了解壓縮，順便提一提DP的壓縮。每個(gè)DP中的64K個(gè)元素被當(dāng)成是一個(gè)序列，其中所有的null的位置都會(huì)被單獨(dú)存儲，然后其余的non-null的數(shù)據(jù)會(huì)被壓縮。數(shù)據(jù)的壓縮跟數(shù)據(jù)的類型有關(guān)，infobright會(huì)根據(jù)數(shù)據(jù)的類型選擇壓縮算法。infobright會(huì)自適應(yīng)地調(diào)節(jié)算法的參數(shù)以達(dá)到最優(yōu)的壓縮比。

Knowledge Grid還是比較復(fù)雜的，里面還有很多細(xì)節(jié)的東西，可以參考官方的白皮書和Brighthouse: an analytic data warehouse for ad-hoc queries這篇論文。

comment lookup的使用

前面已經(jīng)分析了Infobright的構(gòu)架，簡要介紹了Infobright的壓縮過程和工作原理。現(xiàn)在來討論查詢優(yōu)化的問題。

1）配置環(huán)境：在Linux下面，Infobright環(huán)境的配置可以根據(jù)README里的要求，配置brighthouse.ini文件。

2）選取高效的數(shù)據(jù)類型

Infobright里面支持所有的MySQL原有的數(shù)據(jù)類型。其中Integer類型比其他數(shù)據(jù)類型更加高效。盡可能使用以下的數(shù)據(jù)類型：

• TINYINT，SMALLINT，MEDIUMINT，INT，BIGINT
• DECIMAL（盡量減少小數(shù)點(diǎn)位數(shù)）
• DATE ，TIME

效率比較低的、不推薦使用的數(shù)據(jù)類型有：

• BINARY VARBINARY
• FLOAT
• DOUBLE
• VARCHAR
• TINYTEXT TEXT

Infobright數(shù)據(jù)類型使用的一些經(jīng)驗(yàn)和注意點(diǎn)：

1. Infobright的數(shù)值類型的范圍和MySQL有點(diǎn)不一樣，比如Infobright的Int的最小值是-2147483647，而MySQl的Int最小值應(yīng)該是-2147483648。其他的數(shù)值類型都存在這樣的問題。
2. 能夠使用小數(shù)據(jù)類型就使用小數(shù)據(jù)類型，比如能夠使用SMALLINT就不適用INT，這一點(diǎn)上Infobright和MySQL保持一致。
3. 避免效率低的數(shù)據(jù)類型，像TEXT之類能不用就不用，像FLOAT盡量用DECIMAL代替，但是需要權(quán)衡畢竟DECIMAL會(huì)損失精度。
4. 盡量少用VARCHAR，在MySQL里面動(dòng)態(tài)的Varchar性能就不強(qiáng)，所以盡量避免VARCHAR。如果適合的話可以選擇把VARCHAR改成CHAR存儲甚至專程INTEGER類型。VARCHAR的優(yōu)勢在于分配空間的長度可變，既然Infobright具有那么優(yōu)秀的壓縮性能，個(gè)人認(rèn)為完全可以把VARCHAR轉(zhuǎn)成CHAR。CHAR會(huì)具有更好的查詢和壓縮性能。
5. 能夠使用INT的情況盡量使用INT，很多時(shí)候甚至可以把一些CHAR類型的數(shù)據(jù)往整型轉(zhuǎn)化。比如搜索日志里面的客戶永久id、客戶id等等數(shù)據(jù)就可以用BIGINT存儲而不用CHAR存儲。其實(shí)把時(shí)間分割成year、month、day三列存儲也是很好的選擇。在我能見到的系統(tǒng)里面時(shí)間基本上是使用頻率最高的字段，提高時(shí)間字段的查詢性能顯然是非常重要的。當(dāng)然這個(gè)還是要根據(jù)系統(tǒng)的具體情況，做數(shù)據(jù)分析時(shí)有時(shí)候很需要MySQL的那些時(shí)間函數(shù)。
6. varchar和char字段還可以使用comment lookup，comment lookup能夠顯著地提高壓縮比率和查詢性能。

3）使用comment lookup

comment lookup只能顯式地使用在char或者varchar上面。Comment Lookup可以減少存儲空間，提高壓縮率，對char和varchar字段采用comment lookup可以提高查詢效率。Comment Lookup實(shí)現(xiàn)機(jī)制很像位圖索引，實(shí)現(xiàn)上利用簡短的數(shù)值類型替代char字段已取得更好的查詢性能和壓縮比率。Comment Lookup的使用除了對數(shù)據(jù)類型有要求，對數(shù)據(jù)也有一定的要求。一般要求數(shù)據(jù)類別的總數(shù)小于10000并且當(dāng)前列的單元數(shù)量/類別數(shù)量大于10。Comment Lookup比較適合年齡，性別，省份這一類型的字段。

comment lookup使用很簡單，在創(chuàng)建數(shù)據(jù)庫表的時(shí)候如下定義即可：

4）盡量有序地導(dǎo)入數(shù)據(jù)

前面分析過Infobright的構(gòu)架，每一列分成n個(gè)DP，每個(gè)DPN列面存儲著DP的一些統(tǒng)計(jì)信息。有序地導(dǎo)入數(shù)據(jù)能夠使不同的DP的DPN內(nèi)的數(shù)據(jù)差異化更明顯。比如按時(shí)間date順序?qū)霐?shù)據(jù)，那么前一個(gè)DP的max（date）<=下一個(gè)DP的min(date)，查詢的時(shí)候就能夠減少可疑DP，提高查詢性能。換句話說，有序地導(dǎo)入數(shù)據(jù)就是使DP內(nèi)部數(shù)據(jù)更加集中，而不再那么分散。

5）使用高效的查詢語句。

這里涉及的內(nèi)容比較多了，總結(jié)如下：

• 盡量不適用or，可以采用in或者union取而代之
• 減少IO操作，原因是infobright里面數(shù)據(jù)是壓縮的，解壓縮的過程要消耗很多的時(shí)間。
• 查詢的時(shí)候盡量條件選擇差異化更明顯的語句
• Select中盡量使用where中出現(xiàn)的字段。原因是Infobright按照列處理的，每一列都是單獨(dú)處理的。所以避免使用where中未出現(xiàn)的字段可以得到較好的性能。
• 限制在結(jié)果中的表的數(shù)量，也就是限制select中出現(xiàn)表的數(shù)量。
• 盡量使用獨(dú)立的子查詢和join操作代替非獨(dú)立的子查詢
• 盡量不在where里面使用MySQL函數(shù)和類型轉(zhuǎn)換符
• 盡量避免會(huì)使用MySQL優(yōu)化器的查詢操作
• 使用跨越Infobright表和MySQL表的查詢操作
• 盡量不在group by 里或者子查詢里面使用數(shù)學(xué)操作，如sum（a*b）。
• select里面盡量剔除不要的字段。
• 避免使用select * from table
• 避免使用union all
• 盡量使用系統(tǒng)提供的函數(shù)

Infobright執(zhí)行查詢語句的時(shí)候，大部分的時(shí)間都是花在優(yōu)化階段。Infobright優(yōu)化器雖然已經(jīng)很強(qiáng)大，但是編寫查詢語句的時(shí)候很多的細(xì)節(jié)問題還是需要程序員注意。

Infobright導(dǎo)入工具

• Insert
• MySQL 導(dǎo)入工具 （@bh_dataformat='mysql'）
• ETL工具：http://www.infobright.org/Downloads/Contributed‐Software/
• Infobright 自身的導(dǎo)入工：CSV格式(@bh_dataformat='txt_variable'),二進(jìn)制格式(@bh_dataformat='binary')
• DLP 分布式導(dǎo)入工具（1.6TB/小時(shí)）

參考鏈接：

• infobright商業(yè)網(wǎng)站：http://www.infobright.com/
• infobright社區(qū)交流網(wǎng)站：http://www.infobright.org/
• mysql對infobright的介紹：http://dev.mysql.com/tech-resources/articles/datawarehousing_mysql_infobright.html
• 關(guān)于infobright的介紹視頻：http://www.infobright.com/Resource-Library/Webcasts-Podcasts/?infobright_product_demo