大規模DBを見据えた
PostgreSQLの性能検証
2012年度活動成果報告
PostgreSQLエンタープライズ・コンソーシアム
WG1(性能WG)

WG1(性能ワーキンググループ）の役割
 技術部会で設定された課題に具体的に取り組む実

働部隊の一つで主に性能関係の課題をテーマとする ミッションクリティカル性の高いエンタープライズ領域への適用に向けて、本体・周辺ツールに関する技術ノウハウを共有する
 性能に関する課題の例
 CPUマルチコアに対する性能懸念
 負荷分散方式が確立されていない
 などなど（総数約50件)
 この中から問題点を整理し、PGEConsとして取り組んで効果がありそうなものをテーマ化
 さらに今年度実施するものを絞り込む
Copyright © PostgreSQL Enterprise Consortium, All Rights Reserved.

2

活動テーマ候補の一部抜粋


PGEConsにおける課題領域の中から性能検証テーマを分類、初年度はスケールアップとスケールアウトを選定

ＰＧＥＣｏｎｓにおける課題領域
性能

性能評価手法、性能向上手法、チューニ
ングなど

可用性

高可用クラスタ、BCP

保守性

保守サポート、トレーサビリティ

運用性

監視運用、バックアップ運用

セキュリティ

監査

互換性

データ、スキーマ、SQL、ストアドプロシー
ジャの互換性

接続性

他ソフトウェアとの連携

性能検証テーマ
性能評価手法オンラインやバッチなどの業
務別性能モデル、サイジング
手法

スケールアップ

マルチコアCPUでのスケールアップ性検証スケールアウト

負荷分散クラスタでのスケー
ルアウト性検証

性能向上機能クエリキャッシュ、パーティショ
ニング、高速ロードなど

性能チューニング

チューニングノウハウの整備、実行計画の制御手法

Copyright © PostgreSQL Enterprise Consortium, All Rights Reserved.

3

企業でのニーズ（ＷＧ１）
具体的な企業ニーズ

検証しておきたい技術①「最近のサーバはマルチコア化している。マルチコアサー
バでも性能メリットがあるDBMSを利用したい。」

コア数差による性能②「月次で、本店から町工場へ部材情報をバッチ転送している。町工場でも、よりタイムリーに本店の情報を見れると嬉しい。」

Cascading
Replication③「複数のサーバを並べて負荷分散をはかりたい。」

pgpool-II

Postgres-XC④「震災・停電時のＢＣＰ対策として、ディザスタリカバリ構成をとりたい。」

Cascading
Replication

pgpool-II⑤「自国から様々な海外拠点へ、ＤＢのデータを送って使用したい。」

Cascading
Replication⑥「サイズの大きいデータベースを扱いたい」⑦

ＷＧにて寄せられた意見：「PGEConsメンバ企業視点
でPostgres-XCはどんな印象？」

PostgreSQL本体 Postgres-XC

Postgres-XC

２０１２年度の注力部分（囲み）Copyright © PostgreSQL Enterprise Consortium, All Rights Reserved.

4

ＰＧＥＣｏｎｓへのご意見

ＰＧＥＣｏｎｓへ寄せられた意見（性能に関連するもののみ抜粋）
エンタープライズ領域で採用するための課題

ご意見元

技術検証項目候補

1 更新系のレプリケーショ
ン、複数台でのレプリ
ケーション

技術部会/ＷＧ１会合
セミナーアンケート(2012年7月)

マスタＤＢ更新性能への影響
多段構成（孫レプリケーション）

2 性能スケーラビリティが不足

セミナーアンケート(2012年7月,12月,2013年2月)

性能スケーラビリティ情報の拡充

3 負荷分散構成の情報が不足している

技術部会

実機検証情報の拡充

4 同期レプリケーション情報が不足している

技術部会

実機検証情報の拡充

5 既存アプリケーションの改修が必要

セミナーアンケート(2012年7月,12月,2013年2月)

スケールアウト、スケールアップに伴う改修要否

6 高可用構成での実績や事例が少ないセミナーアンケート(2012年7

実機検証情報の拡充

月,12月,2013年2月)

