本次測試的主體有3個，分別為：
測試主體
版本
postgresql版本
postgis版本gp
4.3.8.2
8.2.15
2.0xc
1.0.4
9.1.13
2.1pgsql
9.1.13
9.1.13
2.1所有的環境均搭建在7層機房6臺（編號1－6）1u的伺服器上，各台伺服器的配置如下：
引數項
配置
cpu32核記憶體
64g磁碟
4塊7200轉sata，未做raid
網路4塊千兆網絡卡，1和2作mode=2的繫結，3和4各連乙個交換機，各組乙個區域網
gp集群採用1個master（執行在編號1的伺服器/dev/sda上），6個segment host（對應編號1－6的伺服器）的組織方式，每個segment host啟動3個例項，分別位於不同的物理磁碟上（/dev/sdb 、/dev/sdc 、/dev/sdd）。
xc集群採用1個gtm（執行在編號1的伺服器上），1個gtm_standy（執行在編號1的伺服器上），4個gtm_proxy（對應編號3－6的伺服器），4個coordinator（對應編號3－6的伺服器），4個datanode（對應編號3－6的伺服器）的組織方式。coordinator執行於/dev/sda，datanode執行於/dev/sdb。
pgsql採用xc集群中編號3伺服器上執行的datanode。
測試並對比三個測試主體的入庫、查詢效能。
本次測試使用了三個測試工具：
使用pgbench測試不同壓力條件下，複雜面狀要素的入庫效率
使用org2ogr測試不同客戶端連線數條件下，fgdb檔案的入庫效率。fgdb有要素1178840條，820m。
使用tpc-h測試固定大小非空間資料的入庫效率
使用tpc-h測試複雜查詢的查詢效率
測試主體
連線數
3分鐘插入記錄數
每秒事務數xc
2*24
4*24
gppgsql
測試主體
org2ogr程序數
總耗時(unit=m)xc
40+32+32
40+30+30+30
pgsql
gp使用tpc-h將8張總大小為200g，總記錄數約1.7億的資料入庫。耗時情況如下：
xc(unit=m)
gp(m)
pgsql(m)
耗時8.05
6.821.9
查詢sql編號
xc(unit=s)
gp(s)
pgsql(s)
timeout
timeout
timeout
timeout
timeout
timeout
可能是postgis版本較低的原因，gp處理空間資料的效率不高。正如4.1與4.2中所反映，入向量資料效率較低。xc處理空間資料的效能要優於gp。
對於小事務的擴充套件能力，xc的效能最好。這得宜於它的架構支援多個coordinator，使得將客戶連線負載均衡到不同的協調器中；
gp作為決策支援型資料庫，對於大資料量的查詢分析，效率很高；
如果事務數非常少（以本例來看，在小於20－30的情況下），集群的效能不如單機的效能；
Redis Sentinel 哨兵 集群解決方案
size x large color black b redis 哨兵的服務框架 b color size 哨兵也是 redis 伺服器，只是它與我們平時提到的 redis 伺服器職能不同，哨兵負責監視普通的 redis 伺服器，提高乙個伺服器集群的健壯和可靠性。哨兵和普通的 redis 伺服器所用...
Oracle RAC集群環境啟動失敗解決方法
問題找到了，是因為crs訪問不到而導致asm啟動不起來，找了幾天也沒有找到解決的辦法，最後實在無奈重新建立了crs就ok了。在兩個節點上刪除之前的crs配置資訊，root racdb2 install rootcrs.pl verbose deconfig force 然後重新執行root.sh指令...
Postgresql刪除資料庫失敗解決方法
pgadmin右鍵建立資料庫很簡單起個名字就可以了。本以為刪除也很簡單，右鍵刪除drop就可以了，可是偏偏刪除的時候報錯 error database dbname is being accessed by other users detail there are 2 other sessions ...