Greenplum是一種基於PostgreSQL的分佈式數據庫,其採用shared-nothing架構,主機、操做系統、內存、存儲都是自我控制的,不存在共享。python
官方文檔:>>>--大概內容以下sql
Greenplum採用Postgresl做爲底層引擎,良好的兼容了Postgresql的功能,Postgresql中的功能模塊和接口基本上99%均可以在Greenplum上使用,例如odbc、jdbc、oledb、perldbi、python psycopg2等,因此Greenplum與第三方工具、BI報表集成的時候很是容易;固然它也提供了一些Postgresql不存在的高級功能:數據庫
外部表並行數據加載安全
可更新數據壓縮表服務器
行、列混合存儲網絡
數據表多級分區架構
Bitmap索引併發
Hadoop外部表分佈式
Gptext全文檢索高併發
並行查詢計劃優化器和Orca優化器
Primary/Mirror鏡像保護機制
資源隊列管理
WEB/Brower監控
Greenplum最大的特色總結就一句話:基於低成本的開放平臺基礎上提供強大的並行數據計算性能和海量數據管理能力。這個能力主要指的是並行計算能力,是對大任務、複雜任務的快速高效計算,但若是你期望MPP並行數據庫可以像OLTP數據庫同樣,在極短的時間處理大量的併發小任務,這個並不是MPP數據庫所長。請牢記,並行和併發是兩個徹底不一樣的概念,MPP數據庫是爲了解決大問題而設計的並行計算技術,而不是大量的小問題的高併發請求。
再通俗點說,Greenplum主要定位在OLAP領域,利用Greenplum MPP數據庫作大數據計算或分析平臺很是適合,例如:數據倉庫系統、ODS系統、ACRM系統、歷史數據管理系統、電信流量分析系統、移動信令分析系統、SANDBOX自助分析沙箱、數據集市等等。
而MPP數據庫都不擅長作OLTP交易系統,所謂交易系統,就是高頻的交易型小規模數據插入、修改、刪除,每次事務處理的數據量不大,但每秒鐘都會發生幾十次甚至幾百次以上交易型事務 ,這類系統的衡量指標是TPS,適用的系統是OLTP數據庫或相似Gemfire的內存數據庫。
Greenplum主要由Master節點、Segment節點、interconnect三大部分組成。Greenplum master是Greenplum數據庫系統的入口,接受客戶端鏈接及提交的SQL語句,將工做負載分發給其它數據庫實例(segment實例),由它們存儲和處理數據。Greenplum interconnect負責不一樣PostgreSQL實例之間的通訊。Greenplum segment是獨立的PostgreSQL數據庫,每一個segment存儲一部分數據。大部分查詢處理都由segment完成。
master節點是外邊用戶訪問greenplum的入口。用戶並不與segment節點發生任何關係,外部用戶的網絡只須要與master服務器聯通便可。
master數據庫也是一個被改造過的PostgreSQL數據庫,它包含了整個分佈式數據庫中的全部元數據,如表結構定義、索引、數據分佈信息等等。但其並不存儲實際的數據,實際的數據是存儲在segment數據庫的。
master節點接受用戶發過來的sql命令,而後解析生成分佈式的執行計劃,再把執行計劃下發到對應的segment節點進行執行。segment節點執行完成後的結果會發送到master上,master接收到segment的結果進行彙總並返回執行結果給用戶。因此在這種master-slave結構中,master不會成爲系統的瓶頸。
Greenplum的每一個segment節點能夠運行多個segment instance,每一個instance能夠綁定到一個網卡,這樣能夠發揮CPU和網絡性能。
系統的數據都分佈式的存儲在segment上。
每一個segment同時執行master分發的任務,在執行查詢任務或者數據加載的時候可能會涉及數據的移動。在進行數據移動的時候master不參與進來,只是在segment之間進行。
segment能夠動態擴展,既能夠在原有主機上進行增長segment instance的操做,又能夠新增主機來增長segment。當擴展segment後,系統裏面的數據會進行重分佈操做,這個動做消耗時間會比較多。
Greenplum interconnect負責不一樣PostgreSQL實例之間的通訊。
通常是針對單個主機,徹底透明共享CPU/MEMORY/IO,並行處理能力差,典型的表明SQLServer。 shared-everything架構優勢很明顯,可是網絡,硬盤很容易就會成爲系統瓶頸。
各個處理單元使用本身的私有 CPU和Memory,共享磁盤系統。典型的表明Oracle Rac, 它是數據共享,可經過增長節點來提升並行處理的能力,擴展能力較好。其相似於SMP(對稱多處理)模式,可是當存儲器接口達到飽和的時候,增長節點並不能得到更高的性能 。
各個處理單元都有本身私有的CPU/內存/硬盤等,不存在共享資源,各處理單元之間經過協議通訊,並行處理和擴展能力更好。各節點相互獨立,各自處理本身的數據,處理後的結果可能向上層彙總或在節點間流轉。Share-Nothing架構在擴展性和成本上都具備明顯優點。
大規模並行處理系統是由許多鬆耦合處理單元組成的,藉助MPP這種高性能的系統架構,Greenplum能夠將TB級的數據倉庫負載分解,並使用全部的系統資源並行處理單個查詢。
與事務型數據庫系統經過鎖機制來控制併發訪問的機制不一樣, GPDB使用多版本控制(Multiversion Concurrency Control/MVCC)保證數據一致性。 這意味着在查詢數據庫時,每一個事務看到的只是數據的快照,其確保當前的事務不會看到其餘事務在相同記錄上的修改。據此爲數據庫的每一個事務提供事務隔離。 MVCC以免給數據庫事務顯式鎖定的方式,最大化減小鎖爭用以確保多用戶環境下的性能。在併發控制方面,使用MVCC而不是使用鎖機制的最大優點是, MVCC對查詢(讀)的鎖與寫的鎖不存在衝突,而且讀與寫之間從不互相阻塞。
greenplum的高可用性是經過master和segment的鏡像來實現的,鏡像是基於服務器級別的,因此能提供比較好的安全保證。
master節點不能和segment節點安裝在同一個主機上,standby節點能夠和segment節點複用。
master宕機的話,standby master不會自動切換到master,須要手動切換到主設備。segment若是一個環節壞掉,系統能夠自動將mirror切換到primary。
當segment中某臺設備出現故障後,mirror會切換成primary。檢查出故障的主機恢復後可使用gprecoverseg命令恢復成以前的主備關係
segment包括如下兩種mirror模式:
☕: grouped mirror模式
在這種模式下,主機的mirror節點所有放在下一個主機上,當一臺機器掛掉,那麼擁有該機器mirror的主機負載加劇一倍
🎭:spread mirror模式
該模式下,mirror節點分散在後面主機上,但要求部署的物理機數量要至少多於運行在每一個節點上的instance一個。
☮ 標準SQL接口,比MapReduce接入更方便 ;
☪ 完整的分佈式事務能力,確保強數據一致性 ;
🕉 近乎線性的在線擴展能力 ;
☸ 高併發數據加載技術 ;
✡ 高靈活的行、列以及混合存儲及壓縮技術 ;
⚛ 高可用技術方案 ;
☯ 支持多方式的受權管理及審計,表級別粒度;
☦ 豐富的生態系統,便捷對接hadoop等。
連接文章:>>