Copyright © PostgreSQL Enterprise Consortium, All Rights Reserved.

5

WG1(性能ワーキンググループ）の今年度テーマ
 スケールアップ検証
 多コアCPUでの性能検証
 PostgreSQL 9.2での到達点の把握
 pgbenchによる検索性能検証
 JDBCrunnerによるTPC-Cライクなベンチマーク

 スケールアウト検証
 以下のOSSについてスケールアウト特性を検証する
 PostgreSQL 9.2 カスケードレプリケーション
 非同期レプリケーション

 pgpool-II(レプリケーションモード)+ PostgreSQL 9.2
 同期レプリケーション+検索負荷分散

 Postgres-XC
 同期データ分散+更新負荷分散
Copyright © PostgreSQL Enterprise Consortium, All Rights Reserved.

6今年度の成果物
 スケールアップ、スケールアウト検証の手順および結果文書
 具体的なハードソフト構成、構築手順、検証結果デー
タを公開 検証結果、手順書、スクリプトなど
は再利用、再配布可能なライセン
スを設定する予定 「2012年度WG1活動報告書」として一冊にまとめた冊子を2013年4月に公開

Copyright © PostgreSQL Enterprise Consortium, All Rights Reserved.

7

実施体制


参加企業(企業名順)
 株式会社アイ・アイ・エム
 株式会社アシスト
 SRA OSS, Inc.日本支社(主査) NECソフト株式会社
 日本電気株式会社
 日本電信電話株式会社
 日本ヒューレット・パッカード株式会社
 株式会社日立製作所
 富士通株式会社

Copyright © PostgreSQL Enterprise Consortium, All Rights Reserved.

8報告1: スケールアップ検証


1.1 pgbenchによる検索性能スケールアップ検証
 80コアCPUマシンでのPostgreSQLの検索性能のスケールアップ特性を検証
 その結果、コア数と同じ80クライアントまで性能が向上することが確認できた

Copyright © PostgreSQL Enterprise Consortium, All Rights Reserved.

9

pgbench によるスケールアップ検証【 目的 】 多数コアでの参照において、クライアント数が増加したときにスケールアップするかどうかを確認する【 方法 】 カスタムスクリプトを作成し、pgbench -h [host] -p[port] [dbname] -c [c] -j [j] -T 30 -n -f custom.sql
を実行する
クライアント数（-c）を変動させる。スレッド数（-j）はその半分とする。
pgbench はクライアント用のマシンから実行する。

メモリ: 64GB

pgbench16コアpgbenchマシン

メモリ: 2TB

80コアPostgreSQLサーバ

Copyright © PostgreSQL Enterprise Consortium, All Rights Reserved.

10

pgbenchとは
 PostgreSQL上でベンチマーク試験を行うプログラム
 PostgresSQLに標準添付
 SQLコマンドの並びを自動実行し、実行結果のトランザクションの速度（ｔｐｓ: 1秒当たりのトランザクション数）の平均を計算する
 デフォルトで実行された pgbench は、1トランザクション当たり5つのSELECT、UPDATE、INSERTコマンドを含むおおよそTPC-Bに基いたシナリオを実行する
 カスタムシナリオを実行させることも可能

Copyright © PostgreSQL Enterprise Consortium, All Rights Reserved.

11実施したスクリプト(参照系トランザクション)¥set nbranches :scale¥set ntellers 10 * :scale¥set naccounts 100000 * :scale¥set row_count 10000¥set aid_max :naccounts - :row_count¥setrandom aid 1 :aid_max¥setrandom bid 1 :nbranches¥setrandom tid 1 :ntellers¥setrandom delta -5000 5000
SELECT count(abalance) FROM pgbench_accounts WHERE aid
BETWEEN :aid and :aid + :row_count;

Copyright © PostgreSQL Enterprise Consortium, All Rights Reserved.

12

結果
スケールファクタ1000
データ量: 1億件(15GB)

pgbench -S のように平易なトランザクションだと変化がでにくいが、負荷の高いトランザクションの場合、コア数と同じ 80 クライアントまで性能が向上する

Copyright © PostgreSQL Enterprise Consortium, All Rights Reserved.

13報告1: スケールアップ検証


1.2 JDBCrunnerによるスケールアップ検証
 更新系ベンチマークにより、セッション数に応じて性能が向上することが確認できた

Copyright © PostgreSQL Enterprise Consortium, All Rights Reserved.

14

更新系処理におけるスケールアップ検証 検証概要 JdbcRunnerによる更新系処理での性能測定
 データベース内部処理による性能への影響度合いを確認

 JdbcRunnerとは特徴・国産のJavaベース(JDBC接続)のデータベース負荷ツール
・ライセンスはNew BSD License
・各種DB （PostgreSQL、Oracle、MySQL)に対応し、Tiny SysBench、Tiny TPC-B、Tiny TPC-Cなどのテストスクリプトも提供されている

