f pgbench and dbt-3 test on PGXL Cluster ~ 迪貝之家

Pages

pgbench and dbt-3 test on PGXL Cluster

pgbench 的測試劇本沒辦法呈現XL優勢,底下是pgbench 預設的交易語法
BEGIN;

UPDATE pgbench_accounts SET abalance = abalance + :delta WHERE aid = :aid;

SELECT abalance FROM pgbench_accounts WHERE aid = :aid;

UPDATE pgbench_tellers SET tbalance = tbalance + :delta WHERE tid = :tid;

UPDATE pgbench_branches SET bbalance = bbalance + :delta WHERE bid = :bid;

INSERT INTO pgbench_history (tid, bid, aid, delta, mtime) VALUES

(:tid, :bid, :aid, :delta, CURRENT_TIMESTAMP);

END;
從語法中看到where condition 都透過aid 在處理資料,這是一個Primary Key 的欄位,所以每次處理資料就是單筆,但在XL的架構下,並不是每筆資料都是在local端進行處理,與Oracle RAC技術不同點是在於,XL會把sql語句拋到remote node執行後彙整結果,所以會有remote query的overhead(這可以從系統的log看得到remote query 的進行) ,因此不能使用pgbench 的預設劇本來進行測試比較,我找了一個叫做DBT3  的Open Source工具來進行PG與PGXL的壓力測試

DBT3 是遵循TPCH的規格開發的,已經在Postgres 10.4測過是可用的,但在XL 10Alpha2 下,好像有點問題,因為測試會停在第九個查詢語法,從datanode 的log來看,這段記錄會一直被拋出來execute p_1_5cb6_2/p_1_5cb6_2: Remote Subplan,不確定問題發生在哪裡??進行DBT-3  TPC-H benchmark XL95 及 Single 95 測試比較後,XL 有兩個缺點 :


  • 複雜查詢效能比不上單一instance,如subqery,越簡單的sql查詢,它的效能會顯示出來。
  • 當它沒辦法解析語法時,也就是不知道怎麼執行你丟給它的sql 語法時整個cluster 有可能當掉。


我認為XL是個未成熟,甚至可以說,它還是個實驗中產品,上述的第二點是個很大的致命傷,我不建議使用它,因為風險太高。如果要找MPP解決方案 ,應該花時間在GREENPLUM的研究。