Greenplum做為新一代的數(shù)據(jù)庫引擎，有著良好的發(fā)展與應(yīng)用前景。強(qiáng)大的工作效率，低成本的硬件平臺對數(shù)據(jù)倉庫與商業(yè)智能建設(shè)有很大的吸引力。要清楚的了解其特點最好從架構(gòu)著手。

　　架構(gòu)分析 

　　Greenplum的高性能得益于其良好的體系結(jié)構(gòu)。Greenplum的架構(gòu)采用了MPP(大規(guī)模并行處理)。在 MPP 系統(tǒng)中，每個 SMP 節(jié)點也可以運(yùn)行自己的操作系統(tǒng)、數(shù)據(jù)庫等。換言之，每個節(jié)點內(nèi)的 CPU 不能訪問另一個節(jié)點的內(nèi)存。節(jié)點之間的信息交互是通過節(jié)點互聯(lián)網(wǎng)絡(luò)實現(xiàn)的，這個過程一般稱為數(shù)據(jù)重分配 (Data Redistribution) 。與傳統(tǒng)的SMP架構(gòu)明顯不同，通常情況下，MPP系統(tǒng)因為要在不同處理單元之間傳送信息，所以它的效率要比SMP要差一點，但是這也不是絕對的，因為MPP系統(tǒng)不共享資源，因此對它而言，資源比SMP要多，當(dāng)需要處理的事務(wù)達(dá)到一定規(guī)模時，MPP的效率要比SMP好。這就是看通信時間占用計算時間的比例而定，如果通信時間比較多，那MPP系統(tǒng)就不占優(yōu)勢了，相反，如果通信時間比較少，那MPP系統(tǒng)可以充分發(fā)揮資源的優(yōu)勢，達(dá)到高效率。當(dāng)前使用的OTLP程序中，用戶訪問一個中心數(shù)據(jù)庫，如果采用SMP系統(tǒng)結(jié)構(gòu)，它的效率要比采用MPP結(jié)構(gòu)要快得多。而MPP系統(tǒng)在決策支持和數(shù)據(jù)挖掘方面顯示了優(yōu)勢，可以這樣說，如果操作相互之間沒有什么關(guān)系，處理單元之間需要進(jìn)行的通信比較少，那采用MPP系統(tǒng)就要好，相反就不合適了。

　　Shared nothing架構(gòu) 

　　常見的OLTP數(shù)據(jù)庫系統(tǒng)常常采用shared everything架構(gòu)來做集群，例如oracle RAC架構(gòu)，數(shù)據(jù)存儲共享，節(jié)點間內(nèi)存可以相互訪問。

Oracle RAC架構(gòu)

　　Greenplum是一種基于postgresql（開源數(shù)據(jù)庫）的分布式數(shù)據(jù)庫。其采用shared nothing架構(gòu)（MPP），主機(jī)，操作系統(tǒng)，內(nèi)存，存儲都是自我控制的，不存在共享。主要由master host，segment host，interconnect三大部分組成。

                                              Greenplum架構(gòu)圖

　　了解完Greenplum的架構(gòu)后，對其工作流程也就相對簡單了。因greenplum采用了MPP架構(gòu)，其主要的優(yōu)點是大規(guī)模的并行處理能力，應(yīng)該把精力主要放在大規(guī)模存儲與并行處理兩個方面。

　　大規(guī)模存儲 

　　Greenplum數(shù)據(jù)庫通過將數(shù)據(jù)分布到多個節(jié)點上來實現(xiàn)規(guī)模數(shù)據(jù)的存儲。數(shù)據(jù)庫的瓶頸經(jīng)常發(fā)生在I/O方面，數(shù)據(jù)庫的諸多性能問題最終總能歸罪到I/O身上，久而久之，IO瓶頸成為了數(shù)據(jù)庫性能的永恒的話題。

　　Greenplum采用分而治之的辦法，將數(shù)據(jù)規(guī)律的分布到節(jié)點上，充分利用segment主機(jī)的IO能力，以此讓系統(tǒng)達(dá)到最大的IO能力（主要是帶寬）。

　　在greenplum中每個表都是分布在所有節(jié)點上的。Master host首先通過對表的某個或多個列進(jìn)行hash運(yùn)算，然后根據(jù)hash結(jié)果將表的數(shù)據(jù)分布到segment host中。整個過程中master host不存放任何用戶數(shù)據(jù)，只是對客戶端進(jìn)行訪問控制和存儲表分布邏輯的元數(shù)據(jù)。

并行處理 

Greenplum的并行處理主要體現(xiàn)在外部表并行裝載，并行備份恢復(fù)與并行查詢處理三個方面。

數(shù)據(jù)倉庫的主要精力一般集中在數(shù)據(jù)的裝載和查詢，數(shù)據(jù)的并行裝載主要是在采用外部表或者web表方式，通常情況下通過gpfdist來實現(xiàn)。

Gpfidist架構(gòu)

　　Gpfdist程序能夠以370MB/s裝載text格式的文件和200MB/s裝載CSV格式文件，ETL帶寬為1GB的情況下，我們可以運(yùn)行3個gpfdist程序裝載text文件，或者運(yùn)行5個gpfdist程序裝載CSV格式文件。例如圖例中采用了2個gpfdist程序進(jìn)行數(shù)據(jù)裝載。可以根據(jù)實際的環(huán)境通過配置postgresql.conf參數(shù)文件來優(yōu)化裝載性能。

　　查詢性能的強(qiáng)弱往往由查詢優(yōu)化器的水平來決定，greenplum主節(jié)點負(fù)責(zé)解析SQL與生成執(zhí)行計劃。Greenplum的執(zhí)行計劃生成同樣采用基于成本的方式，基于數(shù)據(jù)庫是由諸多segment實例組成，在選擇執(zhí)行計劃時主節(jié)點還要綜合考慮節(jié)點間傳送數(shù)據(jù)的代價。

　　工作原理:

　　在主節(jié)點上存在query dispatcher (QD)進(jìn)程，該進(jìn)程前期負(fù)責(zé)查詢計劃的創(chuàng)建和調(diào)度，segment instance返回結(jié)果后，該進(jìn)程再進(jìn)行聚合與向用戶展示；segment host存在query executor (QE)進(jìn)程，該進(jìn)程負(fù)責(zé)其它節(jié)點相互通信與執(zhí)行QD調(diào)度的執(zhí)行計劃。

　　Greenplum最為一個嚴(yán)格的數(shù)據(jù)庫系統(tǒng)，同樣支持線性擴(kuò)展，高可用性架構(gòu)，數(shù)據(jù)與主機(jī)的容錯機(jī)制，還有數(shù)據(jù)的分區(qū)與壓縮功能。

　　想要充分的發(fā)揮出greenplum的性能，還要對greenplum的運(yùn)行機(jī)制有更加深入的了解。<歡迎大家一起討論>

it知識庫：greenplum數(shù)據(jù)庫引擎探究，轉(zhuǎn)載需保留來源！

鄭重聲明：本文版權(quán)歸原作者所有，轉(zhuǎn)載文章僅為傳播更多信息之目的，如作者信息標(biāo)記有誤，請第一時間聯(lián)系我們修改或刪除，多謝。