Tiny TPC-C

・TPC-C Standard Specification5.10.1を簡易実装したJdbcRunnerスクリプト
・仕様書のうち以下の章節を実装

注文を受けてから出荷するまでをシ
ミュレート

ダウンロード1 LOGICAL DATABASE DESIGN
2 TRANSACTION and TERMINAL PROFILES
2.4 The New-Order Transaction (2.4.1.1、2.4.3を除く)
2.5 The Payment Transaction (2.5.1.1、2.5.3を除く)
2.6 The Order-Status Transaction (2.6.1.1、2.6.3を除く)
2.7 The Delivery Transaction (2.7.1.1、2.7.2、2.7.3を除く)
2.8 The Stock-Level Transaction (2.8.1、2.8.3を除く)
4 SCALING and DATABASE POPULATION
4.3 Database Population
5 PERFORMANCE METRICS and RESPONSE TIME
5.2 Pacing of Transactions by Emulated Users
5.2.4 Regulation of Transaction Mix

JDBC Runnerのダウンロードは以下より
http://hp.vector.co.jp/authors/VA052413/jdbcrunner/（参考） http://hp.vector.co.jp/authors/VA052413/jdbcrunner/
Copyright © PostgreSQL Enterprise Consortium, All Rights Reserved.

15

JdbcRunnerによるスケールアップ検証
 セッションスケーラビリティ
 検証内容 CPUコア数を固定した状態で同時接続数を増加し、平均

TPM(Transaction Per Minute)の変化を確認
 結果
 セッション数の増加に伴い、平均TPMが向上することを確認
Tiny TPC-C測定結果（80core）

データサイズ:100GB

50,00045,000New-Order

40,00035,000

Payment

TPM

30,000Order-Status

25,00020,000

Delivery

15,00010,000Stock-Level

5,000

0
16

32

64
sessions

128

Copyright © PostgreSQL Enterprise Consortium, All Rights Reserved.

256

16

JdbcRunnerによるスケールアップ検証 アクセス対象データ範囲の拡大
 検証内容 データサイズおよびshared_buffersの値を増加させ、平均TPMの変化を確認
 検証結果 アクセス対象データの増加に対して急激な性能劣化はない shared_buffersのサイズを大きくすることにより性能が向上することを確認
Tiny TPC-C測定結果 （shared_buffers = 80GB）

Tiny TPC-C測定結果 （データサイズ1000GB）
6,000

40,0005,000

30,0004,000
New-Order

20,00010,000TPM

TPM

50,000New-Order

3,000
2,000
1,000

0
100

250
500
データサイズ（GB）

1000

0
80

160

shared_buffers(GB)Copyright © PostgreSQL Enterprise Consortium, All Rights Reserved.

17

JdbcRunnerによる基本検証
 データベース内部処理
 検証内容 以下のデータベース内部処理が性能に与える影響度合いを確認 checkpoint 自動VACUUM

 検証結果メンテナンス処理
checkpoint

結果
性能への影響は軽微考察・課題
checkpoint_completion_targetパラ
メータによる処理分散の効果が高い（今回の検証では0.7に設定）

自動VACUUM

性能への影響は軽微

遅延VACUUM機能による処理分散の効果が高い（今回の検証ではデフォルト値）

Copyright © PostgreSQL Enterprise Consortium, All Rights Reserved.

18

大容量データ(CSV)のロード性能測定
 COPYおよびインデックス生成等の実行時間を計測
