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

　　架構(gòu)分析 

　　Greenplum的高性能得益于其良好的體系結(jié)構(gòu)。Greenplum的架構(gòu)采用了MPP(大規(guī)模并行處理)。在 MPP 系統(tǒng)中，每個(gè) SMP 節(jié)點(diǎn)也可以運(yùn)行自己的操作系統(tǒng)、數(shù)據(jù)庫等。換言之，每個(gè)節(jié)點(diǎn)內(nèi)的 CPU 不能訪問另一個(gè)節(jié)點(diǎn)的內(nèi)存。節(jié)點(diǎn)之間的信息交互是通過節(jié)點(diǎn)互聯(lián)網(wǎng)絡(luò)實(shí)現(xiàn)的，這個(gè)過程一般稱為數(shù)據(jù)重分配 (Data Redistribution) 。與傳統(tǒng)的SMP架構(gòu)明顯不同，通常情況下，MPP系統(tǒng)因?yàn)橐诓煌幚韱卧g傳送信息，所以它的效率要比SMP要差一點(diǎn)，但是這也不是絕對的，因?yàn)镸PP系統(tǒng)不共享資源，因此對它而言，資源比SMP要多，當(dāng)需要處理的事務(wù)達(dá)到一定規(guī)模時(shí)，MPP的效率要比SMP好。這就是看通信時(shí)間占用計(jì)算時(shí)間的比例而定，如果通信時(shí)間比較多，那MPP系統(tǒng)就不占優(yōu)勢了，相反，如果通信時(shí)間比較少，那MPP系統(tǒng)可以充分發(fā)揮資源的優(yōu)勢，達(dá)到高效率。當(dāng)前使用的OTLP程序中，用戶訪問一個(gè)中心數(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ù)存儲(chǔ)共享，節(jié)點(diǎn)間內(nèi)存可以相互訪問。

Oracle RAC架構(gòu)

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

                                              Greenplum架構(gòu)圖

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

　　大規(guī)模存儲(chǔ) 

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

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

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

并行處理 

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

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

Gpfidist架構(gòu)

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

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

　　工作原理:

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

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

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

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

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