前言
在數據庫誕生到現在，我們所能耳熟能詳的數據庫如oracle，mysql，sqlserver等，都屬於關系型數據庫，它們主要是基本的、日常的事務處理，記錄即時的增、刪、改、查，實時性要求很高，但數據量不會很大，不會做很多復雜的邏輯，這一類歸於OLTP（聯機事務處理）型數據庫，而分布式數據庫是對海量的數據進行管理，解決的是海量的數據處理及分析能力，更多的是對數據進行讀的操作，增、刪、改是比較低頻的操作，它對實時性要求不高，更強調的是數據的分析處理能力，屬於OLAP（聯機分析處理）型數據庫。
以下是OLAP和OLTP的比較：
| OLTP | OLAP | |
| 適用場景 | 主要供基層人員使用，進行一線業務操作 | 探索並挖掘數據價值，作為企業高層進行決策的參考 |
| 數據特點 | 當前的、最新的、細節的, 二維的、分立的 | 歷史的, 聚集的, 多維的，集成的, 統一的 |
| 存取能力 | 可以讀/寫數十條記錄 | 讀上百萬條記錄 |
| 復雜度 | 簡單的事務 | 復雜任務 |
| 可承載用戶 | 可承載用戶數量為上千個 | 上百萬個 |
| DB大小 | 大小為100GB | 可以達到100TB |
| 時效性 | 實時 | 時間的要求不嚴格 |
greenplum屬於OLAP型的一種分布式的關系型數據庫，應用於數據倉庫，它的底層是基於開源的關系型數據庫postgresql進行開發完成的，postgresql擁有豐富的數據類型，強容錯能力及存儲結構等優點，因而也一躍而上，成為目前主流的數據庫之一，由於greenplum底層是postgresql的原因，因此greenplum也繼承了postgresql的這些優點，並且兩者之間進行數據遷移可以做到完全兼容，避免進行數據轉換。
postgresql排名圖：
結構
主從結構
greenplum采用一主（Master）多從（Segment）的結構，Master負責查詢解析、優化及任務分發，Segment負責查詢處理、數據存儲，雙方通過Interconnect通信，總體架構如下：
master節點：
是整個系統的控制中心和對外的服務接入點，它負責接收用戶SQL請求，將SQL生成查詢計划並進行並行處理優化，然后將查詢計划分配（dispatch）到所有的Segment節點進行並行處理，協調組織各個Segment節點按照查詢計划一步一步地進行並行處理，最后獲取到Segment的計算結果，再返回給客戶端；從用戶的角度看Greenplum集群，看到的只是Master節點,無需關心集群內部的機制，所有的並行處理都是在Master控制下自動完成的。Master節點一般只有一個或兩個（互為備份），主備方案實現高可用；
segment節點：
是Greenplum執行並行任務的並行運算節點，它接收Master的指令進行MPP並行計算，因此所有Segment節點的計算性能總和就是整個集群的性能，通過增加Segment節點，可以線性化得增加集群的處理性能和存儲容量，Segment節點可以是1~10000個節點，它的數量決定greenplum的算力，可通過橫向擴容提升整個數據庫的算力及性能；
Interconnect：
是Master節點與Segment節點、Segment節點與Segment節點之間的數據傳輸組件，它基於千兆交換機或萬兆交換機實現數據在節點間的高速傳輸；
無共享/MPP架構
Greenplum數據庫軟件將數據平均分布到系統的所有節點服務器上，所以節點存儲每張表或表分區的部分行，所有數據加載和查詢都是自動在各個節點服務器上並行運行，並且該架構支持擴展到上萬個節點，做到數據完全的物理隔離。
Greenplum的架構采用了MPP(大規模並行處理)，在 MPP 系統中，每個 SMP節點也可以運行自己的操作系統、數據庫等。換言之，每個節點內的 CPU 不能訪問另一個節點的內存。節點之間的信息交互是通過節點互聯網絡實現的，這個過程一般稱為數據重分配(Data Redistribution) 。
SMP（SymmetricMulti-Processing），對稱多處理結構的簡稱，是指在一個計算機上匯集了一組處理器(多CPU),各CPU之間共享內存子系統以及總線結構。在這種技術的支持下，一個服務器系統可以同時運行多個處理器，並共享內存和其他的主機資源。傳統的ORACLE和DB2均是此種類型，ORACLE RAC 是半共享狀態；
與傳統的SMP架構明顯不同，通常情況下，MPP系統因為要在不同處理單元之間傳送信息，所以它的效率要比SMP要差一點，但是這也不是絕對的，因為 MPP系統不共享資源，因此對它而言，資源比SMP要多，當需要處理的事務達到一定規模時，MPP的效率要比SMP好。這就是看通信時間占用計算時間的比例而定，如果通信時間比較多，那MPP系統就不占優勢了，相反，如果通信時間比較少，那MPP系統可以充分發揮資源的優勢，達到高效率。
特性
greenplum是用於海量存儲數據進行計算與分析的，它做數據分析跟計算時，往往所做的大量查詢都是全表檢索的模式進行的，是不建議添加索引的，而是用它分區、分布鍵的特性結合多個segment的並行將算力達到最大化。
分區
分區是對存儲的數據進行邏輯划分，通過 "partition by" 子句完成的，它允許將一個大表划分為多個子表。"subpartition by" 子句可以將子表划分為更小的表 。從理論上講，Greenplum對於根表（root table）可以擁有多少級（level）或多少個分區表(partitioned table)並沒有限制，但是對於任一級分區（表的層次結構級別），一個分區表最多可以有32,767個子分區表。
以時間為例，一個table表可以按字段month（月份）分區成table_01，table_02，... table_11，table_12，但都是在一個segment上。
分布鍵
與分區不同，分布鍵是進行物理划分，它是分布在不同的segment上，以指定的分布鍵字段或字段組合進行哈希/隨機的策略分布，散布到不同的segment上，將數據平均分布到每一個節點機器上，為了避免數據傾斜導致算力不均，建議使用哈希策略進行分布，創建表使用 “distributed by（column，[…]）” 子句。
同樣以時間為例，t_test表中'2020-01-01'的數據散布在segment1的t_test_01表上，'2020-01-02'的數據散布在segment2的t_test_02表上 ...
create table t_test ( id int, month varchar(10), name varchar(64) ) distributed by (month) partition by range(month) ( partition 01 start ('2020-01-01') inclusive end ('2020-01-31') inclusive, partition 02 start ('2020-02-01') inclusive end ('2020-02-31') inclusive, partition 03 start ('2020-03-01') inclusive end ('2020-03-31') inclusive, partition 04 start ('2020-04-01') inclusive end ('2020-04-31') inclusive, partition 05 start ('2020-05-01') inclusive end ('2020-05-31') inclusive, partition 06 start ('2020-06-01') inclusive end ('2020-06-31') inclusive, partition 07 start ('2020-07-01') inclusive end ('2020-07-31') inclusive, partition 08 start ('2020-08-01') inclusive end ('2020-08-31') inclusive, partition 09 start ('2020-09-01') inclusive end ('2020-09-31') inclusive, partition 10 start ('2020-10-01') inclusive end ('2020-10-31') inclusive, partition 11 start ('2020-11-01') inclusive end ('2020-11-31') inclusive, default partition 12 );
存儲和執行
Master和Segment都是一個單獨的PostgreSQL數據庫。每一個都有自己單獨的一套元數據字典。
Master節點一般也叫主節點，Segment叫做數據節點。
為了實現高可用，每個Segment都有對應的備節點 Mirror Segment分別存在與不同的機器上。
Client一般只能與Master節點進行交互，Client將SQL發給Master，然后Master對SQL進行分析后再將其分配給所有的Segment進行操作。
Greenplum沒有Windows版本，只能安裝在類UNIX的操作系統上。
Greenplumn極度消耗I/O資源，所以對存儲的要求比較高。