30時間

27時間54分

27時間
24時間

処理時間

21時間
18時間
15時間

VACUUM,ANALYZE

 測定条件 PostgreSQL 9.2.1
 JDBC RunnerのTiny TPCCのデータ作成部をベースに
CSVを生成しCOPYを実行 archive_mode = off 全テーブル
FILLFACTOR ＝ 80

CREATE FOREIGN KEYS
CREATE INDEX(主キー）
COPY文（全テーブル Indexなし）

13時間00分

12時間
9時間

6時間20分
6時間
3時間

2時間27分

0時間
100

250

データ量（GB）

CSVのデータ量100GB
VACUUM , ANALYZE
4分
CREATE FOREIGN KEYS
51分
CREATE INDEX
34分
COPY文
56分
合計 2時間27分

500

1000

250GB
500GB
1000GB
12分
26分 1時間17分
2時間14分 4時間29分 9時間28分
1時間27分 3時間01分 7時間06分
2時間25分 5時間02分 10時間00分
6時間19分 13時間00分 27時間53分

Copyright © PostgreSQL Enterprise Consortium, All Rights Reserved.

19

更新系処理のCPUスケールアップ検証（１／４）
 大規模なCPU数の比較結果

セッション数を増やしていくと、TPM自体は上がっているが、
80coreと40coreで性能がほとんど変わらず、逆転しているところもある
Copyright © PostgreSQL Enterprise Consortium, All Rights Reserved.

20

更新系処理のCPUスケールアップ検証（２／４）
 ４０コア検証時のクライアントとサーバのCPU使用状況
Client CPU使用状況

40core Server CPU使用状況
最大でも使用率は50%程度

別の
評価中

最大でも
15%程度

別の
評価中

小

同時接続セッション数

大小

同時接続セッション数

大40coreの時点で、すでにサーバとクライアントのCPUリソースは余っている状態に
Copyright © PostgreSQL Enterprise Consortium, All Rights Reserved.

21

更新系処理のCPUスケールアップ検証（３／４）
 ４０コア検証時のサーバのストレージ使用状況
40core Server DB領域（base)の
I/O状況

別の
評価中

小

40core Server トランザクションログ(pg_xlog)のI/O状況

別の評価中
セッション数が増える前からutil%が100%近くであり非常に負荷が高い

同時接続セッション数

大

トランザクションログもutil%が最大75%程度となり、負荷が高い

小

同時接続セッション数

大DB領域のI/OネックであまりCPUリソースを活用できていない状況と推測
Copyright © PostgreSQL Enterprise Consortium, All Rights Reserved.

22

更新系処理のCPUスケールアップ検証（４／４）


I/Oボトルネックの解消に向けて３月再検証も、同様の傾向
 DB領域をTABLESPACEで分けてI/O負荷分散
 データサイズを100GBを50GBに減少
データサイズ50GB、共有バッファサイズ80GB、測定時間300秒(TPM)

40core(TPM)

80core(セッション数)(セッション数)

前回の検証と同様にサーバのCPUはまだ使い切れておらず、
WALやDB領域のI/Oの負荷が高い状況が続いていることが確認できた⇒ I/Oネックを解消すれば更なるスケーラビリティが確認できるかも
Copyright © PostgreSQL Enterprise Consortium, All Rights Reserved.

23報告2: スケールアウト検証


2.1 PostgreSQL 9.2 カスケードレプリケーション検証
 レプリケーションノード（マスタから見て孫ノード）数を変化させて、マスタＤＢの更新性能を測定
 レプリケーションノードの増加がマスタＤＢの更新性能に与える影響は小さいことが確認できた

Copyright © PostgreSQL Enterprise Consortium, All Rights Reserved.

24更新系・複数台レプリケーション検証 (PostgreSQL 9.2)


カスケードレプリケーション（非同期）を適用したモデルとして、本店から町工場へ部材情報をタイムリーに流す形態を想定
移植性from ...
イントラネット
インターネット
他DB・異種DB

可用性

Webアプリ

MasterCascading Standby
promote

相互運用性

更新

運用性

Streaming Replication

データ

マスタＤＢ更新性能?

