Postgres-XL：基於PostgreSQL的開源可擴充資料庫叢集，

Postgres-XL：基於PostgreSQL的開源可擴充資料庫叢集，
Postgres-XL：基於PostgreSQL的開源可擴充資料庫叢集
                 

最近這一年業界去“IOE”越叫越響，很多傳統企業也把去“IOE”計劃擺上了案頭。我老是想不明白這些非互連網企業（比如：銀行）做這種事的動力何在？ 高大上的“自主可控”、“振興民族科技”等空洞口號先不去管，真正的動力在哪裡？ “安全”、“成本”、“互連網架構”.......等等、等等， 唯一看起來靠譜是互連網架構的技術先進性。廢話咋這多呢，大勢所趨你管的了嗎！ 言歸正傳，前段時間也在考慮有什麼可”拿來主義“的資料庫，能替代Oracle資料庫做為業務系統的資料存放區。這個資料庫系統必須是開源的、支援SQL、支援ACID，而且業務應用移植的工作量要小。 框來框去，最後發現PostgreSQL符合要求，從應用移植上講工作量遠小於使用MySQL。 
最近微博上MySQL黨人又開始與PostgreSQL黨人紛爭，講到Oracle移植到PostgreSQL工作量小時，M的擁躉者叫喊道 ：“其實，去o不見得要大規模重寫應用啊，完全取決於對資料庫專有特性的依賴程度，一般來說，對規模較大的互連網應用來說，因為考慮規模的伸縮性，不會使用很複雜的特性，換個資料庫遠沒有一般公司專屬應用程式那麼難。就算是重寫的部分”。我想說得的：哥！ 你見過嵌SQL的C程式檔案嗎？見過大量使用PL/SQL預存程序的應用嗎？  很多老系統都是這麼寫業務程式的。恰恰MySQL在這方面暫時還不給力，重構業務系統那量那責任亞力山大，不是什麼企業都能承受的。

昨天閱讀了浙江移動在中國資料庫技術大會上的主題演講《電訊廠商去O淺析》公開版，覺得裡面所講的去O關鍵點與困難很到位，當然是站在傳統企業的角度，不代表BAT等互連網公司高大上視角。
又扯遠了，轉回來接著說PostgreSQL替代O的事。
國外也有專門使用與擴充PostgreSQL、提供替代Oracle解決方案服務的公司，比如：EnterpriseDB ：”EnterpriseDB is the leading worldwide provider of Postgres software and services that enable enterprises to reduce their reliance on costly proprietary solutions and slash their database spend by 80 percent or more. 
With powerful performance and security enhancements for PostgreSQL, sophisticated management tools for global deployments and database compatibility, EnterpriseDB software supports both mission and non-mission critical enterprise applications. More than 2,500 enterprises, governments and other organizations worldwide use EnterpriseDB software, support, training and professional services to integrate open source software into their existing data infrastructures. 

Based in Bedford, MA, EnterpriseDB is backed by strategic private investors.“
另外在網上還看到一個關於日本電信公司（NTT）使用PostgreSQL去O成功案例的PPT：https://www.pgcon.org/2011/schedule/attachments/203_NTT_Case_307.pdf 但新的問題又來了，PostgreSQL能否橫向擴充以應對高並發大交易量系統的資料庫操作壓力？ 於是乎繼續在網上耕耘，這兩天找到一個看上去不錯的開源實現：Postgres-XL。（具體效能上是否能滿足需求，還沒有實際測試暫不可知）
現在，就用稍加整理後的網上資料，簡單介紹下Postgres-XL。

Postgres-XL功能特性

• 開放原始碼：www.postgres-xl.org  
  Postgres-XL 全稱為 Postgres eXtensible Lattice，是TransLattice公司及其收購資料庫技術公司–StormDB的產品，是StormDB核心部分重塑後開源。
  開源協議使用寬鬆的“Mozilla Public License”許可，允許將開原始碼與閉原始碼混在一起使用。
• 完全的ACID支援
  
• 可橫向擴充的關係型資料庫（RDBMS）
  
  • 支援OLAP應用，採用MPP（Massively Parallel Processing：大規模平行處理系統）架構模式
  • 支援OLTP應用，讀寫效能可擴充  （注意，排在第一位的是OLAP！！！）
  • 叢集層級的ACID特性
  • 多租戶安全
  • 也可被用作分布式Key-Value儲存
• 交易處理與資料分析處理混合型資料庫
• 支援豐富的SQL語句類型，比如：關聯子查詢
• 支援絕大部分PostgreSQL的SQL語句
• 分布式多版本並發控制（MVCC：Multi-version Concurrency Control）
• 支援JSON和XML格式

Postgres-XL缺少的功能

• 內建的高可用機制
  
  • 使用外部機制實現高可能，如：Corosync/Pacemaker
  • 有未來功能提升的空間
