最近有部分工作涉及到了 ?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
更多文章、技術交流、商務合作、聯系博主
微信掃碼或搜索:z360901061

微信掃一掃加我為好友
QQ號聯系: 360901061
您的支持是博主寫作最大的動力,如果您喜歡我的文章,感覺我的文章對您有幫助,請用微信掃描下面二維碼支持博主2元、5元、10元、20元等您想捐的金額吧,狠狠點擊下面給點支持吧,站長非常感激您!手機微信長按不能支付解決辦法:請將微信支付二維碼保存到相冊,切換到微信,然后點擊微信右上角掃一掃功能,選擇支付二維碼完成支付。
【本文對您有幫助就好】元