Streaming Replication[ 本店 ]

検証部分
Webアプリ
リアルタイムでのデータ活用業務

StandbyStandby

参照

参照[ 町工場 ]

[ 町工場 ]

Copyright © PostgreSQL Enterprise Consortium, All Rights Reserved.

...
スケールアウト構成
25

検証目的：マスタＤＢ更新性能への影響確認カスケードレプリケーション（非同期）ではノード数が増えていくと、マスタＤＢの更新性能はどのような特性になるのか？

tps

更新性能に
影響が出るケース

tps

更新性能は
安定しているケース

ノード数

ノード数を変化させる

ノード数

tpsは本店での更新スループット、ノード数は町工場の数に相当
Copyright © PostgreSQL Enterprise Consortium, All Rights Reserved.

26

検証構成




MasterとCascadingStandbyは外部ストレージ、Standbyはスタンドアローン
負荷クライアントからネットワーク経由でMasterへデータ更新
Master→CascadingStandby→Standby×4 へネットワーク経由でレプリケーション

更新
pgbench

本店

Master

本店

負荷クライアント※pgbench ： PostgreSQLに標準で付属しているベンチマークツール。OLTP系のTPC-Bに基いたシナリオを実行。
- 基本特性検証のため高負荷ベンチマークを利用して検証。
- scaling factor：100（1000万レコード/約1.5GB）- ベンチマークモデル：標準（TPC-B）- 実行オプション：-c 100 -j 10 -T 30

本店

CascadingStandby町工場

Standby町工場

Standby町工場

Standby町工場

Standby

外部ストレージ

PostgreSQLサーバ

Copyright © PostgreSQL Enterprise Consortium, All Rights Reserved.

27

PostgreSQL 9.2 カスケードレプリケーション検証結果
t 更
新
p
性
s 能

更新性能は
安定している1

ＣＰＵ利用率100

Master50
0

CascadingStandby100
500StandbyStandbyStandbyStandby

100
0

2
wa
sy

100
50

us
wa
sy
us

0
100
50

0
100
0
100
0

ノード数
wa
sy
us
wa
sy

us

3

100
50
0
100
50

0
100
0
100
0
100
0

4
wa
sy
us
wa
sy

us

100
50
0
100
50

0

wa
sy
us
wa
sy

us

100
0
100
0
100
0
100
0

ノード数が増えてもマスタＤＢの更新性能はほぼ一定で安定している機器構成にもよるが基本特性としてはノード数増がマスタＤＢへ与える影響は小さい
Copyright © PostgreSQL Enterprise Consortium, All Rights Reserved.

28

ネットワークやストレージ構成について構成によっては更新性能に影響が出るケースもある ネットワークやストレージを同一で更新性能を測定
 スケールアウト上のボトルネックとなる可能性更新
pgbench

Master

負荷クライアント

すべてのノード間で同一ネットワークを利用

CascadingStandby

構成によっては更新性能に影響が出る

StandbyStandbyStandby

外部ストレージStandbyPostgreSQLサーバ

すべてのノードから同一ストレージへアクセス

Copyright © PostgreSQL Enterprise Consortium, All Rights Reserved.

29報告2: スケールアウト検証


2.2 pgpool-IIによるスケールアウト検証
 更新系処理では、ノード数に応じて性能が劣化することが確認できた
 参照系処理では、ノード数に応じて性能が向上することが確認できた

Copyright © PostgreSQL Enterprise Consortium, All Rights Reserved.

30

pgpool-IIとは

PostgreSQL サーバとクライアントの間に入ってプロキシサーバとして動作するソフトウェア
機能概要

コネクションプール

データベースへの接続を保持して使いまわす機能（ＤＢにとってコストが高い
新規受け付け処理を低減できる）

接続数の制限

設定した最大同時接続数を超えた接続要求に対して、接続待ちをさせる機能（PostgreSQL←→アプリ間に pgpool-II を挟むことで、ＤＢの同時接続数
をエラーを出さずに一定数に抑えることができる）

レプリケーション

データベースの複製を作って、その後にデータ更新処理があっても、同じデータ状態を維持していく機能
同期レプリケーション形式で実装されている（全てのノードで SQL がコミットされてからアプリケーションに処理を返す）

