最近有部分工作涉及到了 ?Infobright 數據倉庫 ，就瀏覽了一些相關的資料，感覺很受啟發。下面寫一些感想，如有謬誤，還請指正。

簡單的來講，Infobright 主要有下面的一些優點：

1. TB 級的數據存儲和高效查詢。大數據量存儲主要依賴自己提供的高速數據加載工具（百G/小時）和高數據壓縮比（>10:1），高效查詢主要依賴特殊設計的存儲結構對查詢的優化，但這里優化的效果還取決于數據庫結構和查詢語句的設計。

2. 高數據壓縮比，號稱一般能夠達到 10:1 以上的數據壓縮率。高數據壓縮比主要依賴列式存儲和 patent-pending 的靈活壓縮算法。

3. 與主要 BI 分析工具的兼容性。兼容性這點主要依賴與 MySQL 的集成，作為 MySQL 的存儲引擎自然地能夠保證與 BI 分析工具的兼容。

除了上面的優點外，它也有一些限制：

1. 不支持數據更新。這使對數據的修改變得很困難，這樣就限制了它作為實時數據服務的數據倉庫來使用。用戶要么忍受數據的非實時或非精確，這樣對最（較）新數據的分析準確性就降低了許多；要么將它作為歷史庫來使用，帶來的問題是實時庫用什么？很多用戶選擇數據倉庫系統，不是因為存儲空間不夠，而是數據加載性能和查詢性能無法滿足要求。

2. 不支持高并發。雖然單庫 10 多個并發對一般的應用來說也足夠了，但較低的機器利用率對投資者來說總是一件不爽的事情，特別是在并發小請求較多的情況下。

3. 沒有提供主從備份和橫向擴展的功能。如果沒有主從備份，想做備份的話，也可以主從同時加載數據，但只能校驗最終的數據一致性，這會使得從機在數據加載時停服務的時間較長；橫向擴展方面，倒不是 Infobright 的錯，它本身就不是分布式的存儲系統，但如果把它搞成一個分布式的系統，應該是一件比較好玩的事情。

在架構方面，Infobright 給我展示了不少新想法，算是受益頗多吧。首先是按列存儲，然后把列數據切成小塊（Data Pack），進行壓縮和統計（DPN, Data Pack Node），然后再對多塊數據之間進行知識關聯（Knowledge Node），最后對整個表形成知識網格（Knowledge Grid）。雖然說 Infobright 沒有提供索引結構，但它 Knowledge Grid 中的 Numerical Histogram、Character Map 和 Pack-to-Pack 結構，怎么看都和? bitmap 索引 脫不了關系。只是它的組織形式不像傳統數據庫中的索引罷了。

其實我們在設計類似的分布式表格系統時，也可以實現類似于 Knowledge Grid 的結構。這個結構未必跟 Infobright 的一樣，但是如果在壓縮的基礎上，基于系統查詢模式（分布式系統的查詢模式一般相對簡單，復雜的也做不來），存儲一些輔助的塊統計信息以及塊之間的關聯信息，對于減少查詢的資源消耗，提高查詢效率會非常有幫助，這也正好是針對分布式表格系統很難建立索引這一缺點的彌補。

參考鏈接：

這篇文章 對 Infobright 及其安裝方法進行了基本介紹，最后的一個查詢速度對比有些夸張（105:1），我覺得這可能跟查詢條件正好能匹配上 Knowledge Grid 中的信息所致； 這個博客 很有趣，從 2010 年 3 月 8 日到 5 月 8 日之間的文章全是? Infobright ?相關的，寫的還是挺詳細的； Brighthouse: An Analytic DataWarehouse for Ad-hoc Queries ?是一篇相關的 08 年 VLDB paper；此外官網上的白皮書不能直接下載，但在搜索引擎中能搜到一些。

?

轉自: http://blog.solrex.org/articles/infobright-data-warehouse.html

INFOBRIGHT 數據倉庫