摘要：最近研究了的兩種集群方案，分別是和，在這里總結一下二者的機制結構優(yōu)劣測試結果等。其中的前身的，的前身是。為了避免單點故障，可以為所有節(jié)點配置對應的節(jié)點。測試測試結果測試結果顯示，兩種集群與單機的性能指標幾乎一致，無法分辨高下。

最近研究了PG的兩種集群方案，分別是Pgpool-II和Postgres-XL，在這里總結一下二者的機制、結構、優(yōu)劣、測試結果等。

1、 Pgpool-II和Postgres-XL簡介
據(jù)我目前的了解，Pgpool-II和Postgres-XL是PG集群開源實現(xiàn)中比較成功的兩個項目，互聯(lián)網(wǎng)上相關的介紹也不少，但尚不確定二者在企業(yè)生產(chǎn)環(huán)境中是否被廣泛使用。其中Pgpool-II的前身的Pgpool-I，Postgres-XL的前身是Postgres-XC。
1.1、Pgpool-II
Pgpool-II相當于中間件，位于應用程序和PG服務端之間，對應用程序來說，Pgpool-II就相當于PG服務端；對PG服務端來說，Pgpool-II相當于PG客戶端。由此可見，Pgpool-II與PG是解耦合的，基于這樣的機制，Pgpool-II可以搭建在已經(jīng)存在的任意版本的PG主從結構上，主從結構的實現(xiàn)與Pgpool-II無關，可以通過slony等工具或者PG自身的流復制機制實現(xiàn)。除了主從結構的集群，Pgpool-II也支持多主結構，稱為復制模式，該模式下PG節(jié)點之間是對等的，沒有主從關系，寫操作同時在所有節(jié)點上執(zhí)行，這種模式下寫操作的代價很大，性能上不及主從模式。PG 9.3之后支持的流復制機制可以方便的搭建主從結構的集群（包括同步復制與異步復制），因此Pgpool-II中比較常用的模式是流復制主從模式，其結構如下圖（也可以一主多從）。

既然PG可以通過自身的流復制機制方便的搭建主從結構集群，為什么還要在它上面搭建Pgpool-II呢？因為簡單的主從結構集群并不能提供連接池、負載均衡、自動故障切換等功能，Pgpool-II正好可以做到這些，當然負載均衡只針對讀操作，寫操作只發(fā)生在主節(jié)點上。為了避免單點故障，Pgpool-II自身也可以配置為主從結構，對外提供虛擬IP地址，當主節(jié)點故障后，從節(jié)點提升為新的主節(jié)點并接管虛擬IP。
1.2、Postgres-XL
Postgres-XL的機制和Pgpool-II大不相同，它不是獨立于PG的，是在PG源代碼的基礎上增加新功能實現(xiàn)的。簡單來說，Postgres-XL將PG的SQL解析層的工作和數(shù)據(jù)存取層的工作分離到不同的兩種節(jié)點上，分別稱為Coordinator節(jié)點和Datanode節(jié)點，而且每種節(jié)點可以配置多個，共同協(xié)調(diào)完成原本單個PG實例完成的工作。此外，為了保證分布模式下事務能夠正確執(zhí)行，增加了一個GTM節(jié)點。為了避免單點故障，可以為所有節(jié)點配置對應的slave節(jié)點。Postgres-XL結構圖見下圖，來自官網(wǎng)。

Postgres-XL的Coordinator節(jié)點是整個集群的數(shù)據(jù)訪問入口，可以配置多個，然后在它們之上通過Nginx等工具實現(xiàn)負載均衡。Coordinator節(jié)點維護著數(shù)據(jù)的存儲信息，但不存儲數(shù)據(jù)本身。接收到一條SQL語句后，Coordinator解析SQL，制定執(zhí)行計劃，然后分發(fā)任務到相關的Datanode上，Datanode返回執(zhí)行結果到Coordinator，Coordinator整合各個Datanode返回的結果，最后返回給客戶端。
Postgres-XL的Datanode節(jié)點負責實際存取數(shù)據(jù)，數(shù)據(jù)在多個Datanode上的分布有兩種方式：復制模式和分片模式，復制模式下，一個表的數(shù)據(jù)在指定的節(jié)點上存在多個副本；分片模式下，一個表的數(shù)據(jù)按照指定的規(guī)則分布在多個數(shù)據(jù)節(jié)點上，這些節(jié)點共同保存一份完整的數(shù)據(jù)。這兩種模式的選擇是在創(chuàng)建表的時候執(zhí)行CREATE TABLE語句指定的，也可以通過ALTER TABLE語句改變數(shù)據(jù)的分布方式。

2、 Pgpool-II和Postgres-XL對比

3、 Pgpool-II和Postgres-XL的性能測試
我分別使用pgbench和benchmarksql測試了Pgpool-II集群和Postgres-XL集群的性能，為了對比，還測試單機PG的性能。
測試條件：Pgpool-II集群是搭建在兩臺虛機上的主從復制（異步）集群；Postgres-XL集群也是搭建在相同條件上的兩臺虛機的集群，其中包含兩個Coordinator節(jié)點和兩個Datanode節(jié)點。單機PG也是運行在相同條件的虛機上。操作系統(tǒng)是CentOS 6.6，單機PG和Pgpool-II集群種的PG版本號是9.5，Postgres-XL的版本號是Postgres-XL 9.5 R1.3，也只基于PG 9.5的。
3.1、pgbench測試
pgbench是PG自帶的一款簡單的PG性能測試工具，測試指標是TPS，表示每秒鐘完成的事務數(shù)。測試過程如下：
1) 建庫

psql -h 10.192.33.244 -p7777 -c "create database pgbench"

2) 生成數(shù)據(jù)

pgbench -i -s 1000 -h 10.192.33.244 -p 7777 pgbench 
#參數(shù)-s指定數(shù)據(jù)量，這里使用1000，最終生成的數(shù)據(jù)量大小約16G。

3) 測試

pgbench -h 10.192.33.244 -p7777  -c30 -T300 -n 
#測試時間5分鐘，連續(xù)測試3次。 

pgbench測試結果：

pgbench的測試結果顯示，Pgpool-II集群的性能比單機PG的性能差一些，約為84%；Postgres-XL集群的性能比單機PG的性能好一些，約為137%。
3.2、benchmarksql測試
benchmarksql的是一款常用的TPC-C測試工具，TPC-C測試衡量的是數(shù)據(jù)庫的OLTP性能。測試過程如下：
1) 建庫

psql -h 10.192.33.244 -p7777 -c "create database tpcc"

2) 生成數(shù)據(jù)

./runDatabaseBuild.sh props.pg
#props.pg為配置文件，配置數(shù)據(jù)庫鏈接信息以及測試數(shù)據(jù)量、測試時間等，
#這里配置的數(shù)據(jù)量是100 warehouse，最終生成的數(shù)據(jù)約10G，測試時間1小時。

3) 測試

./runBenchmark.sh props.pg

benchmarksql測試結果：

benchmarksql測試結果顯示，兩種集群與單機PG的性能指標幾乎一致，無法分辨高下。出現(xiàn)這種結果的可能原因之一是：測試數(shù)據(jù)量較小，無法發(fā)揮集群的性能優(yōu)勢，尤其像Postgres-XL這個集群在設計上針對大數(shù)據(jù)處理做了一些優(yōu)化，應該更加適合大數(shù)據(jù)處理的場景。鑒于benchmarksql測試生成數(shù)據(jù)十分耗時，這里就不再進行較大數(shù)據(jù)量的測試了。

最后，綜合來看，我更傾向于Postgres-XL，如果公司今后打算用的話，我會推介。