負荷分散

SQL の内容が参照処理か更新処理かを自動的に区別し、参照の問い合わ
せについては処理を振り分けて実行する機能※ pgpool-II は、参照ＳＱＬはどれか1ノードのＤＢに対してのみ実行させる

パラレルクエリ（並列問い合わせ）1つの SQL について対象となるテーブルを分散配置しておき、各ノードで並列に処理を行い、統合した結果を返すようにする機能

Copyright © PostgreSQL Enterprise Consortium, All Rights Reserved.

31

pgpool-II によるスケールアウト検証
目的 pgpool-II(3.2.1) & PostgreSQL(9.2.1) で、ノード数を増やすと全体の処理能力が向上するかどうかを確認する

方法
 pgbench の各ノードでの結果を合計する

pgbench はクライアント用のマシンから実行する
更新系性能の測定は、 pgbench のデフォルトシナリオを用いる
参照系性能の測定は、 極力 I/O ネックの発生を抑えた状態で実行するため、カスタムシナリオ
を用いる

更新

pgbenchpgbenchpgbenchpgbenchpgpool-II

pgpool-II ※pgpool-II ※pgpool-II ※PostgreSQL

PostgreSQL

PostgreSQL

参照

PostgreSQL※ ２台目以降簡略化の為矢印は省略。
Copyright © PostgreSQL Enterprise Consortium, All Rights Reserved.

32

更新系の結果

TPS

total tps
average per a node

800

800

700

700

600

600

500

500

400

400

300

300

200

200

100

100

0



以下の条件・指定でpgbenchを実行






シェアードメモリ: 16GB
SF値: 1000 でデータを準備
実施時間(-T): 300秒
同時実行クライアント数(-c): 100
ワーカスレッド数(-j): 20

0
1

2

3

4

nodes count 2 ノード以上では、ノード数が増えるほど合計の tps が減少する
 同期レプリケーションを行うため、更新処理を行わせた場合性能が出にくい 各ノードのデータの書き込み先を物理的に分散させることで、性能の劣化度を多少改善できる
Copyright © PostgreSQL Enterprise Consortium, All Rights Reserved.

33参照系の結果



以下の条件・指定でpgbenchを実行







total tps
average per a node

100,000
90,00080,000

シェアードメモリ: 32GB
SF値: 1000 でデータを準備
実施時間(-T): 300秒
同時実行クライアント数(-c): 100
ワーカスレッド数(-j): 20
実行シナリオ名(-f): カスタムシナリオ
ファイル名を指定
試験前バキュームの禁止(-n)

70,000TPS

60,00050,00040,00030,00020,00010,000
0
1

2

3

4

nodes count

以下のカスタムシナリオを用意¥set nbranches :scale¥set ntellers 10 * :scale¥set naccounts 100000 * :scale¥set range 2000
¥set aidmax :naccounts - :range¥setrandom aid 1 :aidmax¥setrandom bid 1 :nbranches¥setrandom tid 1 :ntellers¥setrandom delta -5000 5000
SELECT count(abalance) FROM
pgbench_accounts WHERE aid
BETWEEN :aid and :aid + :range; ノード数が増えるほど、合計の tps が増える（スケールメリットあり）

Copyright © PostgreSQL Enterprise Consortium, All Rights Reserved.

34報告2: スケールアウト検証


2.3 Postgres-XCによるスケールアウト検証
 更新系処理では、ノード数に応じてスケールアップすることが確認できた 参照系処理では、データ量が多いときにスケールアップすることが確認できた

Copyright © PostgreSQL Enterprise Consortium, All Rights Reserved.

35

Postgres-XCとは①


大規模システムを想定したデータベースクラスタ
複数のDatanodeにデータを分散配置し更新負荷を分散
複数のCoordinatorとDatanodeに参照負荷を分散

クライアント・・・
複数のDatanodeに透過的にアクセス

Coordinator

・・・
GTM

Datanode

・・・
データを分散格納
Copyright © PostgreSQL Enterprise Consortium, All Rights Reserved.

クラスタ全体のトランザクション管理
36

