除非你最近在一個荒島上，否則你不可能不知道，數據倉庫/分析/商務智能( BI )領域正在飛速發展。許多年前，當行業分析師羣體調查CIO最優先考慮的事時，BI排第十位。然而，他於2006年躍升到了第二位，今天，根據Gartner Group分析已經躍居第一位了。這沒有什麼神祕的原因：在激烈的經濟競爭中所有行業和智能企業需要利用其內部的數據來做出重要的商業決策，包括戰術和戰略兩方面，以保持行業的領先地位。
但有個問題：在公司組建主要的BI部門將要花費很大一筆資金。很多數據倉庫和BI廠商較好的實現你的AMEX金卡態度，對部分IT負責人造成了一些挫折;事實上，2007年信息週刊調查發現， 39 %的IT經理抱怨說，軟件許可費用阻礙他們想要推廣BI的倡議。
但有個問題：在公司組建主要的BI部門將要花費很大一筆資金。很多數據倉庫和BI廠商較好的實現你的AMEX金卡態度，對部分IT負責人造成了一些挫折;事實上，2007年信息週刊調查發現， 39 %的IT經理抱怨說，軟件許可費用阻礙他們想要推廣BI的倡議。
但是進入開源!正如最近，開放源碼已經革新了軟件的許多領域，幾乎爲任何公司創造研發操作系統，開發工具，以及數據庫，等具有競爭力的IT環境打開了方便之門，那麼現在同樣的事情也發生在了數據倉庫和商務智能(BI)領域。目睹事實，數據倉庫(如對MySQL的一次重大社會和客戶調查)目前是 MySQL的第五種最常見的應用。
但這裏的另一個統計稱：根據TDWI ，數據倉庫每年的平均增長速度的介於33和50 %之間，然而這一數據對一些企業來說還是相對比較保守的。現在用於MySQL數據倉庫最流行的存儲引擎是MyISAM (第二個是InnoDB的) ，當數據達到1TB左右是他的性能依然很優越。在此之後，大量的用戶往往將數據倉庫分佈在多個服務器，以提高性能。現在，從分析公司IDC統計資料來看，大多數的數據倉庫是6TB下(據IDC稱只有4 %超過25TB)，因此這意味着大多數人成天都只在管理數百GB和6TB之間的數據倉庫。
如果是你，並且你希望有一個基於MySQL的解決方案，那麼你應該爲親自去留意一下Infobright存儲引擎。 Infobright，MySQL / Sun公司的合作伙伴之一，供應的引擎能突破MyISAM和其他存儲引擎限制，並提供了一個非常尖端的技術(令人吃驚... )，當進行安裝，設置和數據庫設計以獲得難以置信的快速的反應時間時，你並不需要繁重的工作。
讓我們先來看看在Infobright架構，看看它是如何完成這些事情，然後對他進行測試以瞭解其是如何更好的執行解析式查詢。
列非常酷
概括地說， Infobright存儲引擎是一個列導向的架構，結合高速數據裝載機，高度的數據壓縮和一個靈活的，外部優化器以及'知識網格' ，提供令人印象深刻的數據倉庫功能。從MySQL的角度來看， Infobright就像其他任何存儲引擎，因此從界面的角度來看沒有什麼新的東西要理解。 Infobright是一個單獨的安裝，然而，從總體MySQL服務器，但它安裝很簡單(我發現實際速度超過一個標準MySQL的安裝) ，以及下載也只有17MB，這是一個非常了不起的引擎，可以管理10萬億字節的數據。
首先要說明的是， Infobright引擎是一列導向的設計。列導向的數據庫的存在已經有一段時間(如Sybase公司的IQ ) ，但現在纔給人以強烈的印象，歸功於其能很好的滿足數據倉庫的需求。2008年3月Infobright研究報告“What’s Cool About Columns”，菲利普霍華德寫道， “在過去十年，對於大部分使用列導向的做法是非常合理的。不過...我們相信，現在是列走出陰影，成爲數據倉庫和相關的市場主要力量的時候。”他接着補充說， “列以較低的成本和更小的封裝提供更好的性能：但很難理解，爲什麼任何公司都對查詢性能感興趣，但從不考慮基於列的解決方案。
爲什麼要作這樣的聲明?由於像Infobright這樣列導向的設計，在數據倉庫環境下真的包含着許多優勢。出現這種情況有許多原因，但在這裏僅僅是少數幾個。大多數數據倉庫/解析查詢，只關心一個或多個表中的兩列，而不是所有的列。在這種情況下，爲數據倉庫目的，數據以典型的行格式存儲是沒有效率，而更應該採取列導向的格式存儲。在像Infobright這樣列導向設計的數據庫中，全表掃描將永遠不會被執行(除非查詢請求一個表中全部或大部分列) ; 可能只需進行全列掃描。最終的結果是更少I / O操作並且提高列導向數據庫的響應時間。
Infobright採用列導向的設計並結合任何人都喜歡的其它設計：高強度的數據壓縮。因爲它是列導向，當Infobright壓縮數據，它對每一列這樣做，這通常是比標準的行導向的壓縮更有效率，因爲壓縮算法可被每一列數據類型精調。在正常的行導向的壓縮中，你最多看到2或3比1的壓縮;但採用Infobright ，10比1壓縮是最基本的(在某些情況下會高得多) ，所以1TB的數據庫可以被壓縮到100GB 。當Sun性能組一些成員的看到這種性能，他們對Inforbright壓縮數據的能力很吃驚，他的性能比他們以往使用過的任何數據庫(行導向和列導向) 都要強。當然，數據壓縮的結果是，不僅有助於提高性能，同時也有助於降低數據倉據的存儲成本，這將受到更多IT經理的青睞。
Infobright的其他技術優勢
雖然您可以通過所有標準路線加載數據到MySQL Infobright表， Infobright還提供了一個特殊的高速裝載機，他在加載數據到一個數據庫時採用了完全不一樣的算法。該加載算法是多線程，使每個列能並行載入。採用 Infobright企業版，單表加載100GB的數據通常需要一個小時，而多表加載一個小時可以實現300GB左右的二進制數據載入，這不是太寒酸。 Infobright社區版已降低載入速度，因爲它只能處理文字輸入(而不是二進制) ，但你仍然可以看一個小時載入40GB左右數據的速度。
但是，也許在Infobright架構主要的最突出的技術是它的“知識網格”和相應的優化器。 Infobright在數據加載到數據庫中(無論初始化或遞增)時候就開始建造知識網格。知識網格本質上是數據庫中數據和數據統計的一個統計描述。這裏關鍵要記住知識網格：它可以替代索引，這意味着你永遠不需要在Infobright表中創建索引。不用創建索引，這是一件好事!
Infobright知識網格沒有索引維護的缺點，從所周知，造成數據庫插入和更新的響應時間隨着時間的推移而增加的原因，是因爲對據庫越來越多的修改操作。另一個優點Infobright在做非常難以預測的查詢服務時，做得非常好，這正是許多數據倉庫需要處理的。這種查詢是數據庫管理員的惡夢，因爲他們不能設計一個有效的索引或分割策略，因此數據庫性能從來沒有到達最大。但隨着Infobright 出現，所有這些問題都迎刃而解，因爲它能自動完成這些工作。
Infobright的實際數據是按照列存儲的。這些列被分爲64K的大小，稱作數據包，其元數據存儲在知識網格。當一個查詢提交給 Infobright執行時，優化器諮詢知識網格，以便產生一個粗略的想法，哪些數據包包含查詢結果集所需的數據。當出現以下兩種情況( a )有相對較少的數據包中包含結果集的數據;( b )優化工具能夠準確地確定一系列所需的數據包，查詢速度將異常快速。
考慮數據分佈方法類似於自動數據分割。再次，這是一件好事。隨着Infobright 出現，得到性能優越的數據倉庫，你不必是一個數據倉庫的設計專家，因爲它幾乎爲你做了所有困難的工作-沒有索引或分割戰略，這以前都是你工作的一部分。
在某些情況下，查詢根本不需要任何數據包就可以執行;只要諮詢過知識網格，像這樣的查詢將立即執行。由於知識網格包含了許多聚合信息，因爲在數據倉庫的應用中，聚合是所有查詢一個共同的點，對許多數據倉庫類型的查詢執行來說，很少或根本沒有這些必要處理是不尋常的(例子後續下文) 。
Infobright趨向的應用框架是有深的、寬的實際表和低維度表的星型模式(儘管真正的星型設計不需要)，並且數據庫中表的設計基本上是非格式化的。在包括高度標準化架構的應用和更多的隨機數據的分佈的使用情況下，Infobright可能無法執行。這是因爲這些數據不會以數據集中的模式壓縮，並且數據的查詢結果集遍佈數據庫，因此大量的數據包需要被掃描。
