簡介及適用場景 如果想在數據倉庫中快速查詢結果，可以使用greenplum。 Greenplum資料庫也簡稱GPDB。它擁有豐富的特性： 第一，完善的標準支持：GPDB完全支持ANSI SQL 2008標準和SQL OLAP 2003 擴展；從應用編程介面上講，它支持ODBC和JDBC。完善的標準支... ...
簡介及適用場景
如果想在數據倉庫中快速查詢結果，可以使用greenplum。
Greenplum資料庫也簡稱GPDB。它擁有豐富的特性：
第一，完善的標準支持：GPDB完全支持ANSI SQL 2008標準和SQL OLAP 2003 擴展；從應用編程介面上講，它支持ODBC和JDBC。完善的標準支持使得系統開發、維護和管理都大為方便。而現在的 NoSQL，NewSQL和Hadoop 對 SQL 的支持都不完善，不同的系統需要單獨開發和管理，且移植性不好。
第二，支持分散式事務，支持ACID。保證數據的強一致性。
第三，做為分散式資料庫，擁有良好的線性擴展能力。在國內外用戶生產環境中，具有上百個物理節點的GPDB集群都有很多案例。
第四，GPDB是企業級資料庫產品，全球有上千個集群在不同客戶的生產環境運行。這些集群為全球很多大的金融、政府、物流、零售等公司的關鍵業務提供服務。
第五，GPDB是Greenplum（現在的Pivotal）公司十多年研發投入的結果。GPDB基於PostgreSQL 8.2，PostgreSQL 8.2有大約80萬行源代碼，而GPDB現在有130萬行源碼。相比PostgreSQL 8.2，增加了約50萬行的源代碼。
第六，Greenplum有很多合作伙伴，GPDB有完善的生態系統，可以與很多企業級產品集成，譬如SAS，Cognos，Informatic，Tableau等；也可以很多種開源軟體集成，譬如Pentaho,Talend 等。
greenplum起源
Greenplum最早是在10多年前（大約在2002年）出現的，基本上和Hadoop是同一時期（Hadoop 約是2004年前後，早期的Nutch可追溯到2002年）。當時的背景是：
- 互聯網行業經過之前近10年的由慢到快的發展，累積了大量信息和數據，數據在爆髮式增長，這些海量數據急需新的計算方式，需要一場計算方式的革命；
- 傳統的主機計算模式在海量數據面前，除了造價昂貴外，在技術上也難於滿足數據計算性能指標，傳統主機的Scale-up模式遇到了瓶頸，SMP（對稱多處理）架構難於擴展，並且在CPU計算和IO吞吐上不能滿足海量數據的計算需求；
- 分散式存儲和分散式計算理論剛剛被提出來，Google的兩篇著名論文發表後引起業界的關註，一篇是關於GFS分散式文件系統，另外一篇是關於MapReduce 並行計算框架的理論，分散式計算模式在互聯網行業特別是收索引擎和分詞檢索等方面獲得了巨大成功。
下圖就是GFS的架構
總體架構
greenplum的總體架構如下：
資料庫由Master Severs和Segment Severs通過Interconnect互聯組成。
Master主機負責：建立與客戶端的連接和管理；SQL的解析並形成執行計劃；執行計劃向Segment的分發收集Segment的執行結果；Master不存儲業務數據，只存儲數據字典。
Segment主機負責：業務數據的存儲和存取；用戶查詢SQL的執行。
greenplum使用mpp架構。
基本體系架構
master節點，可以做成高可用的架構
master node高可用，類似於hadoop的namenode和second namenode，實現主備的高可用。
segments節點
並行管理
對於數據的裝載和性能監控。
並行備份和恢復。
數據訪問流程，數據分佈到不同顏色的節點上
查詢流程分為查詢創建和查詢分發，計算後將結果返回。
對於存儲，將存儲的內容分佈到各個結點上。
對於數據的分佈，分為hash分佈和隨機分佈兩種。
均勻分佈的情況：
總結
GPDB從開始設計的時候就被定義成數據倉庫，如果是olap的應用，可以嘗試使用GPDB。