Postgres-XCとは②
 Postgres-XCを構成するコンポーネント
Coordinator

クライアントからの接続を受け付け、参照・更新要求を
Datanodeに要求し、処理結果を取りまとめて返却する。

Datanode

実際にデータが格納され、参照・更新処理を実行する。

GTM

データベースクラスタ全体のトランザクション管理を行う。

GTM Proxy

GTMへの通信負荷を軽減するためのプロキシ。

Copyright © PostgreSQL Enterprise Consortium, All Rights Reserved.

37

Postgres-XC によるスケールアウト検証【 目的 】 Postgres-XC 1.0.1（PostgreSQL 9.1.5 がベース）で、ノード数を増やすと全体の処理能力が向上するかどうかを確認する【 方法 】 pgbench の各ノードでの結果を合計する。
pgbench はクライアント用のマシンから実行する。
使う pgbench は Postgres-XC 同梱の改造版。-k オプシ
ョンをつけて初期化するとテーブルの分割を行なう。


Coordinator
Datanode
GTM proxy

Coordinator
Datanode
GTM proxyGTMpgbenchclients

Postgres-XC
Copyright © PostgreSQL Enterprise Consortium, All Rights Reserved.

38更新系の結果
pgbench -i -k-s 100(total: 1.5GB)

pgbench-c 100 -j 10-n -k-T 6002 ノード以上では、ノード数が増えるほど合計の tps が増える。

Copyright © PostgreSQL Enterprise Consortium, All Rights Reserved.

39参照系の結果（pgbench -n -k -S）
pgbench -i -k-s 1000(total: 15 GB)

pgbench-c 100 -j 10-n -k -S
-T 300
PostgreSQL
9.1.5

ノード数が増えるほど、合計の tps が増える。ただし、データが複数のDatanodeに分散されているため、参照系では性能が出にくい。
Copyright © PostgreSQL Enterprise Consortium, All Rights Reserved.

40参照系の結果（PostgreSQL単体と比べて） PostgreSQL単体との性能比ではXCが不利に

PostgreSQL
単体性能

Copyright © PostgreSQL Enterprise Consortium, All Rights Reserved.

41

参照系の結果（考察） XCに最適化した性能測定ではなかった可能性
 分割／レプリケーションの判断基準
 Transaction tables

 Master tables→ Distributed→ Replicate

 今回の測定条件
 XC付属のpgbenchでデータ作成時に“-k”（すべての表を分割）を指定
 低負荷のトランザクションを大量に実行
 更新系の検証はDBサイズが小さいため、トランザクション同士の競合により、性能が制約されていた可能性が高い
 pgbenchで個々のデータノードが処理するSQLは極めて低負荷であり、ノード間通信やロックのオーバヘッドが相対的に大きくなる

測定パターンの変更や最適化は2013年度以降の実施を検討
Copyright © PostgreSQL Enterprise Consortium, All Rights Reserved.

42初年度活動をふりかえって 初年度はどのように進めていくかも含め、実際に活動しながら試行錯誤して進めるワーキンググループを作る期間だった 日頃は競合することもある複数企業メンバーが、共同検証を通じ交流を深めることができ、 PGECons設
立趣旨に合致した活動をスタートできた PostgreSQL 9.3の新機能検証など、何かやってみた
いと思われた方は次の活動を一緒に実施していきましょう！

Copyright © PostgreSQL Enterprise Consortium, All Rights Reserved.

43

今後の予定 2013年度ＷＧ１メンバ募集＆活動内容検討
 WG1メンバ募集
 5月16日キックオフ、具体的な活動内容を検討
 PostgreSQL 9.3 のリリース時期に合わせた実機性能検証

 PGCon 2013 The PostgreSQL Conference 5月カナダで講演 WG1/WG2“Introducing PostgreSQL Enterprise Consortium activities”
Talks-Day2-2013-05-24, Track: Case Studies
 PGEConsの活動として初のWorldWideでの紹介

Copyright © PostgreSQL Enterprise Consortium, All Rights Reserved.

44

まとめ


スケールアップ検証
 従来公表されている64コアを上回る80コアでの検証を実施
 検索処理／更新処理ともにPostgreSQLが高いCPUスケー
