整體架構(gòu)分為計算層和存儲層，都是可擴(kuò)展的，計算層需由以下幾項(xiàng)主要進(jìn)程構(gòu)成：

　　MariaDB（mysqld）：收集用戶請求的一個SQL入口，存儲元數(shù)據(jù)信息；

　　Execution Manager：解析語法樹，轉(zhuǎn)化成任務(wù)列表（JOB LIST），包括優(yōu)化、取數(shù)據(jù)、（HASH）JOIN、匯總、分組；

　　DMLProc／DDLProc：將DML／DDL語句發(fā)送到指定的PM執(zhí)行；

　　Performance Module：接受Execution Manager發(fā)送過來的任務(wù)調(diào)度，分布式掃描，（HASH）JOIN與匯總。

　　由此，我們能清晰地理解整個處理流程：MariaDB收到用戶的SQL請求后，通過執(zhí)行管理器將SQL轉(zhuǎn)化為任務(wù)列表，再由DMLProc／DDLProc發(fā)送任務(wù)給PM，最后PM將結(jié)果返回給UM進(jìn)行匯總，返回結(jié)果給客戶端。

　　優(yōu)勢

　　存儲、性能、兼容、擴(kuò)展

　　為了解決在大數(shù)據(jù)統(tǒng)計性能上的問題，對比了Infobright和ColumnStore兩種解決方案，最終選取了ColumnStore，對比如下：

　　表1 數(shù)倉方案對比表

　　1. 對于存儲而言，InnoDB本身的壓縮率并不高，有1倍左右。相比之下，Infobright的壓縮率相對最高，有20倍之多；而ColumnStore則比較適中，為5倍左右。如果為了追求高壓縮比的歷史數(shù)據(jù)存檔，很明顯使用Infobright社區(qū)版是很好的方案。

　　2. InnoDB自身的擴(kuò)展性并不高，需要外部中間件來實(shí)現(xiàn)分庫分表，因此給予擴(kuò)展性低的評價；Infobright也可以部署集群，因此擴(kuò)展性給予高評分；同樣ColumnStore也是易于擴(kuò)展的分布式方案。

　　3. 在性能方面，InnoDB的OLTP性能遠(yuǎn)高于后兩者，在數(shù)據(jù)倉庫中提供在線服務(wù)，可以考慮用InnoDB來存儲，但統(tǒng)計性能則相差甚遠(yuǎn)；由于Infobright中存在Knowledge Grid（知識網(wǎng)格），又使用了列式存儲來壓縮數(shù)據(jù)，在數(shù)據(jù)量超過內(nèi)存容量的情況下，對單列的統(tǒng)計表現(xiàn)卓越，100倍性能提升就成了極輕松的事，但如果統(tǒng)計字段增加或多表查詢，性能也就極速下降；ColumnStore不僅擁有單列高速統(tǒng)計的優(yōu)勢，而且在多表連接的場景下也表現(xiàn)不俗，當(dāng)然字段越多性能同樣會下降，但下降后的速度仍可以接受。

　　4. Infobright的社區(qū)版不支持DML，因此語法兼容性存在很大問題，對查詢的支持尚佳；ColumnStore本身開源，但語法也略有不同，例如多表連接時，不能對同一個表進(jìn)行多次連接，分組查詢字段（SELECT COLUMN LIST）必須要在分組列表（GROUP BY LIST）中。

相關(guān)電子資料下載