• 增加節點/重新分區資料（re-shard）的簡便性
  
  • 資料重分布（redistribution）期間會鎖表
  • 可採用預分區（pre-shard）方式解決，在同台物理伺服器上建立多個資料節點，每個節點儲存一個資料分區。
    資料重分布時，將一些資料節點遷出即可
• 某些外鍵、唯一性限制式功能
  

Postgres-XL架構
      

• 基於開源項目Postgres-XC
  • XL增加了MPP，允許資料節點間直接通訊，交換複雜跨節點關聯查詢相關資料資訊，減少協調器負載。
• 多個協調器（Coordinator）
  • 應用程式的資料庫連入點
  • 分析查詢語句，產生執行計畫
• 多個資料節點（DataNode）
  • 實際的資料存放區
  • 資料自動打散分布到叢集中各資料節點
  • 本地執行查詢
  • 一個查詢在所有相關節點上並行查詢
• 全域交易管理員（GTM：Global Transaction Manager）
  • 提供事務間一致性視圖
  • 部署GTM Proxy執行個體，以提高效能

協調器（Coordinator）     

• 處理用戶端網路連接，是資料庫的存取點
  
• 分析查詢語句，產生執行計畫，並將計劃傳遞給資料節點實際執行
  
• 對資料節點返回的查詢中間結果集執行最後處理
  
• 管理事務兩階段交易認可（2PC）
  
• 儲存全域目錄（Global Catalog）資訊
  

      


資料節點（DataNode）
   

• 儲存表和索引資料
  
• 只有協調器串連到資料節點
  
• 執行協調器下傳的查詢
  
• 兩個資料節點間可建立一對一通訊串連，交換分布式表關聯查詢的相關資訊
  

      全域交易管理員（GTM）
       

• 處理必須的MVCC任務
  
  • Transaction IDs  事務ID
  • Snapshots          資料快照，MVCC使用
• 管理全域性資料值
  
  • Timestamps       時間戳記
  • Sequences         序列對象
• 全叢集只有一個GTM節點，會有單點故障問題。解決方案：配置StranBy熱備節點保證高可用
  

         

• 通過部署GTM Proxy，解決可能的GTM效能瓶頸

              
    GTM Proxy
      

• 與協調器（Coordinator）和資料節點（DataNode）在一起運行
  
• 後端（協調器、資料節點）用它替代GTM，直接與它互動，它做為後端與GTM間的中間人
  
• 將對GTM的請求分組歸集，多個請求一次提交給GTM
  
• 擷取transaction ids（XIDs）範圍
  
• 擷取資料快照
• 比如： 10個進程分別請求一個transaction id
  • 它們每一個都串連到本地的GTM Proxy
  • GTM Proxy發送請求到GTM，一次申請10個XID
  • GTM鎖定procarray資料結構，分配10個XID
  • GTM返回XID範圍
  • GTM解除進程互斥鎖

Postgres-XL資料分布
Postgres-XL資料分布有兩種模式： 複製表（Replicated Table）、分布表（Distributed Table）。（這兩個名詞很熟悉啊，貌似基於MySQL的開源列存MPP資料庫InfoBright也是這兩種方式，某個基本概念與InfoBright相似度很高的國產MPP資料庫也一樣。）

CREATE TABLE my_table (…)DISTRIBUTE BYHASH(col) | MODULO(col) | ROUNDROBIN | REPLICATION[ TO NODE (nodename[,nodename…])]

            

複製表（Replicated Table）

• 益用於唯讀和讀多寫很少的表
  
• 有時益用於資料倉儲的維度資料表
  
• 如果協調器與資料節點一對一部署在同一台伺服器，就會是本機資料讀取，減少網路傳送
  
• 對寫入頻繁的表嚴重不適用
  
• 每行記錄複製到叢集中所有的資料節點，每節點一份
  

分布表（Distributed Table）

• 益用於寫入頻率的表
• 益用於資料倉儲的事實表
• 每行記錄只存於一個資料節點
• 可用的分區策略方式
  • Hash
  • Round Robin
  • Modulo

Postgres-XL可用性

       

• 不存在單點故障
  
  • 全域交易管理員採用熱備方式（有熱備就不叫單點故障了嗎？）
  • 多個協調器間負載平衡
  • 資料節點使用流式複製，複製資料到備節點
• 但，但是，這一切目前都是手工的........... （主要是講流式複製？手工的，講個毛啊~）

Postgres-XL效能

交易處理型（OLTP Transaction）效能

• 測試使用針對電子商務應用的TPC-W（DBT-1）基準測試模型。
  
• 協調層增加了30%的開銷：在單節點（CPU4核）上，與簡單地直接使用PostgreSQL相比，只有PostgreSQL效能的70%。
  
• 叢集規模擴大到10個節點時，與單節點PostgreSQL相比，理論上應獲得7倍效能提升，實際上達到6-6.4倍。
  
• 隨著叢集節點數的增加，開啟的事務數、快照空間佔用、可見度檢查都會隨之增長。