ラビリティを持つことを確認できた
 スケールアウト検証
 PostgreSQLカスケードレプリケーション、pgpool-II、

Postgres-XCという異なるスケールアウトソリューションを検証 カスケードレプリケーションはノード数が増えても安定した更新性能を維持
 Pgpool-IIは参照系に強み
 Postgres-XCは更新系に強み
Copyright © PostgreSQL Enterprise Consortium, All Rights Reserved.

45

付録：今回使用した検証環境について
スケールアップ検証では日本ヒューレット・パッカード
株式会社様から検証環境をご提供いただきました スケールアウト検証では株式会社日立製作所様、日本電気株式会社様から検証環境をご提供いただきました PostgreSQLエンタープライズ・コンソシアムとして御礼を申し上げます

Copyright © PostgreSQL Enterprise Consortium, All Rights Reserved.

46

付録：検証環境１ （提供： 日本ヒューレット・パッカード株式会社）
スケールアップ検証での使用機器/設備
HPソリューションセンター

HP ProLiant DL980G7

Network
SwitchCPU: Xeon E7-4870(10Core) × 8 [80Core]
HP ProLiant DL360pGen8
Memory: 2TB / HDD: 900GB x 8
CPU: Xeon E5-2690(8Core) × 2 [16Core]
Memory: 64GB / HDD: 300GB 10k x 4

FC Switch

FC Switch

VPN
VRAID5 [20]

VRAID1 [20] VRAID5 [20]
VRAID0 [20]

VRAID5 [20]HP P6550 Enterprise Virtual Array

インターネット経由
HDD: 900GB (6G SAS 10K 2.5inch) x 100 [20本×5セット]
リモートアクセス © Copyright 2013 Hewlett-Packard Development Company,L.P.
Copyright © PostgreSQL Enterprise Consortium, All Rights Reserved.

47

付録：検証環境２ （提供： 株式会社 日立製作所）
 スケールアウト検証での使用機器/設備
ハーモニアス・コンピテンス・センター★BS500 ： 6ブレード( BladeSymphony BS520H )PostgreSQLサーバとして使用
CPU:インテルXeon E5-2670(2.60GHz)８コア×２
メモリ:64GB: 1台
HDD:600GB×2 RAID1( Hitachi Adaptable Modular Storage 2100 )★AMS2000

ストレージとして使用
450GB（SAS 15,000min-1）×15
RAID5(4D+1P)

サーバルーム★HA8000 : 2台
( HA8000/RS210AL )検証ルーム

負荷クライアントとして使用
CPU:インテルXeon X5675(3.06GHz)６コア×２
メモリ:16GB
HDD:600GB×4 RAID6
JR品川駅 港南口より徒歩約3分
京浜急行品川駅 高輪口より徒歩約5分© Hitachi, Ltd. 2013. All rights reserved.
Copyright © PostgreSQL Enterprise Consortium, All Rights Reserved.

48

付録：検証環境３ （提供：日本電気株式会社）
 スケールアウト検証での使用機器/設備
ＮＥＣプラットフォームイノベーションセンター
Server & Client

Express5800/B120d Blade 12台(ＤＢサーバ 10台 – 負荷クライアント 2台)CPU：XeonプロセッサーE5-2470(2.30GHz 8Core 20M) × 2 socket
メモリ：32GB (8GB ×4)
HDD：300GB(2.5型SAS 15,000rpm) ×2







Storage

RAID1

1000BASE-T：4ポート （標準の2ポート含む）
Fibre Channelコントローラ(8Gbps/2ch) ｘ 1（データベース格納領域）

iStorage/M300 1台

コントローラ数： 2台 （ＦＣコントローラ）
キャッシュメモリ： 16ＧＢ
ＦＣポート数： 8個 （8G対応 4ポート／1コントローラ）
ディスク： SAS 3.5型 15krpm 600GB ×20玉RAID5 (4D + P)
© NEC Corporation 2013. All rights reserved.
Copyright © PostgreSQL Enterprise Consortium, All Rights Reserved.

49

Copyright © PostgreSQL Enterprise Consortium, All Rights Reserved.

50