PostgreSQLエンタープライズ・コンソーシアム 技術部会 WG#1

2016年度WG1活動報告書

PostgreSQL Enterprise Consortium

目次
目次
1. はじめに1.1. PostgreSQLエンタープライズコンソーシアムとWG1について
1.1.1. 各WGとWG1の活動テーマ
1.2. WG1の活動テーマ
1.3. 本資料の概要と目的
1.3.1. 2016年度の活動テーマ
1.3.2. 定点観測（スケールアップ）
1.3.3. パラレルクエリ
1.3.4. JSON/JSONB
1.3.5. VACUUM改善
1.3.6. 全文検索
1.3.7. Pgpool-II検証
1.4. 成果の公開
1.4.1. 2015年度までの活動テーマの紹介
1.5. 実施体制
1.6. 実施スケジュール
1.7. 謝辞
1.8. 参考文献
2. 定点観測(スケールアップ検証・参照系)
2.1. 検証概要
2.2. pgbench とは
2.3. 検証構成
2.3.1. ハードウェア構成
2.3.2. ソフトウェア構成
2.3.3. カーネル設定
2.3.4. PostgreSQL 設定
2.4. 検証方法
2.4.1. 環境
2.4.2. 測定
2.5. 検証結果
2.6. 考察
3. 定点観測(スケールアップ検証・更新系)
3.1. 検証目的
3.2. 検証構成
3.3. 検証方法
3.3.1. 環境構築
3.3.1.1. データベース初期設定
3.3.1.2. postgresql.confの設定値
3.3.2. 測定
3.3.2.1. pgbenchスクリプト(測定対象トランザクション)
3.3.2.2. pgbenchの実行方法
3.3.2.3. 測定結果の取得
3.3.3. 測定パラメータ
3.4. 検証結果
3.4.1. CPUスケーラビリティ
3.4.2. バージョン比較
3.5. 考察4. パラレルクエリ
4.1. 検証概要
4.2. パラレルクエリとは
4.2.1. パラレルクエリ
4.2.2. PostgreSQL9.6でのパラレルクエリ
4.2.3. パラレルクエリに関連するパラメータ
4.3. 検証構成
4.3.1. 検証ハードウェア構成
4.3.2. 検証ソフトウェア構成
Page 2 of 78

2
6
6
6
6
6
6
7
7
7
7
7
8
8
8
8
8
9
9
10
10
10
11
11
12
12
12
12
12
13
13
16
17
17
17
17
17
17
17
18
18
18
18
18
19
19
20
21
23
23
23
23
23
24
24
24
25

PostgreSQL Enterprise Consortium

4.4. 検証方法
4.4.1. 検証項目
4.4.1.1. 検証A
4.4.1.2. 検証B
4.4.1.3. 検証C
4.4.2. データモデル
4.4.3. DB設定
4.4.4. 測定手順
4.4.4.1. 検証A測定方法
4.4.4.2. 検証B測定方法
4.4.4.3. 検証C測定方法
4.5. 検証結果
4.5.1. 検証A(単一テーブルに対するパラレルクエリの効果)
4.5.1.1. 検証A 並列処理数(起動するワーカーの数)の違いによる検証結果
4.5.1.2. 検証A 補足1:データがメモリにのりきらない場合の検証結果
4.5.1.3. 検証A 補足2:ストレージ性能の違いによる検証結果
4.5.2. 検証B(パーティションテーブルと単一(非パーティション)テーブルの比較)
4.5.2.1. パーティションプルーニングが効かないSQL
4.5.2.2. パーティションプルーニングが効くSQL
4.5.3. 検証C(異なるワーカー数が起動するテーブル同士結合時のワーカー数検証)
4.5.3.1. ネステッドループ結合
4.5.3.2. ハッシュ結合
4.6. 考察4.6.1. 検証A
4.6.2. 検証B
4.6.3. 検証C
4.6.4. 総括
5. Pgpool-II 検証
5.1. 検証概要
5.2. Pgpool-IIとは
5.2.1. Pgpool-II 概要
5.2.2. Pgpool-II 機能
5.2.2.1. ネイティブレプリケーションモード(Pgpool-II の独自のレプリケーション機能)
5.2.2.2. マスタースレーブモード(PostgreSQL のストリーミングレプリケーション機能を利用)
5.2.2.3. レプリケーション方式まとめ
5.3. 検証構成
5.3.1. 検証構成概要
5.3.2. ハードウェア構成
5.3.3. ソフトウェア構成
5.3.4. カーネル設定
5.4. 検証方法
5.4.1. 設定
5.4.1.1. 各レプリケーション方式における共通設定
5.4.1.2. ネイティブレプリケーション
5.4.1.3. ストリーミングレプリケーション(非同期)
5.4.1.4. ストリーミングレプリケーション(remote_apply同期)
5.4.2. 環境作成
5.4.3. 検証実施
5.5. 検証結果
5.5.1. 参照系
5.5.2. 更新系
5.6. 考察5.6.1. 参照系
5.6.2. 更新系
5.6.3. まとめ
6. JSON/JSONB
6.1. 検証概要
6.2. 検証構成
6.2.1. 検証サーバ
Page 3 of 78

25
25
25
25
25
25
26
27
27
27
27
28
28
28
29
31
31
31
32
33
33
34
37
37
37
37
37
38
38
38
38
38
38
40
42
42
42
42
43
43
43
43
43
44
44
44
44
45
45
45
46
47
47
47
48
49
49
49
49

PostgreSQL Enterprise Consortium

6.2.2. PostgreSQL
6.3. 検証方法
6.3.1. テーブル定義
6.3.2. インデックス定義
6.3.3. データ挿入性能
6.3.4. データ検索性能
6.4. 検証結果
6.4.1. 格納性能とテーブルサイズ
6.4.2. インデックス作成性能とインデックスサイズ
6.4.3. データロードとインデックス作成まとめ
6.4.4. 検索性能
6.4.5. 検索時間のまとめ
6.5. 考察

49
49
49
50
51
51
51
51
52
54
55
56
57
58
58
58
58
58
58
59
59
59
59
60
61
61
61
61
61
62
63
64
65
65
67
67
67
67
67
67
67
68
68
68
68
68
69
71
72
74
74
74
76
77
78

7. 全文検索7.1. 検証概要
7.2. 検証構成
7.2.1. マシン構成
7.2.2. 全文検索用モジュール
7.2.3. postgresql.confの設定値
7.3. 検証方法
7.3.1. 全文検索対象のデータ
7.3.2. インデックスの作成方法
7.3.3. 検索方法
7.3.4. インデックスによる検索ノイズの測定
7.4. 検証結果
7.4.1. インデックス作成時間、データ増分の比較
7.4.2. 英語キーワードによる比較
7.4.2.1. 検索時間の比較
7.4.2.2. 検索時間と件数の相関
7.4.2.3. Recheck処理による影響
7.4.3. 日本語キーワードによる比較
7.4.3.1. 検索時間と件数の相関
7.4.3.2. Recheck処理による影響
7.5. 考察8. VACUUM改善
8.1. 検証目的
8.1.1. VACUUM FREEZEについて
8.1.2. PostgreSQL 9.6における改善
8.1.3. 検証目的
8.2. 検証構成
8.2.1. ハードウェア構成
8.2.2. postgresql.confの設定値
8.3. 検証方法
8.3.1. 環境構築
8.3.1.1. PostgreSQLのインストール
8.3.1.2. DBの作成
8.3.1.3. 性能測定
8.4. 検証結果
8.5. 考察
9. おわりに9.1. 検証結果から見る PostgreSQL の今9.2. 今後の活動に向けて
10. 著者
11. ライセンス
12. Appendix 検証環境

Page 4 of 78

PostgreSQL Enterprise Consortium

Page 5 of 78

PostgreSQL Enterprise Consortium

1. はじめに1.1. PostgreSQLエンタープライズコンソーシアムとWG1について
Po stgreSQ L エンタープライズコンソーシアム(略称 PG ECo n s) は、Po stgreSQ L 本体および各種ツールの情報収集と提供、整備などの活動を通じて、ミッションクリティカ
ル性の高いエンタープライズ領域へのPo stgreSQ L の普及を推進することを目的として、2012 年4 月に設立された団体です。

1.1.1. 各 WGと WG1の 活動テー マ
PG ECo n s 技術部会ではPo stgreSQ L の普及を促進する技術的な課題の解決をテーマとし、「大規模基幹業務に向けた Po stgreSQ L の適用領域の明確化」を大きな目標に活動しております(2012 年7 月6 日開催のPG ECo n s セミナーより)。
この目標に向けて技術部会では課題を以下の課題領域に分類し、三つのワーキング・グループ(W G )で分担することとしました。

表 1.1 PG ECo n s における課題領域
課題領域

概要

担当 WG

性能

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

1

互換性

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

2

可用性

高可用クラスタ、B CP

3

保守性

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

3

運用性

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

3

セキュリ
ティ

監査

3

接続性

他ソフトウェアとの連携

3

W G 1 （新技術検証ワーキンググループ）
新しい技術の実検証から有用性や課題を検討
Po stgreSQ L の最新バージョンの性能傾向の調査・検討
W G 2 （移行ワーキンググループ）
ストアドプロシージャの移行技術に対する強化
利用者観点で整備した「移行フレームワーク」に基づき、成果物のユーザビリティ向上、 内容の最新化などを実施
W G 3 （課題検討ワーキンググループ）
データベース管理者やアプリケーション開発者が抱える、現場の課題に向けた課題に対するテーマを設定

1.2. WG1の活動テーマ
W G 1 では、Po stgreSQ L の新技術に対する技術検証、および新バージョンにおける性能検証を進めるにあたり、以下のような観点から個々の検証テーマをたてて、参加企業が集まってチームを作って具体的な検討を進めています。

表 1.2 W G 1 の検証テーマ
検証観点

具体的なテーマの例

新機能の技術検証

文字列データやJSO N などの特定データ型に対する処理性能や利便性、VACU U M に代表される保守コマンドの改善など性能向上機能定点観測

パラレルクエリ、パーティショニング、クエリキャッシュ、高速ロードなど
最新バージョンの Po stgreSQ L に対して、前バージョンとの性能傾向の差異を把握する

スケ ールアップ

マルチコアCPU でのスケールアップ性検証。定点観測で実施する

スケ ールアウト

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

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

性能チ ューニング

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

1.3. 本資料の概要と目的
本資料は、2016 年9 月にリリースされた Po stgreSQ L 9.6 のスケール性(参照系および更新系)、新技術・機能向上（パラレルクエリ、VACU U M 改善)、および近年のPo stgreSQ L に関連する技術(JSO N/JSO NB 、全文検索、Pgp o o l-II によるスケールアウト)について調査と性能検証を実施し、その方法と結果を報告します。

1.3.1. 2016年度の 活動テー マ
Page 6 of 78

PostgreSQL Enterprise Consortium

2016 年度は、2016 年9 月29 日にリリースされた Po stgreSQ L 9.6 を対象として以下のようなテーマで検証を実施しました。
Po stgreSQ L 9.6 のスケール性(参照系および更新系)
Po stgreSQ L 9.6 の新技術・機能向上
パラレルクエリ
VACU U M 改善

JSO N/JSO NB
全文検索

Pgp o o l-II のスケール性
以下、各検証テーマごとの概要を紹介します。

1.3.2. 定点観測（ スケー ル アッ プ）
今年度の定点観測の検証では、CPU のコア数が96 個の高性能サーバを使用して、Po stgreSQ L の最新バージョン 9.6 と その1 つ前のバージョン 9.5 との性能傾向を検証しました。
その結果、参照系のクエリにおいて、9.6 は 9.5 に比べて最高スループットで約20% 高いことが確認できました。
更新系のクエリにおいては、9.6 は 9.5 に比べて最高スループットが約30% 高いことが確認できました。また、最高スループットを達成する同時接続数についても、9.5 では
96 クライアントであったのに対し、9.6 では192 クライアントとなっており、並行処理の改善が図れていることを確認しました。

1.3.3. パラレル クエリ
Po stgreSQ L 9.6 では、1 つのクエリを複数のプロセスで実行するパラレルクエリ機能が実装されました。今年度は、以下のようなパラレルクエリの基本的な性能特性を検証しました。
パラレルクエリが効果的に動作できる、行数が多い表の検索に対して、 並列度を高めたときにどの程度の性能向上が図れるかを検証した。 並列度1 での検索性能を基準として、並列度が40 程度に対して約25 倍の性能向上が見られた。
同じく行数が多い表をパーティショニングで分割した際の性能を検証した。
プルーニングできない検索では、並列度が4 程度に増やすと約2.2 倍の性能向上が見られた。
プルーニングが有効な検索では、並列度が4 程度に増やすと約3.23 倍の性能向上が見られた。
行数の多い表と少ない表との結合を含む問合せで、 それぞれの表をスキャンするための並列度がどのように設定されるかを検討した。 その結果、行数が多い表に対する並列度(ワーカ数) でどちらの表もスキャンされていることが確認された。

1.3.4. JSON/JSONB
JSO N (JavaScrip t O b ject No tatio n )は、軽量のデータ交換フォーマットであり、多くのプログラミング言語でサポートされています [JSO N_O RG ] 。階層構造をもったデータを柔軟に記述できることから、関係データベースでは扱いにくい半構造データ [semi_stru ctu re] の処理に向いています。
Po stgreSQ L では、バージョン9.2 から JSO N データ型を扱えるようになりました。更に、バージョン9.4 からは JSO N データをバイナリ形式で格納することで処理の高速化を図った JSO NB が追加されました。
ここでは、近年注目されている Io T (In tern et o f Th in gs) 分野への応用で、センサ機器が半構造データを出力するユースケースを想定して、Po stgreSQ L のJSO N/JSO NB データ型の有効な利用法を検討しました。
その結果、以下のようなことが分かりました。

JSO N/JSO NB 型を使用すると、半構造データをそのまま格納できるという利点がある反面、 通常のテキスト型にデータを格納する場合に比べて、 必要な容量が大きくなり、検索時間も長くなるというトレードオフの関係が見られた。
データサイズについては、通常のテキストとして JSO N データを格納する場合に比べて、 JSO N 型を使うと 2.83 倍、JSO NB 型では 3.70 倍の容量が必要となる。
検索に要する時間は、通常のテキストとして JSO N データを格納する場合に比べて、 JSO N 型を使うと 9.3 ～28.6 倍、JSO NB 型では 2.70 ～ 3.71
倍の時間を必要とする。
検索時間については、定型的な検索(たとえば、データを取得した時間帯による絞り込み) を行う場合、該当するデータ項目だけをカラムとして格納することで通常のデータ型(たとえば timestamp )に格納する場合とそん色のない性能となる。

1.3.5. VACUUM改善
Po stgreSQ L 9.6 では、データベースの表にあるコミット済みデータを「凍結」する VACU U M FREEZE コマンドにて、事前にマークされた FREEZE 済みのページをスキップする機能が追加されました。VACU U M FREEZE に要する時間がどの程度短縮されるのか、検証しました。
その結果、Po stgreSQ L 9.5 では FREEZE するタプルの多少にかかわらず、表の大きさに比例する時間を要していた VACU U M FREEZE が、9.6 では FREEZE するタプ
ル数が少ない場合には、表の大きさとは無関係にほぼ一定の時間で完了することが確認されました。

1.3.6. 全文検索
Po stgreSQ L の適用領域の拡大、また取り扱うデータ量の増加に伴い、 Po stgreSQ L に格納されたデータに対する全文検索の重要性がますます高まっています。
Po stgreSQ L の標準機能においても、LIKE 文を用いることで文字列パターンを指定した検索は可能ですが、性能の観点からは全文検索専用のインデックスを使うことが望ましいと考えられます。

Page 7 of 78

PostgreSQL Enterprise Consortium
本章では、特に国内においてニーズの高い” 日本語検索” に対応した代表的な検索手法である p g_trgm （ピージートリグラム）、p g_b igm （ピージーバイグラム）、
PG ro o n ga （ピージールンガ）の特性を検証によって明らかにしました。
その結果、以下のようなことが分かりました。
今回取り上げた検索手法では、インデックスを使って検索結果の候補をまず探し、次いでその候補が検索結果として適切かを Rech eck 処理で確認する。
検索に要する時間は、インデックスによる候補の検索と、Rech eck 処理の合計となる。
検索キーワードによって、候補の検索に要する時間と Rech eck 処理の時間の割合は大きく異なる。
今回の検証では、検索キーワードが日本語 * 日本、東京都、データベース など) の場合、p g_b igm が多くのキーワードで最も高速であった。一方、検索キー
ワードが英語 (n p m 、An sib le 、Po stgreSQ L など）の場合、p g_b igm が最も遅く、p g_trgm, PG ro o n ga の方が多くの場合に高速であった。

1.3.7. Pgpool-II検証
PG ECo n s では2012 年度の検証テーマとして Pgp o o l-II を用いた参照負荷を分散するクラスタでの性能検証を実施しました。この時には、データのレプリケーションは
Pgp o o l-II によって行いました。今年度はそれを受けて、最新 Pgp o o l-II と Po stgreSQ L とを用いて Po stgreSQ L 側でレプリケーションを実施するケースを加えて、性能の比較検証を実施して、以下のような結果を得ました。
参照性能に関しては、負荷分散の方式によらずほぼ同じ性能(スループット)となる
どの方式の場合でも同じように、台数に比例して参照処理性能が向上する
更新性能に関しては台数を増やしても性能は向上せず、むしろ低下する。 その度合いはレプリケーション方式によって性能が異なる。
低下の度合いが最も小さいのは、Po stgreSQ L が提供する非同期レプリケーションを使うケース。 ただし、プライマリとスタンバイの間でレプリケーション遅延によるデータの不一致がある
次いで小さいのは、Po stgreSQ L が提供する同期レプリケーションを使うケース。 この場合、プライマリとスタンバイ間のデータの不一致は生じない
性能低下の度合いが最も大きいのは、Pgp o o -II によるネイティブレプリケーションを使うケース。 この構成ならでは利点としては、異なるバージョンのPo stgreSQ L サーバにデータをレプリケートできる、 システム全体の構成を柔軟にできることがある

1.4. 成果の公開
本資料も含めて、活動成果は報告書の形にまとめて、 PG ECo n s のW eb サイト で公開しています。また、過去の活動成果も含めてテーマ毎に報告書を検索できるように
成果物総索引 も用意しています。

1.4.1. 2015年度まで の 活動テー マの 紹介
2012 年度は、企業システムで使われる機器構成で、 Po stgreSQ L のスケールアップ、スケールアウトによる性能特性、性能限界を検証しました。 企業システムへのPo stgreSQ L 採用や、システム構成を検討するための、 一つの指針として「 2012 年度W G 1 活動報告書」として情報を公開しています。
2013 年度は、2012 年度に引き続き2013 年9 月9 日にリリースされた Po stgreSQ L 9.3 を対象とした スケールアップの定点観測を実施、Po stgreSQ L 9.3 新機能による性能影響も合わせて評価することとしました。 また、更新スケールアウト構成が可能なPo stgres-XC の測定パターンを変えた再測定により、 最適な利用指針を探る評価を実施することとしました。 さらに、2013 年度の新たな取り組みとしてデータベースの性能向上に着目、 データベースのI/O 負荷分散機能であるパーティショニングや、ハード
ウェアを活用した性能向上の検証を実施しました。

2014 年度は、2013 年度に引き続き2014 年12 月7 日にリリースされた Po stgreSQ L 9.4 を対象とした スケールアップの定点観測を実施、そして 9.4 新機能のW AL 改善を評価するために 更新系処理を新たに評価することとしました。 また、新たな取り組みとして物理環境以外の環境におけるデータベースの性能評価に着目、 KVM を使った仮想化環境と、Lin u x コンテナのDo cker 環境の検証を実施しました。
2015 年度は、2016 年1 月7 日にリリースされた Po stgreSQ L 9.5 を対象とした、スケールアップの定点観測を実施しました。 これは昨年度に引き続き、参照系・更新系の双方で性能を調査するものです。 Po stgreSQ L 9.5 での2 つの新機能、B RIN インデックスとParallel Vacu u m について、その利用ノウハウが得られるような検証を行い ました。最後に、基盤となるLin u x O S の主要なディストリビューションの一つである Red Hat En terp rise Lin u x 6 と7 とでPo stgreSQ L の性能を比較しました。

1.5. 実施体制
2016 年7 月14 日に開催された 2016 年度第1 回技術部会より、以下の体制で実施しています(企業名順)。
表 1.3 2016 年度W G 1 参加企業
SRA O SS, In c. 日本支社

NTTテクノクロス株式会社
日本電気株式会社
日本電信電話株式会社
日本ヒューレット・パッカード株式会社
富士通株式会社
この中で、日本電気株式会社は、「主査」として W G 1 の取りまとめ役を担当することになりました。

1.6. 実施スケジュール
Page 8 of 78

PostgreSQL Enterprise Consortium

2016 年度は、下記スケジュールで活動しました。
表 1.4 実施スケジュール
活動概要

スケ ジュール

W G 1 スタート

2016 年7 月14 日

実施計画策定2016 年7 月～10 月

検証実施2016 年11 月～2017 年1 月

2016 年度W G 1 活動報告書作成

2017 年2 月～2017 年3 月

総会と成果報告会

2017 年5 月18 日(東京)、2017 年6 月2 日(大阪/報告会のみ実施)

1.7. 謝辞
検証用の機器を日本ヒューレット・パッカード株式会社および富士通株式会社(敬称略)よりご提供いただきました。 この場を借りて厚く御礼を申し上げます。

1.8. 参考文献[JSO N_O RG ] JSO N の紹介. h ttp ://w w w .jso n .o rg/jso n -ja.h tml 2017.4.4 閲覧[semi_stru ctu re] Semi-stru ctered data. h ttp s://en .w ikip edia.o rg/w iki/Semi-stru ctu red_data 2017.4.4 閲覧

Page 9 of 78

PostgreSQL Enterprise Consortium

2. 定点観測 (スケールアップ検証・参照系 )2.1. 検証概要
本年度も例年行っているスケールアップ参照性能を観点とした定点観測検証を行いました。（昨年の2015 年度報告は こちら です。） 2016 年度は96 コアのCPU （インテル Xeo n E7-8890 v4 2.2G Hz ）、メモリ2TB といった例年通りのハイエンドスペックのサーバで、最新のPo stgreSQ L バージョン 9.6 と前バージョンの 9.5 とのスケールアップ参
照性能の比較を行いました。

2.2. pgbench とは
本検証では、 p gb en ch というベンチマークツールを使用しました。

p gb en ch はPo stgreSQ L に付属する簡易なベンチマークツールです(バージョン9.5 より前はco n trib に付属)。標準ベンチマーク TPC-B （銀行口座、銀行支店、銀行窓口担当者などの業務をモデル化）を参考にしたシナリオに基づくベンチマークの実行のほか、検索クエリのみを実行するシナリオも搭載されています。また、カスタムスクリプトを用意することで、独自のシナリオでベンチマークを実行することも可能です。

p gb en ch でベンチマークを実行すると、以下のように 1 秒あたりで実行されたトラザクションの数(TPS: Tran sactio n s Per Seco n d)が出力されます。なお、「 in clu din g
co n n ectio n s estab lish in g 」はPo stgreSQ L への接続に要した時間を含んだ TPS を、「 exclu din g co n n ectio n s estab lish in g 」はこれを含まないTPS を示します。

transaction type: TPC-B (sort of)scaling factor: 10
query mode: simple
number of clients: 10
number of threads: 1
number of transactions per client: 1000
number of transactions actually processed: 10000/10000
tps = 85.184871 (including connections establishing)tps = 85.296346 (excluding connections establishing)p gb en ch には「スケールファクタ」という概念があり、データベースの初期化モードでp gb en ch を起動することにより、任意のサイズのテスト用のテーブルを作成できます。デフォルトのスケールファクタは1 で、このとき「銀行口座」に対応する「 p gb en ch _acco u n ts 」というテーブルで10 万件のデータ、約15MB のデータベースが作成されます。
以下に、各スケールファクタに対応するデータベースサイズを示します。
表 2.1 スケールファクタに対するデータベースサイズ
スケ ールファク タ

データ ベースサイ ズ

1

15MB

10

150MB

100

1.5G B

1000

15G B

5000

75G B

初期化モードではp gb en ch _acco u n ts の他にもテーブルが作成されます。作成されるテーブルのリストを以下に示します。
表 2.2 p gb en ch _acco u n ts(口座)
列名

データ 型

コ メ ントaid

in tegerアカウント番号(主キー)b id

in teger

支店番号

ab alan cein teger

口座の金額

fillerch aracter(84)

備考

表 2.3 p gb en ch _b ran ch es(支店)
列名

データ 型

コ メ ントb idin teger

支店番号b b alan cein teger

口座の金額

fillerch aracter(84) 備考

Page 10 of 78

PostgreSQL Enterprise Consortium
表 2.4 p gb en ch _tellers(窓口担当者)
列名

データ 型

コ メ ントtid

in teger

担当者番号

b id

in teger

支店番号

tb alan cein teger

口座の金額

fillerch aracter(84) 備考

スケールファクタが 1 の時、p gb en ch _acco u n ts は 10 万件、p gb en ch _b ran ch es は 1 件、p gb en ch _tellers は 10 件のデータが作成されます。スケールファクタを増やすとこれに比例して各テーブルのデータが増えます。

p gb en ch には、様々なオプションがあります。詳細は Po stgreSQ L のマニュアル をご覧ください。ここでは、本レポートで 使用している主なオプションのみを説明します。
ベンチマークテーブル初期化-i ベンチマークテーブルの初期化を行います。
-s スケールファクタを数字(1 以上の整数)で指定します。

ベンチマークの実行-c 同時に接続するクライアントの数-j pgbench 内のワーカスレッド数-T ベンチマークを実行する時間を秒数で指定

前述のように、p gb en ch ではカスタムスクリプトを作成することで、独自の SQ L でベンチマークを実行することができま す。ここで、本検証で利用した機能を簡単に説明します。

set 文で変数に値を設定可能です。以下の例では変数 ro w _co u n t に 10000 を代入しています。

\set row_count 10000

また set 文では四則演算が利用可能です。以下の例ではスケールファクタの 100000 倍の値を「 n acco u n ts 」に設 定しています。ここで「 :scale 」は-s オプションで指定したスケールファクタの値で置き換えられます。

\set naccounts 100000 * :scale

変数には乱数を用いることも可能です。以下の例では変数 aid に 1 から aid_max の間の乱数を代入します。

\setrandom aid 1 :aid_max

設定した変数は、以下のようにスクリプト中の SQ L 文から参照できます。

SELECT count(abalance) FROM pgbench_accounts WHERE aid BETWEEN :aid and :aid + :row_count;

2.3. 検証構成
2.3.1. ハー ドウ ェア構成

Page 11 of 78

PostgreSQL Enterprise Consortium

図 2.1 検証ハードウェア構成

2.3.2. ソフトウ ェア構成
検証環境のソフトウェア構成を示します。
表 2.5 検証用サーバ

OS

Red Hat En terp rise Lin u x 7.2

Po stgreSQ L

9.5.5, 9.6.1
表 2.6 負荷かけ用サーバ

OS

Red Hat En terp rise Lin u x 7.2

p gb en ch

9.6.1

2.3.3. カー ネ ル 設定
O S デフォルト
ハイパースレッディングは利用しない

2.3.4. PostgreSQL 設定
Po stgreSQ L 設定ファイル p o stgresql.co n f での設定は以下の通りです。

listen_addresses = '*' ... 負荷マシンからの接続用
max_connections = 510 ... 多めに設定
shared_buffers = 200GB ... メモリ 2TB の 1/10
work_mem = 1GBcheckpoint_timeout = 30min
max_wal_size = 1GBlogging_collector = onlogline_prefix = '%t [%p-%l] 'ただし、パラメータ w al_level は 9.6 から以前の arch ive, h o t_stan db y 指定が統合されて rep lica で指定するようになったため、9.5 では

wal_level = archive

9.6 では

wal_level = replicaを指定しています。

2.4. 検証方法
2.4.1. 環境
Page 12 of 78

PostgreSQL Enterprise Consortium
以下の手順で、データベースクラスタを作成しました。

in itdb でデータディレクトリを作成し、上記に示した設定をp o stgresql.co n f に記述します。

$ initdb --no-locale --encoding=utf-8$ vi $PGDATA/postgresql.conf

Po stgreSQ L を起動してベンチマーク用のデータベースを作成します。

$ pg_ctl -w start$ createdb [dbname]p gb en ch コマンドを用いて、ベンチマーク用データベースをスケールファクタ 1000 で初期化します。

$ pgbench -i -s 1000 [dbname]2.4.2. 測定
本検証では p g_p rew arm モジュールを用います。

p g_p rew arm はバッファキャッシュにテーブルデータを読み込むためのモジュールで、バッファキャッシュがクリア されているデータベース起動直後の性能低下状態を解消するために用いることができます。
まず、測定スクリプト実行前に p g_p rew arm を実行します。これによりテーブルデータはすべてバッファキャッシュに格納されます。

=# SELECT pg_prewarm('pgbench_accounts');

以下のスクリプトをcu sto m.sql として作成して、適度な負荷がかかるようにしました。これは、p gb en ch の標準 シナリオ（ p gb en ch -S ）ではCPU に充分な負荷がかからないためです。具体的には、ランダムに 10000 行を取得 しています。

\set naccounts 100000 * :scale\set row_count 10000\set aid_max :naccounts - :row_count\setrandom aid 1 :aid_max
SELECT count(abalance) FROM pgbench_accounts WHERE aid BETWEEN :aid and :aid + :row_count;

これを、クライアント用検証機から$ pgbench -n -h [host] -p [port] -c [clients] -j [threads] -f custom.sql -T 300 -s 1000 [dbname]

として実行しました。SELECTのみであるためVACU U M を実行せず、p gb en ch クライアント数とスレッド数を変動させながら、300 秒ずつ実行しています。スレッド数はクライ
アント数の半分としています。スケールファクタにはデータベース初期化時と同じ1000 を指定します。
計測はクライアント数ごとにそれぞれ3 回ずつ実行し、その中央値を結果とします。また、変動させるクライアント 数は{1, 2, 4, 8, 16, 32, 48, 64, 80, 96, 128, 160, 192}です。

2.5. 検証結果
検証結果のTPS およびCPU 使用率のグラフを以下に示します。 9.5, 9.6 はともにクライアント数増加につれて TPS が増加し、 コア数(96)近くのクライアント数128 で96 コアのCPU を使い切った状態でTPS は頭打ちとなっていますが、9.6 のTPS は各クライアント数において常に 9.5 を上回る結果となりました（レイテンシにおいてもより小さい値となっています）。

Page 13 of 78

PostgreSQL Enterprise Consortium

図 2.2 各クライアント数に対する TPS

Page 14 of 78

PostgreSQL Enterprise Consortium

図 2.3 CPU 使用率

Page 15 of 78

PostgreSQL Enterprise Consortium

図 2.4 各クライアント数に対するレイテンシ

2.6. 考察
本検証では例年通り、Po stgreSQ L 最新バージョンと前バージョンのスケールアップ参照性能比較検証を行いました。 昨年度のバージョン 9.5 においてもメニーコアCPU におけるスケールアップの性能向上は確認されておりましたが、今年度のバージョン 9.6 は更にそれが顕著でした。全てのクライアント数において 9.5 を上回り、かつ最大で1.5倍近くもの性能向上を示していました。
今回詳しい調査に至りませんでしたが、リリースノートではスケーラビリティの大きな改善に「共有ハッシュテーブルのフリーリスト分割による競合回避の修正」が寄与していることが触れられており、本検証結果と関係している可能性があります。 本検証では9.6 における性能向上は確かに確認されており、Po stgreSQ L をメニーコアCPU サーバで用いるメリットがここに至りさらに増してきたと言えるでしょう。
参考：

Po stgreSQ L 9.6 リリースノート (日本語) h ttp ://w w w .srao ss.co .jp /tech n o lo gy/p o stgresql/9.6/
Po stgreSQ L 9.6 リリースノート (英語) h ttp s://w w w .p o stgresql.o rg/do cs/9.6/static/release-9-6.h tml「共有ハッシュテーブルのフリーリストの分割」 メーリングリストでのディスカッション h ttp s://w w w .p o stgresql.o rg/messageid/flat/20151211170001.78ded9d7@ fu jitsu #20151211170001.78ded9d7@ fu jitsu「共有ハッシュテーブルのフリーリストの分割」 コミットログ (英語)h ttp s://gith u b .co m/p o stgres/p o stgres/co mmit/44ca4022f3f9297b ab 5cb ffdd97973db b a1879ed

Page 16 of 78

PostgreSQL Enterprise Consortium

3. 定点観測 (スケールアップ検証・更新系 )3.1. 検証目的
PG ECo n s では、Po stgreSQ L の新バージョン・新リリースにあわせて、新旧バージョンの性能比較やスケールアップ特性の検証を主な目的にした定点観測を2012 年度から実施してきました。2014 年度からは、それまでの参照処理に加えて更新処理についても検証を実施し、検証結果の公開を行いました。
今年度はその定点観測として継続して実施している 1)Po stgreSQ L の更新処理におけるCPU スケーラビリティの達成状況確認、2)新旧バージョン(今年度はPo stgreSQ L 9.6.1 と9.5.5)の比較による更新性能の改善状況確認を行いました。

3.2. 検証構成
本検証のハードウェアおよびソフトウェアの主なスペックと構成を 表. 3.1 に示します。

表 3.1 検証構成
機器

DB サーバ

負荷掛けクライアント

項目

仕様

CPU

インテル Xeo n プロセッサE7-8890v4@ 2.20G Hz(24 コア)x4 合計 96 コア

搭載メモリ

2048G B

内蔵ストレージ

HDD 1.2TB SAS 10K x 10

DB 格納用ストレージ

Fib er Ch an n el 接続(16G b p s) SAN
以下の2 領域を利用
領域1: Po stgreSQ L のDB 領域
領域2: W AL 領域
それぞれの領域はHDD 1.8TB 6G SAS 10K x 4(RAID10 、実効容量約3TB )で構成

OSRed Hat En terp rise Lin u x 7.2

DB MS

Po stgreSQ L 9.6.1
Po stgreSQ L 9.5.5

CPU

インテル Xeo n プロセッサE5-2620v4@ 2.30G Hz(8 コア)x2 合計 16 コア

搭載メモリ

128G B

内蔵ストレージ

HDD 1.2TB SAS 10K x 8

DB 格納用ストレージなし(内蔵ストレージのみ)OS

Red Hat En terp rise Lin u x 7.2

クライアントPo stgreSQ L 9.6.1 のソースコードに含まれるp gb en ch をビルドして使用

3.3. 検証方法
3.3.1. 環境構築
3.3.1.1. データ ベース初期設定
スケールファクタは7000 、FILLFACTO R は80 として初期設定(テーブル作成)を行いました。これにより対象テーブルのサイズは約100G B となります。FILLFACTO R を80 としたのは、U PDATE 文実行時に HO T機能を働かせるためです。

$ pgbench -i -s 7000 -F 80
測定時間を短縮するために、テーブルのデータ ($PG DATA ディレクトリ以下のファイル群)は、測定を行うたびに p gb en ch -i で作成するのではなく、上記の手順で作成したテーブルのデータを保存しておき、それを毎回$PG DATA に戻す方法で用意することにしました。

3.3.1.2. postgresql.confの設定値
p o stgresql.co n f により設定するパラメータのうち、いくつかをデフォルトから変更して測定を実施しました。 主な目的はCHECKPO INTによる影響を排除しできるだけ測定
状況を均一化する、VACU U M の影響を排除する、本番システムを想定した w al_level とすることです。sh ared_b u ffers は検証ハードウェア(DB サーバ)が搭載するメモリ量に合わせて設定しました。また、max_w al_size を大きな値にすることで、測定期間中に CHECKPO INT処理が実行されないようにしました。

Page 17 of 78

PostgreSQL Enterprise Consortium
リスト 3.1 p o stgresql.co n f のデフォルトからの変更内容

max_connections = 1000
shared_buffers = 384GB# サーバ搭載容量の約20%
wal_level = replica # PostgreSQL 9.6
wal_level = archive # PostgreSQL 9.5
max_wal_size = 160GB
checkpoint_timeout = 60min
maintenance_work_mem = 20GB
log_checkpoints = on
logging_collector = on
log_line_prefix = '%t %p %a'log_lock_waits = on
autovacuum = offlisten_addresses = '*'3.3.2. 測定
3.3.2.1. pgbench スク リプト ( 測定対象ト ラ ンザク ショ ン )Po stgreSQ L で実行させるトランザクションは、例年度通りに、サイズの大きい表(p gb en ch _acco u n ts)からランダムに選んだ行に対する比較的単純な更新処理(U PDATE)としました。
リスト 3.2 p gb en ch のカスタムスクリプト\set naccounts 1000000 * :scale\set aid_val random(1, :naccounts)
UPDATE pgbench_accounts
SET filler=repeat(md5(current_timestamp::text), 2)
WHERE aid=:aid_val;
3.3.2.2. pgbench の実行方法
システムの定常状態に近い動作で検証を行うため、p g_p rew arm を利用して、テーブルの全データをsh ared_b u ffer にロードした状態で測定を開始するようにしました。
全データをsh ared_b u ffer にロードした後、Po stgreSQ L を動作させたままで3 回p gb en ch を5 分間実行し、中央値を測定結果として用いることにしました。測定実施
中(p gb en ch 実行中)に CHECKPO INTが起動しないことを確実にするために、各p gb en ch 実行の間でch eckp o in t コマンドを実行させました。これにより、次のCHECKPO INTが起動するまでのW AL 量(のカウンタ )がリセットさせます。

p gb en ch を実行させるコマンドを以下に示します。

pgbench -c [clients] -j [threads] -f [script] -s 7000 [dbname]pgbench

実行コマンド[clients] クライアント数[threads] スレッド数(クライアント数の1/2)[script] スクリプトファイル名[dbname] pgbench表を作成した DB名
昨年度までに行ってきた参照系や更新系の検証を踏襲し、p gb en ch のスレッド数はクライアント数の半分としています。

3.3.2.3. 測定結果の取得
スループット値はクライアント用検証機で実行させるp gb en ch プログラムが実行終了時に出力します。ネットワーク接続操作を含むスループット値と含まない値の2 種類が出力されますが、本報告書では、ネットワーク接続操作を含まない値(exclu din g co n n ectio n s estab lish in g)を用いています。ここで行った性能測定では、各実行条
件(測定パラメータ )について 3 回行った p gb en ch 実行から中央値を選び、それを最終的な測定結果としました。CPU 使用率は、p gb en ch を実行させている5 分の間、
sar コマンドをサーバ用検証機で動作させて計測しました。

3.3.3. 測定パラメー タ
性能測定では、p gb en ch のクライアント数(スレッド数)を変動させて性能(スループットやCPU 使用率)がどのように変化するのかを調べることを基本としました。これ以降、クライアント数の変化に伴うスループットおよびCPU 使用率の変化を「基本性能特性」と呼びます。この他に変動させた測定パラメータは、CPU コア数、Po stgreSQ L のバージョン(9.5.5 と9.6.1)です。 CPU コア数については、1CPU チップ(ソケット)が24 コアであることを考慮し、24, 48, 96 の3 種類について測定を行いました。今年度使用した O SのRed Hat En terp rise Lin u x 7.2 では、reb o o t することなく動的に CPU コアの使用状態(o n lin e, o fflin e)を切り換える機能が提供されています。そこで、CPU コア数の変更は、この機能を使用する下記スクリプトにより行いました。

Page 18 of 78

PostgreSQL Enterprise Consortium
リスト 3.3 コア数変更スクリプト#!/bin/bash
cd /sys/devices/system/cpu
CHIP0=' 0 1 2 3 4 5 6 7 8 9 10 11 48 49 50 51 52 53 54 55 56 57 58 59 'CHIP1=' 12 13 14 15 16 17 18 19 20 21 22 23 60 61 62 63 64 65 66 67 68 69 70 71 'CHIP2=' 24 25 26 27 28 29 30 31 32 33 34 35 72 73 74 75 76 77 78 79 80 81 82 83 'CHIP3=' 36 37 38 39 40 41 42 43 44 45 46 47 84 85 86 87 88 89 90 91 92 93 94 95 'case ${1:-96} in96) cpuON="${CHIP0} ${CHIP1} ${CHIP2} ${CHIP3}"
cpuOFF="";;
72) cpuON="${CHIP0} ${CHIP1} ${CHIP2}"
cpuOFF="${CHIP3}";;48) cpuON="${CHIP0} ${CHIP1}"
cpuOFF="${CHIP2} ${CHIP3}";;24) cpuON="${CHIP0}"
cpuOFF="${CHIP1} ${CHIP2} ${CHIP3}";;*) cpuON="${CHIP0} ${CHIP1} ${CHIP2} ${CHIP3}"
cpuOFF="";;
esac
for n in ${cpuON}
doecho 1 > cpu${n}/online
done
for n in ${cpuOFF}
doecho 0 > cpu${n}/online
done

3.4. 検証結果
3.4.1. CPUスケー ラビリ ティ
基本性能特性を 図. 3.1 と 図. 3.2 に示します。9.5.5 では最大のスループットとなったのは48 コアのケースで、96 コアのケースではスループットが少々下がるがほぼ同じ傾向となりました。どちらもピークとなったクライアント数は96 でした。一方、9.6.1 では傾向が大きく異なり、今回の検証で最大のクライアント数である192 が最大のスループットとなっており、48 コアも96 コアもクライアント数を更に増やすことでスループットの向上が望めるような結果となりました。24 コアと96 コアを比較すると、最大で約60% のスループット向上が確認できました。 コア数が24 の場合は9.5.5 、9.6.1 ともに、64 接続数以降、横ばいとなる結果となりました。

図 3.1 Po stgreSQ L 9.5.5 のスループット

Page 19 of 78

PostgreSQL Enterprise Consortium

図 3.2 Po stgreSQ L 9.6.1 のスループット

3.4.2. バー ジョ ン 比較
図. 3.3 に 24 コア、 図. 3.4 に 48 コア、 図. 3.5 に 96 コアの結果を示します。24 コアの場合は9.6.1 がわずかにスループットが下がりますが、ほぼ同じ性能を示しました。 48 コ
ア、96 コアの場合は、クライアント数が少ない場合は9.5.5 が若干スループットが高く、クライアント数が96 を過ぎたあたりから 9.6.1 が9.5.5 に比べて高いスループットを示す結果が得られました。今回の検証では、9.6.1 は9.5.5 よりも最大で約30% のスループット向上が確認できました。

図 3.3 24 コアでのスループット

Page 20 of 78

PostgreSQL Enterprise Consortium

図 3.4 48 コアでのスループット

図 3.5 96 コアでのスループット

3.5. 考察
本検証ではクライアント数が多い場合に、バージョン9.6 が9.5 と比較して更新性能が向上したことが確認されました。 特にバージョン9.6 ではCPU コア数の倍の192 までクライアント数を増やしても、性能が劣化は発生しませんでした。

CPU コア数96 、クライアント数192 でのCPU 使用率について 図. 3.6 に示します。 9.6.1 は9.5.5 と比べて CPU 使用率が高く、CPU をより効率よく利用できていることがわかります。このことが性能差に影響していると考えられます。

Page 21 of 78

PostgreSQL Enterprise Consortium

図 3.6 96 コアでのスループット
この原因として、Po stgreSQ L 9.6 でPro cArrayLo ck 、Clo gCo n tro lLo ck の競合の改善が行われたことが影響していると考えられます。 Pro cArrayLo ck は複数のプロセスが同時にコミットするときに利用されるロックで、9.5 までは複数のプロセスが同時にコミットする場合、それぞれのプロセスでロック競合の解決を行っていました。 9.6 からは、最初にロックを獲得したプロセスがほかのプロセス分の処理も行うことで、性能改善を図っています。 Clo gCo n tro lLo ck は、トランザクションの状態を読み書きする際に利用されるロックで、9.6 でバッファサイズを拡張することにより、メニーコアに対して性能の改善を図っています。
なお、今回の検証は非常に高性能なストレージを用いて、I/O ボトルネックになりにくい環境であったため、有効なスケーラビリティが確認されましたが、 ストレージの性能によっては異なる傾向になる可能性が高いことにご留意いただきたいと思います。

Page 22 of 78

PostgreSQL Enterprise Consortium

4. パラレルクエリ
4.1. 検証概要
近年、ハードウェアの性能向上はめざましく、一つのプロセッサに搭載されるコアの数とメモリの容量は年々増大しています。
メニーコアについては、代表的な2 ソケット対応のB ro adw ell マイクロアーキテクチャ インテル Xeo n E5-2699 v4 では、1 プロセッサあたり22 コア、2 プロセッサ構成では44 コアとなります。 4 ソケット対応のB ro adw ell マイクロアーキテクチャのインテル Xeo n E7-8890 v4 に至っては1 プロセッサあたり24 コア、4 プロセッサ構成では96 コアにもなります。
またメモリの大容量化も進みハイエンドサーバではTB (テラバイト)単位でのメモリ搭載がされています。

Po stgreSQ L 9.5 までは、メニーコア環境であっても1 つのクエリでは1 つのコアしか使用されませんでした。 商用ソフトウェアでは以前から実装されていて、Po stgreSQ L でも長年実装が待ち望まれてきたメニーコアや大容量メモリを有効活用するパラレルクエリが、ついにバージョン9.6 で実装されました。
そこで、パラレルクエリにより複数のコアをどのように利用して性能向上を果たすのかを検証しました。

4.2. パラレルクエリとは
4.2.1. パラレル クエリ
パラレルクエリとは、一つのクエリを複数のプロセスで分担して並列処理することで、単一プロセスでの処理よりも高速にクエリを実行する、メニーコアの利点を有効活用する処理方式です。
例えばSELECT文で1000 万レコードを全件検索する場合、検索で使用するプロセスが1 個だけだと1 プロセスが1000 万レコードをすべて検索する必要があります。 それに対して検索で使用する10 プロセスあって複数のプロセスで分担することができれば、1 プロセス当たりの検索対象は100 万レコードと10 分の1 に減ります。
複数のプロセスで検索処理を分担して実行することで、1 プロセスあたりの検索自体にかかる実行時間は短くなりますが、 ある処理を複数に分割する配分の制御や受け
渡し、そして複数で処理した結果を集めて一つにまとめる処理などの実行時間が長くなります。 複数のプロセスで短縮できる時間があまり少ないと、パラレルクエリに変更す
ることでむしろ余計に実行時間がかかってしまうこともあります。
そのため、プランナは多くの実行プランの中から、パラレルクエリのほうが効率的に処理できると判断した場合のみパラレルクエリの実行プランを選択します。

4.2.2. PostgreSQL9.6で の パラレル クエリ
Po stgreSQ L 9.6 で実装されているパラレルクエリに関する処理は、パラレルスキャン、パラレルジョイン、パラレル集約の三種類です。
プランナが処理を分担したほうが効率的だと判断した場合、パラレルクエリのプランを採用します。

exp lain (an alyze , verb o se)で確認したパラレルクエリ プラン例QUERY PLAN-------------------------------------------------------------------------------------------------------------------------------------Gather (cost=1000.00..112816.10 rows=38400 width=52) (actual time=0.198..224.017 rows=99740 loops=
1)
Output: log_id, date, "time", product_id, place_id, machine_id, app_id, access_time_second, access_count, err_code
Workers Planned: 4Workers Launched: 4-> Parallel Seq Scan on public.access_log (cost=0.00..107976.10 rows=9600 width=52) (actual tim
e=0.017..209.797 rows=19948 loops=5)
Output: log_id, date, "time", product_id, place_id, machine_id, app_id, access_time_second,
access_count, err_code
Filter: ((access_log.log_id % '77'::bigint) = 0)
Rows Removed by Filter: 1516052
Worker 0: actual time=0.016..214.828 rows=20088 loops=1
Worker 1: actual time=0.016..214.518 rows=19967 loops=1
Worker 2: actual time=0.020..218.061 rows=20817 loops=1
Worker 3: actual time=0.015..213.654 rows=20054 loops=1
パラレルクエリでは、親プロセスに加えワーカーがバックグラウンドワーカープロセスとして起動されて処理を実行するため、検索プロセス数は親プロセスとワーカーの合計となります。そして、各プロセスで処理した結果をG ath er ノードで集約します。
また、パラレルクエリで起動されるワーカー数は、テーブルサイズによりデフォルトで起動する数が決まっています。

Page 23 of 78

PostgreSQL Enterprise Consortium
表 4.1 テーブルサイズによるワーカー数
ブロ ック 数

サイ ズ（ M B ）起動ワーカ ー数

検索プロ セス数

1,024

8

1

2

3,072

24

2

3

9,216

72

3

4

27,648216

4

582,944648

5

6248,832

1,944

6

7

746,496

5,832

7

8

2,239,488

17,4968

96,718,464

52,4889

1020,155,392

157,464

10

11

・・・

・・・

・・・

・・・

※ プロック数はブロックサイズがデフォルト(8KB )の場合です。

4.2.3. パラレル クエリ に関連するパラメー タ
パラレルクエリ時に関連する主なパラメータには以下のパラメータがあります。なお、max_p arallel_w o rkers_p er_gath er パラメータのデフォルト値が0 のため、デフォルト設
定ではパラレルクエリは実行されません。

表 4.2 パラレルクエリに関連する主なパラメータパラ メ ータ

デフォルト 値

説明

max_w o rker_p ro cesses

8

システムがサポートするバックグラウンドワーカープロセスの最大数を指定します。

max_p arallel_w o rkers_p er_gath er

0

一つのG ath er ノードに対して起動できるワーカー数の最大値を指定します。

min _p arallel_relatio n _size

8MB

パラレル処理を行うテーブルの最小サイズを指定します。

p arallel_setu p _co st

1000

ワーカーを起動するためのコストに対するプランナの推測値を指定します。

p arallel_tu p le_co st

0.1

あるワーカーから、1 行を他のプロセスに転送するためのコストに対するプランナの推測値を指定します。

※ max_p arallel_w o rkers_p er_gath er で指定した値がmax_w o rker_p ro cesses で指定した値を超える場合、起動されるワーカー数はmax_w o rker_p ro cessesの値に制限されます。 また、複数のパラレルクエリが同時に行われる場合、起動されるワーカー数の合計がmax_w o rker_p ro cesses で指定した値に制限されます。 このため、プラン作成時のワーカー数よりも実際に起動されるワーカー数が少ない場合があります。

4.3. 検証構成
4.3.1. 検証ハー ドウ ェア構成
検証環境のハードウェア構成の概略を示します。
本パラレルクエリ検証ではDB サーバ上でSQ L を直接実行する形式としました。
またコア数やメモリサイズの違いによるパラレルクエリの効果の違いを比較するために、 検証ではコア数とメモリサイズの構成が異なる下記のDB サーバを使用しました。

Page 24 of 78

PostgreSQL Enterprise Consortium
表 4.3 検証用DB サーバ構成
機器

項目

2TB メモリサーバ

仕様

CPU

インテル Xeo n E7-8890v4@ 2.20G Hz
24 コアx4 合計 96 コア
ハイパースレッディング:o ff

搭載メモリ

2048G B

内蔵ストレージ

HDD 1.2TB SAS 10K x 10

DB 格納用ストレージ Fib er Ch an n el 接続(16G b p s) SAN
領域はHDD 1.8TB 6G SAS 10K x 4
RAID10 、実効容量約3TB で構成
256G B メモリサーバ

CPU

インテル Xeo n E5-2690v4@ 2.60G Hz
14 コアx2 合計 28 コア
ハイパースレッディング:o ff

搭載メモリ

256G B

内蔵ストレージ

HDD 1.2TB SAS 10K x 16

DB 格納用ストレージ Fib er Ch an n el 接続(16G b p s) SAN
領域はHDD 1.8TB 6G SAS 10K x 4
RAID10 、実効容量約3TB で構成

4.3.2. 検証ソフトウ ェア構成
検証環境のソフトウェア構成を示します。
表 4.4 ソフトウェア構成
種類

OS

ソフト ウェ ア名およびバージョ ン

Red Hat En terp rise Lin u x 7.2

Datab ase Po stgreSQ L 9.6.1

4.4. 検証方法
4.4.1. 検証項目
パラレルクエリ検証では以下の三点を検証します。

4.4.1.1. 検証 A
検証A では、パラレルクエリの並列度による処理性能の改善状況の確認をします。
パラレルクエリ適用が有効と考えられるある程度の大きさを持ったテーブルに対し、 max_p arallel_w o rkers_p er_gath er の値を変更し、並列度の違いによる処理時間を比較します。
テーブルサイズから計算されるデフォルトの並列度まで性能向上するのか、あるいはそれを超える設定にした場合に効果があるのか、 大きすぎるとオーバーヘッドにより性能低下となるのかという点を明らかにします。

4.4.1.2. 検証 B
検証B では、パーティションテーブルでのパーティション絞り込み（パーティションプルーニング）とパラレルクエリとの比較を行います。
パーティションテーブルの場合、並列度は個々のパーティションテーブルのサイズにより計算されるため、単一のテーブルよりも並列度が小さくなります。 巨大なサイズの単一テーブルで並列度を大きくした場合と、パーティション化して検索対象パーティションが絞り込まれる場合とでの処理時間を比較します。
パーティション化されたテーブルとパラレルクエリとではどちらが速いのか、パーティションプルーニングが有効なSQ L と無効なSQ L について測定します。

4.4.1.3. 検証 C
検証C では、複数テーブルを結合する場合のパラレルクエリの動作を確認します。
起動されるワーカー数が異なるテーブルを結合させた場合、実際に起動されるワーカー数を確認します。
サイズの大きいテーブルでは起動されるワーカー数が多く、サイズが小さいテーブルでは起動されるワーカー数は少なくなります。このサイズが異なる二つのテーブル、すなわちデフォルトの並列度が異なるテーブル同士を結合させた場合、どのような並列度で処理されるのかを確認します。

4.4.2. デ ー タモデ ルPage 25 of 78

PostgreSQL Enterprise Consortium
本検証で使用するデータモデルは、2013 年度のパーティション性能検証および、2015 年度のB RIN とパーティション比較検証で使用したモデルを使用します。 具体的には
以下の2 テーブルを使用します。

access_lo g テーブル： 1 日当たり768 万行のデータを保持するテーブル。通常テーブルとパーティションテーブルで性能を比較します。
p ro du ct_master テーブル： 8MB (パラレルクエリが行われる程度の大きさ）のマスタテーブル。
テーブル定義は以下のとおりです。

access_lo g テーブル

create table access_log (log_idbigserial,datechar(8),timechar(6),
product_id
int,place_idint,
machine_id
int,
app_idint,
access_time_second int,
access_countint,
err_codeint);

p ro du ct_master テーブル

create table product_master (product_id
int primary key,product_nametext);

access_lo g テーブルは、単一テーブルとパーティションテーブルの比較を行うため、単一テーブルのaccess_lo g テーブルを保持するデータベースと、パーティションテーブルのaccless_lo g テーブルを保持するデータベースを用意し、それぞれのデータベースに access_lo g テーブル、p ro du ct_master テーブルを配置します。
表 4.5 各データベースとaccess_lo g テーブル
データ サイ ズ

No

データ ベース

説明

(M B)

最大並列
度

1

b ase366day

1 日あたり768 万行× 366 日（ 28 億1088 万レコード）を単一テーブルとして保持する
access_lo g テーブルのあるDB

226,391112

p art366day

1 日あたり768 万行を1 パーティションに保持し、366 日分のパーティション（合計28 億1088 万レ
コード）で構成されるaccess_lo g パーティションテーブルのあるDB

618 （※）

5 （※）※ データサイズは1 パーティションのサイズ。最大並列度はパーティションのサイズで決まります。

4.4.3. DB設定
性能測定にあたり、デフォルトから変更したパラメータは以下のとおりです。

Page 26 of 78

PostgreSQL Enterprise Consortium
表 4.6 デフォルトから変更したパラメータパラ メ ータ

256GB メ モリサーバ

2TB メ モリサーバ

listen _addresses**

sh ared_b u ffers

100G B

100G Bw o rk_mem

500MB

500MB o r 3G B (※)

w al_level

rep lica

rep lica

max_w o rker_p ro cesses

20

100

max_p arallel_w o rkers_p er_gath er(※)

16

16

ch eckp o in t_timeo u t

1d1d

max_w al_size

4G B

4G B

lo ggin g_co llecto rononlo g_ro tatio n _size

00

lo g_ch eckp o in ts

ononlo g_lin e_p refix'%m %h %d %u ''%m %h %d %u '※ 測定により値を変更して実施します。

4.4.4. 測定手順
4.4.4.1. 検証 A 測定方法
1 年分のデータを単一テーブルに保持するデータベース(b ase366day)のaccess_lo g テーブルから一日分(768 万行)のデータを集計するSQ L を、p sql を使用して exp lain
(an alyze , verb o se)をつけて実行します。

explain (analyze, verbose) select date, count(*), max(time), avg(access_count), min(log_id) from a
ccess_log where log_id % 366 = 0 group by date;
デフォルトの設定だと230G B 程度の大きさのテーブル(access_lo g テーブル)では、計算上の最大並列度は11 です。
そこで起動ワーカー数がデフォルト計算上の最大並列度以上となるように、 p arallel_setu p _co st とp arallel_tu p le_co st とmin _p arallel_relatio n _size を以下のとおり設定し、並列度と処理時間の関係を測定します。なお、各パラメータの説明については 表. %s を参照してください。

set parallel_setup_cost=0;
set parallel_tuple_cost=0;
set min_parallel_relation_size=0;
set max_parallel_workers_per_gather= N;/* N： 1～69 */4.4.4.2. 検証 B 測定方法
1 年分のデータを単一テーブルに保持するデータベース(b ase366day)とパーティションテーブルに保持するデータベース(p art366day)のaccess_lo g テーブルから一日分(768 万行)のデータを集計するSQ L を、p sql を使用して exp lain (an alyze , verb o se)をつけて実行します。
パーティションプルーニングが効かないSQ L とパーティションプルーニングが効く SQ L の2 つのSQ L の測定を行います。
パーティションプルーニングが効かないSQ L

explain (analyze, verbose) select date, count(*), max(time), avg(access_count), min(log_id) from a
ccess_log where log_id % 366 = 0 group by date;
パーティションプルーニングが効く SQ L

explain (analyze, verbose) select date, count(*), max(time), avg(access_count), min(log_id) from a
ccess_log where date = '20160101' group by date;
4.4.4.3. 検証 C 測定方法

Page 27 of 78

PostgreSQL Enterprise Consortium

1 年分のデータを単一テーブルに保持するデータベース(b ase366day)のaccess_lo g テーブルと、p ro du ct_master テーブルとを結合するSQ L を、p sql を使用して exp lain
(an alyze , verb o se)をつけて実行します。

explain (analyze,verbose) select a.product_id, p.product_name from access_log a, product_master p w
here a.product_id = p.product_id and a.log_id % 77 = 0 and date = '20160101';
また結合方法の違いによる動作を確認するため、明示的にネステッドループ結合あるいはハッシュ結合が選択されるように、以下のとおり設定を行って測定します。
ネステッドループ結合

set enable_nestloop=true;
set enable_mergejoin=false;
set enable_hashjoin=false;

ハッシュ結合set enable_nestloop=false;
set enable_mergejoin=false;
set enable_hashjoin=true;

4.5. 検証結果
4.5.1. 検証 A(単一テー ブル に対するパラレル クエリ の 効果 )4.5.1.1. 検証 A 並列処理数 ( 起動するワーカ ーの数 ) の違いに よる検証結果
メモリサイズが2TB のサーバを使い、並列度を70 まで増やした時に性能が単体処理と比較してどの程度向上するかを検証しました。
表 4.7 検証条件

DB サーバ2TB メモリサーバ

スト レージ

FC ストレージ

SQL 文

保持データ 量768 万行（一日分）を集計するSQ L 1 年分（ 768 万× 366 ）並列度を変化させた場合の処理時間のグラフと表を以下に示します。

図 4.1 データがメモリに載りきる場合の処理時間の変化

Page 28 of 78

PostgreSQL Enterprise Consortium
表 4.8 並列度と処理時間
並列度

処理時間 ( ミ リ秒 )

性能向上比

1

309,3151.00

2166,692

1.86

3

120,424

2.57

495,8683.23

585,1873.63

673,6694.20

762,1764.97

861,9095.00

954,9295.63

1049,2516.28

1144,9226.89

15

31,9699.68

20

23,57013.12

30

15,70319.70

40

12,17925.40

50

25,62212.07

60

22,41213.80

70

22,32713.85

パラメータのデフォルト値での並列度11 では、シーケンシャルスキャンの約7 倍高速化しました。
パラメータを変更して並列度を70 まで変更して計測した結果、性能向上が最大となったのは並列度40 での 約25 倍 でした。
並列度が40 を超えるとオーバーヘッドにより性能は向上せず、並列度50 ～70 では並列度20 と同等の性能向上である約13 倍にまで戻りました。

4.5.1.2. 検証 A 補足 1:データ がメ モリに のり きら ない場合の検証結果
2TB メモリサーバでの検証では、データサイズが230G B のテーブルはすべてのデータファイルがO S のファイルキャッシュにおさまります。 そのため、検索を実施してもディスクへの
物理I/O がほとんど発生しておらず、CPU を効率的に使用できていると考えられます。 この推測が正しいか検証するため、メモリサイズの小さな256G B メモリサーバ上で同じデータを使用して並列度を変えて検証を行いました。
表 4.9 検証条件

DB サーバ
256G B メモリサーバ

スト レージ

FC ストレージ

SQL 文

保持データ 量768 万行（一日分）を集計するSQ L 1 年分（ 768 万× 366 ）

その結果の処理時間のグラフと表を以下に示します。

Page 29 of 78

PostgreSQL Enterprise Consortium

図 4.2 メモリに載りきらない場合の処理時間の変化

表 4.10 並列度と処理時間
並列度

366 処理時間 ( ミ リ秒 )

性能向上比

1

359,5431.00

2

207,441

1.73

3

188,532

1.91

4

187,935

1.91

5

184,824

1.95

6

183,906

1.96

7

179,5712.00

8

189,2291.90

9185,575

1.94

10

187,268

1.92

11

185,2811.94

並列度が3 以上では性能向上比がほぼ2 倍で横ばいになり、データがメモリに乗りきるサイズと比較するとパラレルクエリの効果が低いことがわかります。 データファイルが格納されているディスクに対するI/O 状況を sar -d コマンドで確認したところ以下のような状況でした。
表 4.11 sar -d コマンドによるディスク I/O 状況確認結果

2TB サーバ
並列度

256GB サーバ

平均 rd_sec/s

平均 % util

平均 rd_sec/s

平均 % util

1

0.00

0.00

1,206,857

70.11

2

0.00

0.00

2,111,040

94.76

3

0.00

0.00

2,384,332

96.18

4

0.00

0.00

2,333,760

96.92

5

0.00

0.00

2,345,654

97.33

6

0.00

0.00

2,401,205

97.60

7

0.00

0.00

2,442,297

97.83

8

0.00

0.19

2,407,313

97.94

9

0.00

0.22

2,406,484

98.05

10

0.00

0.29

2,366,832

98.14

11

0.00

0.35

2,430,127

98.16

Page 30 of 78

PostgreSQL Enterprise Consortium
推測とおり、メモリ2TB のサーバではディスク I/O がほとんど発生していないのに対し、メモリ256G B サーバでは性能向上が頭打ちになる並列度3 以降のrd_sec/s が約240万/秒となっています。 rd_sec/s は1 回に 1 セクター(512 バイト)のI/O であるため、計算では約1200MB /秒のI/O が発生していることになります。 また、%u til の値もほぼ100% に近く、これがボトルネックになっていると考えられます。

4.5.1.3. 検証 A 補足 2:スト レージ性能の違いに よる検証結果
ディスク I/O がパラレルクエリによる性能向上のボトルネックになることをさらに確かめるため、I/O 性能の低い内蔵ディスクにデータファイルを配置して同じ検証を行いました。
表 4.12 検証条件

DB サーバスト レージ

256G B メモリサーバ

内蔵ディスクSQL 文

保持データ 量768 万行（一日分）を集計するSQ L 1 年分（ 768 万× 366 ）

その結果の処理時間のグラフと表を以下に示します。

図 4.3 内蔵ディスクを使用した場合の処理時間の変化

表 4.13 並列度と処理時間
並列度

処理時間 ( ミ リ秒 )

性能向上比

1

1,082,303

1.00

2853,0461.27

3

850,580

1.27

4

798,4751.36

5851,6381.27

6874,2691.24

7

850,908

1.27

8

879,7781.23

9893,5781.21

10

943,8311.15

11936,294

1.16

高性能なFC ストレージと比較すると絶対的な処理時間も長く、パラレルクエリによる性能向上の幅も限定的であることがわかります。

4.5.2. 検証 B(パー ティシ ョ ン テー ブル と単一 (非パー ティシ ョ ン )テー ブル の 比較 )時系列などの大量データを保持するテーブルの検索性能向上のために、テーブルをパーティション化し、検索条件で検索対象となるパーティションを絞り込む（パーティション
プルーニング）という手法が使われることがあります。
パラレルクエリによる性能向上と、パーティションテーブルによる性能向上がどの程度の差があるのかを、パーティションプルーニングが効かないSQ L と、パーティションプルーニングが効く SQ L の２通りを検証しました。

4.5.2.1. パーティショ ンプルーニングが効かない SQL

Page 31 of 78

PostgreSQL Enterprise Consortium
検索条件にパーティションキーがなく、パーティションプルーニングが効かないSQ L の検証結果は以下のとおりです。
表 4.14 検証条件

DB サーバ2TB メモリサーバ

スト レージ

FC ストレージ

SQL 文
768 万行（一日分）を集計するSQ L 。

保持データ 量1 年分（ 768 万× 366 ）パーティションプルーニング無効
その結果の処理時間のグラフと表を以下に示します。

図 4.4 パーティションプルーニングが無効となるSQ L 処理時間比較

表 4.15 並列度と処理時間(パーティションプルーニングが無効)
並列度

単一テーブル 処理時間 ( ミ リ秒 )パーティショ ンテーブル 処理時間 ( ミ リ秒 )1

309,315

408,7172

166,692

263,4383

120,424

193,406

4

95,868151,5565

85,187

122,441

6

73,6697

62,176

8

61,909954,92910

49,251

11

44,922

パーティションプルーニングが効かないSQ L では、並列度が1 、つまりパラレルクエリが有効ではない状態では、単一テーブルで309 秒、パーティションテーブルで409 秒と、パーティションテーブルではオーバーヘッドのため約1.3 倍処理時間がかかっています。 ただしパーティションプルーニングが効かないSQ L でもパラレルクエリにより性能向上は見込
め、並列度5 の時に 122 秒と非パラレルの場合と比べて、約3.3 倍性能向上しています。

4.5.2.2. パーティショ ンプルーニングが効く SQL
検索条件にパーティションキーがあり、パーティションプルーニングが効く SQ L の検証結果は以下のとおりです。

Page 32 of 78

PostgreSQL Enterprise Consortium
表 4.16 検証条件

DB サーバ2TB メモリサーバ

スト レージ

SQL 文

FC ストレージ

768 万行（一日分）を集計するSQ L 。

保持データ 量1 年分（ 768 万× 366 ）パーティションプルーニング有効
その結果の処理時間のグラフと表を以下に示します。
パーティションプルーニングが効く場合は、単一テーブル293 秒に比べてパーティションテーブルでは4 秒と2 桁ほど処理時間が短いです。
パーティションプルーニングが効く場合でもパラレル化による性能向上は見込めますが、元々速いので絶対値としての削減量は小さいです。

図 4.5 パーティションプルーニングが有効となるSQ L 処理時間比較

表 4.17 並列度と処理時間
並列度

単一テーブル 処理時間 ( ミ リ秒 )パーティショ ンテーブル 処理時間 ( ミ リ秒 )1

293,1093,950

2

159,124

2,078

3

108,743

1,483

4

86,3361,263

570,3631,135

660,635

7

52,9048

47,057

942,42010

38,8601135,8634.5.3. 検証 C(異なるワー カー 数が起動するテー ブル 同士結合時の ワー カー 数検証 )計算上起動されるワーカー数が異なるテーブルを結合した場合、実際に起動されるワーカー数がどのようになるか、また、テーブル結合の方式によってどのようになるかを検証しました。 起動されるワーカーの状況の確認のためには、exp lain an alyze よりもexp lain ( an alyze, verb o se )のほうが、実際に起動されたワーカー内の処理時間や処理した行の概数が表示されるため、好ましいです。

4.5.3.1. ネステッド ループ結合
256G B メモリサーバ上でネステッドループ結合を行う SQ L を実行しました。小さいテーブル（ p ro du ct_master テーブル）へのアクセスは、結合に使用するカラムにインデックス

Page 33 of 78

PostgreSQL Enterprise Consortiumが作成されているため、In dex Scan となります。 そのためパラレルスキャンにはなりません。大きいテーブル（ access_lo g テーブル）のスキャンは複数プロセスで並列処理され、起動されるワーカー数は10 となっています。
表 4.18 検証条件

DB サーバ
256G B メモリサーバ

スト レージ

FC ストレージ

SQL 文

保持データ 量2 テーブルを結合させ10 万行を取得する 1 年分（ 768 万× 366 ）SQ L 。

exp lain an alyze とexp lain (an alyze, verb o se)の出力結果は以下のとおりです。exp lain (an alyze, verb o se)のほうが詳細な情報が出力されていることがわかります。
・ exp lain an alyze

QUERY PLAN---------------------------------------------------------------------------------------------------------------------------------------------Nested Loop (cost=1000.42..34216441.40 rows=37882 width=40) (actual time=8.075..186255.334 rows=99740 loops=1)-> Gather (cost=1000.00..33901973.20 rows=37882 width=4) (actual time=8.059..186109.137 rows=99740 loops=1)
Workers Planned: 10
Workers Launched: 10-> Parallel Seq Scan on access_log a (cost=0.00..33897185.00 rows=3788 width=4) (actual t
ime=3.800..186236.448 rows=9067 loops=11)
Filter: ((date = '20160101'::bpchar) AND ((log_id % '77'::bigint) = 0))
Rows Removed by Filter: 255525478-> Index Scan using product_master_pkey on product_master p (cost=0.42..8.29 rows=1 width=40) (actual time=0.001..0.001 rows=1 loops=99740)
Index Cond: (product_id = a.product_id)
・ exp lain (an alyze, verb o se)

QUERY PLAN-------------------------------------------------------------------------------------------------------------------------------------------------Nested Loop (cost=1000.42..34216441.40 rows=37882 width=40) (actual time=6.127..180622.369 rows=99740 loops=1)
Output: a.product_id, p.product_name-> Gather (cost=1000.00..33901973.20 rows=37882 width=4) (actual time=6.105..180479.876 rows=99740 loops=1)
Output: a.product_id
Workers Planned: 10
Workers Launched: 10-> Parallel Seq Scan on public.access_log a (cost=0.00..33897185.00 rows=3788 width=4) (actual time=6.159..180604.178 rows=9067 loops=11)
Output: a.product_id
Filter: ((a.date = '20160101'::bpchar) AND ((a.log_id % '77'::bigint) = 0))
Rows Removed by Filter: 255525478
Worker 0: actual time=7.211..180618.215 rows=9587 loops=1
Worker 1: actual time=7.345..180618.488 rows=10195 loops=1
Worker 2: actual time=7.529..180618.285 rows=9782 loops=1
Worker 3: actual time=7.719..180618.567 rows=9710 loops=1
Worker 4: actual time=7.882..180619.043 rows=9990 loops=1
Worker 5: actual time=7.923..180618.817 rows=9523 loops=1
Worker 6: actual time=2.440..180619.029 rows=9909 loops=1
Worker 7: actual time=2.772..180619.381 rows=10155 loops=1
Worker 8: actual time=7.899..180619.093 rows=9943 loops=1
Worker 9: actual time=3.138..180619.706 rows=10282 loops=1-> Index Scan using product_master_pkey on public.product_master p (cost=0.42..8.29 rows=1 width=40) (actual time=0.001..0.001 rows=1 loops=99740)
Output: p.product_id, p.product_name
Index Cond: (p.product_id = a.product_id)
4.5.3.2. ハッシュ結合

Page 34 of 78

PostgreSQL Enterprise Consortium

256G B メモリサーバ上でハッシュ結合を行う SQ L を実行しました。起動されたワーカー数は10 となりました。
計算上起動されるワーカー数は大きいテーブル（ access_lo g テーブル）が10 、小さいテーブル（ p ro du ct_master テーブル）が4 です。 exp lain (an alyze, verb o se)コマン
ドの結果を見ると、実際にはp ro du ct_master テーブルも10 個のワーカーによりスキャンされている(赤字部分)ことが確認できました。
・ exp lain an alyze

QUERY PLAN------------------------------------------------------------------------------------------------------------------------------------------Gather (cost=8797.00..33911415.29 rows=37882 width=40) (actual time=79.738..238055.321 rows=99740
loops=1)
Workers Planned: 10
Workers Launched: 10-> Hash Join (cost=7797.00..33906627.09 rows=37882 width=40) (actual time=76.084..238048.282 ro
ws=9067 loops=11)
Hash Cond: (a.product_id = p.product_id)-> Parallel Seq Scan on access_log a (cost=0.00..33897185.00 rows=3788 width=4) (actual t
ime=4.605..237973.441 rows=9067 loops=11)
Filter: ((date = '20160101'::bpchar) AND ((log_id % '77'::bigint) = 0))
Rows Removed by Filter: 255525478-> Hash (cost=3734.00..3734.00 rows=200000 width=40) (actual time=70.721..70.721 rows=200000 loops=11)
Buckets: 65536 Batches: 8 Memory Usage: 2316kB-> Seq Scan on product_master p (cost=0.00..3734.00 rows=200000 width=40) (actual t
ime=0.018..32.052 rows=200000 loops=11)
・ exp lain (an alyze, verb o se)

Page 35 of 78

PostgreSQL Enterprise Consortium

QUERY PLAN------------------------------------------------------------------------------------------------------------------------------------------Gather (cost=8797.00..33911415.29 rows=37882 width=40) (actual time=67.438..286325.054 rows=99740
loops=1)
Output: a.product_id, p.product_name
Workers Planned: 10
Workers Launched: 10-> Hash Join (cost=7797.00..33906627.09 rows=37882 width=40) (actual time=69.543..286317.637 ro
ws=9067 loops=11)
Output: a.product_id, p.product_name
Hash Cond: (a.product_id = p.product_id)
Worker 0: actual time=71.316..286319.780 rows=9167 loops=1
Worker 1: actual time=71.334..286319.553 rows=9348 loops=1
Worker 2: actual time=67.892..286320.195 rows=9203 loops=1
Worker 3: actual time=71.601..286320.017 rows=9284 loops=1
Worker 4: actual time=67.893..286320.432 rows=9090 loops=1
Worker 5: actual time=71.888..286320.081 rows=9376 loops=1
Worker 6: actual time=69.246..286320.465 rows=9134 loops=1
Worker 7: actual time=72.278..286320.148 rows=9304 loops=1
Worker 8: actual time=66.812..286320.426 rows=9131 loops=1
Worker 9: actual time=67.552..286321.155 rows=9165 loops=1-> Parallel Seq Scan on public.access_log a (cost=0.00..33897185.00 rows=3788 width=4) (actual time=1.925..286246.477 rows=9067 loops=11)
Output: a.product_id
Filter: ((a.date = '20160101'::bpchar) AND ((a.log_id % '77'::bigint) = 0))
Rows Removed by Filter: 255525478
Worker 0: actual time=2.199..286247.064 rows=9167 loops=1
Worker 1: actual time=2.196..286246.933 rows=9348 loops=1
Worker 2: actual time=2.427..286251.181 rows=9203 loops=1
Worker 3: actual time=2.473..286247.263 rows=9284 loops=1
Worker 4: actual time=2.684..286251.689 rows=9090 loops=1
Worker 5: actual time=2.770..286247.360 rows=9376 loops=1
Worker 6: actual time=2.802..286250.378 rows=9134 loops=1
Worker 7: actual time=0.067..286244.552 rows=9304 loops=1
Worker 8: actual time=0.053..286250.022 rows=9131 loops=1
Worker 9: actual time=0.447..286250.427 rows=9165 loops=1-> Hash (cost=3734.00..3734.00 rows=200000 width=40) (actual time=66.977..66.977 rows=200000 loops=11)
Output: p.product_name, p.product_id
Buckets: 65536 Batches: 8 Memory Usage: 2316kB
Worker 0: actual time=68.361..68.361 rows=200000 loops=1
Worker 1: actual time=68.444..68.444 rows=200000 loops=1
Worker 2: actual time=64.821..64.821 rows=200000 loops=1
Worker 3: actual time=68.435..68.435 rows=200000 loops=1
Worker 4: actual time=64.598..64.598 rows=200000 loops=1
Worker 5: actual time=68.450..68.450 rows=200000 loops=1
Worker 6: actual time=65.770..65.770 rows=200000 loops=1
Worker 7: actual time=71.617..71.617 rows=200000 loops=1
Worker 8: actual time=66.124..66.124 rows=200000 loops=1
Worker 9: actual time=66.344..66.344 rows=200000 loops=1-> Seq Scan on public.product_master p (cost=0.00..3734.00 rows=200000 width=40) (actual time=0.017..28.920 rows=200000 loops=11)
Output: p.product_name, p.product_id
Worker 0: actual time=0.020..30.171 rows=200000 loops=1
Worker 1: actual time=0.018..29.697 rows=200000 loops=1
Worker 2: actual time=0.017..26.473 rows=200000 loops=1
Worker 3: actual time=0.017..30.388 rows=200000 loops=1
Worker 4: actual time=0.012..26.610 rows=200000 loops=1
Worker 5: actual time=0.018..30.037 rows=200000 loops=1
Worker 6: actual time=0.019..27.514 rows=200000 loops=1
Worker 7: actual time=0.020..33.813 rows=200000 loops=1
Worker 8: actual time=0.012..28.000 rows=200000 loops=1
Worker 9: actual time=0.021..28.487 rows=200000 loops=1

Page 36 of 78

PostgreSQL Enterprise Consortium

4.6. 考察4.6.1. 検証 A
256G B メモリサーバと2TB メモリサーバではPo stgreSQ L のキャッシュ領域であるsh ared_b u ffers の値は両方とも100G B に設定していました。 しかし、同一のデータ量、同一のSQ L をパラレルクエリで実行させた場合に、処理時間に大きな差がでました。 その原因は2TB メモリサーバではディスク I/O が発生しなかったのに対し、256G B メモリサー
バでは大量のディスク I/O が発生し、それがボトルネックになったことがあげられます。 I/O 性能の低い内蔵ディスクを使用した場合には、ボトルネックがさらに顕著になりました。 このことから、データがキャッシュ（ sh ared_b u ffers ではなく O S のファイルキャッシュ）に載ると、ディスク I/O のボトルネックが解消され、デフォルトの最大並列度以上の並
列度まで処理性能が向上するといえます。 本検証の2TB メモリサーバ上ではデフォルトの11 よりも大きな40 までスケールしました。
内蔵ディスクのように I/O 性能が高くないディスクの場合、キャッシュに載りきらないテーブルではデフォルトの最大並列度にいたるまでに性能が悪化するので注意が必要です。

4.6.2. 検証 B
パーティションプルーニングが有効な検索では、パラレルクエリによる効果よりもパーティションプルーニングの効果が高く、パーティションテーブルへの検索の方が非常に高速でした。 一方パーティションプルーニングが有効にならない検索では、パーティション化によるオーバーヘッドにより単一テーブルの検索の方が速くなりますが、パラレルクエリの効果
により、どちらのテーブルでも処理性能は向上します。
以上の結果から、大量データの検索性能向上の手段としては、いままでとおりパーティションテーブルの導入が有効です。 Po stgreSQ L 9.6 のパーティションテーブルには作成方法が複雑だったり、制約があったりしましたが、次期バージョンであるPo stgreSQ L 10 では多くの改善がされる予定ですので、期待したいと思います。

4.6.3. 検証 C
テーブルを結合するSQ L では、起動されるワーカー数は並列度の大きいテーブル（ access_lo g テーブル）によって決定され、ハッシュ結合の場合は小さいテーブル（ p ro du ct_master テーブル）も大きいテーブルのワーカー数でスキャンされました。 ただし、exp lain コマンドに verb o se オプションをつけないと、通常の「 Seq Scan 」のように表示されるため、注意が必要です。
また、p ro du ct_master テーブルは10 個のワーカーでスキャンされていますが、「 Parallel Seq Scan 」ではなく「 Seq Scan 」となっている点も注目すべき点です。 「 Parallel
Seq Scan 」では各ワーカー（と親プロセス）が、全体のスキャン対象を分割してスキャンを行うのに対し、「 Seq Scan 」では各ワーカー（と親プロセス）が、それぞれ全体をスキャンしています。

4.6.4. 総括
本検証を通じて、パラレルクエリによる性能向上を有効活用するためには、搭載するメモリ量を多くしたり、高性能のストレージを利用したりするなどの方法でディスク I/O の影響を極力減らすことが必要であることがわかりました。
また、パーティションテーブルに対するパーティションプルーニングはパラレルクエリによって代替されるものではなく、依然有効であること、またパーティションプルーニングが効かな
い場合にも、パラレルクエリによる性能向上があることが判明したのは大きな収穫でした。
パラレルクエリが実装されたことは、ハードウェア技術の進化を生かした大規模エンタープライズ用途向けの機能の一つがPo stgreSQ L に備わったと感じました。 次期バージョンでのパラレルクエリのさらなる進化に期待したいです。

Page 37 of 78

PostgreSQL Enterprise Consortium

5. Pgpool-II 検証
5.1. 検証概要
以前2012 年度に Pgp o o l-II のレプリケーション検証を行っております (2012 年度報告は こちら です)。当時は Pgp o o l-II が独自のレプリケーション機能を用いる方式(ネイティブレプリケーション)についての特性を検証しましたが、本年度はそれの再試に加え、 Po stgreSQ L 9.6 で新しく登場し、 ネイティブレプリケーションと特性の似た
remo te_ap p ly 同期ストリーミングレプリケーション方式との参照性能および更新性能の比較検証を行います。加えて、非同期設定と同期設定の比較を行うために非同期ストリーミングレプリケーション方式も検証対象としました。

5.2. Pgpool-IIとは
5.2.1. Pgpool-II 概要
Pgp o o l-II は、O SS として開発、公開されている Po stgreSQ L 専用のクラスタリング用ミドルウェアです (Pgp o o l-II オフィシャルサイトは こちら です)。
サポートする Po stgreSQ L のバージョンは 6.4 以降です。稼働環境は Lin u x/U NIX で、W in do w s では動作しません。Pgp o o l-II は Po stgreSQ L のクライアントアプリ
ケーションと Po stgreSQ L の間に割りこませる p ro xy のような使い方をします。つまり、Po stgreSQ L のクライアントアプリケーションから見ると Po stgreSQ L に見えて、
Po stgreSQ L から見るとクライアントアプリケーションのように振る舞います。

図 5.1 Pgp o o l-II と Po stgreSQ L

Pgp o o l-II を利用する上では、Pgp o o l-II は極力クライアントアプリケーションには手を入れなくて済むように設計されています（制限事項があります）。実際、本検証で使用している p gb en ch は、Po stgreSQ L で直接使う場合と同じ使い方ができます。また、Po stgreSQ L 本体にはまったく手を入れる必要はありません。

5.2.2. Pgpool-II 機能
Pgp o o l-II の機能は大きく分けて以下の４つがあります。
コネクションプーリング

Po stgreSQ L への接続を保存しておき、再利用することによって Po stgreSQ L への接続オーバヘッドを低減し、システム全体の性能を向上することができます。 [ 注: 本検証では p gb en ch が持続的に Po stgreSQ L に接続するため、この機能の恩恵は受けません。 ]HA クラスタPgp o o l-II は複数の Po stgreSQ L サーバを管理することができます。 HA クラスタ機能を使用することにより、 万が一どれかの DB サーバに障害が発生しても運用を継続することができます。Po stgreSQ L に障害が発生した際には、自動的に Po stgreSQ L サーバが切り離されます（フェイルオーバ）。
負荷分散
レプリケーションを運用している場合、どのサーバに問い合わせても同じ結果が返ってきます。 多数の検索リクエストをそれぞれのサーバで分担して負荷を軽減させ、システム全体の性能を向上させることができます。最良の場合にはサーバ台数に比例した検索性能向上が見込めます。
レプリケーション
レプリケーション機能を用いることで複数のDB サーバにリアルタイムで同じデータを保存することが出来ます。 Po stgreSQ L にもレプリケーション機能がありますが、 Pgp o o lII にはネイティブレプリケーションと呼ばれる独自のレプリケーション機能が備わっております。
本検証で主に利用する機能はレプリケーションと負荷分散です。レプリケーションについて詳しく見ていきます。Pgp o o l-II では、2 つのレプリケーションモードがあります(Pgp o o l-II を起動する前に予め設定します)。

5.2.2.1. ネイ ティブレプリケ ーショ ンモード (Pgpool-II の独自のレプリケ ーショ ン機能 )Page 38 of 78

PostgreSQL Enterprise Consortium
更新クエリをすべての Po stgreSQ L に送信することにより、データベースのレプリケーションを実現します。

図 5.2 ネイティブレプリケーション利用(Pgp o o l-II の独自レプリケーション機能を用いる方式)
この方式では、以下のように処理が行なわれます。

1. クライアントは更新クエリをPgp o o l-II に送信します。
2. Pgp o o l-II はまず更新クエリをマスターサーバ(健全なサーバのうち、最初に設定ファイルに記述されているサーバ)に送信、応答を待ちます。
3. マスターサーバから応答が返ってきたら、他のサーバにも同時に更新クエリを送信します。
4. すべてのサーバから更新コマンドの実行完了が返ってきたら、応答をクライアントに返します。
このように、クライアントに更新クエリの応答が返ってきた時点ですべてのサーバで更新が完了していることが保証されるため、これは同期レプリケーションとなります。 同期レ
プリケーションでは、クライアントは負荷分散によって異なるサーバに振り分けられた SELECTがタイミングによって異なる結果（古い結果）を受け取る可能性がないため、
Po stgreSQ L に直接接続していることを前提にしたプログラムの修正の必要がありません。
ただし、ステップ2-3 で応答待ちを行なう必要があるため、直接Po stgreSQ L に接続して更新を行なう場合に比べて、必ず更新性能は悪くなります。

Po stgreSQ L 2 ノードの場合、マスター(ノード0)の更新を待ってからノード1 を更新するので総合性能はPo stgreSQ L を直接使う場合の半分、つまり50% の性能
Po stgreSQ L 3 ノード以上では、2, 3... ノードは並列に更新を行なうので、やはり50%
ノードあたりの性能は、全体性能が2 ノード以上、何ノードになっても全体性能が50% なので、ノード数に応じて性能低下
図に、Pgp o o l-II の同期レプリケーションにおける更新性能の理論値を示します。 2012 年度の検証では本特性を実際に確認しています。

Page 39 of 78

PostgreSQL Enterprise Consortium

図 5.3 ネイティブレプリケーションの更新性能理論値
ただし、参照系クエリに関してはクラスタ中のただ 1 台のサーバで実行されます。 どのサーバで実行されるかはサーバの重み付け設定(b acken d_w eigh t)により決定されます。
各バックエンドは他のバックエンドの参照クエリの実行を待つ必要が無いので、参照クエリの実行性能はサーバ数によってスケールアウトします。その特性は2012 年度検証で実際に確認しています。

5.2.2.2. マスタ ースレーブモード (PostgreSQL のスト リーミ ングレプリケ ーショ ン機能を利用 )マスタースレーブモードは Pgp o o l-II 自体のレプリケーションの機能を利用せず、Po stgreSQ L のストリーミングレプリケーション機能を利用して、レプリケーションを実現する方法です(Slo n y-I のレプリケーション機能を利用することも可能です)。
マスタースレーブモードでは Pgp o o l-II は、コネクションプーリングと負荷分散、それにフェイルオーバのみを行ないます。 負荷分散の際、ストリーミングレプリケーションのスタン
バイは更新クエリを実行できないので、更新クエリは常にプライマリサーバに送信されます。 また、ネイティブレプリケーションと同様に参照クエリはクラスタ中のただ 1 台のサーバで実行されます。

Page 40 of 78

PostgreSQL Enterprise Consortium

図 5.4 マスタースレーブモード(Po stgreSQ L のストリーミングレプリケーション機能を利用)
マスタースレーブモードでは以下のように処理が行われます。

1. クライアントは更新クエリをPgp o o l-II に送信します。
2. Pgp o o l-II はまず更新クエリをプライマリサーバに送信、応答を待ちます。
1. 非同期設定の場合、スタンバイの状態は関係なく応答を返します。
2. 同期設定の場合、スタンバイの応答を待ってから応答を返します。
3. プライマリサーバから応答が返ってきたら、応答をクライアントに返します。
Po stgreSQ L のストリーミングレプリケーションは2. 以降でプライマリの更新W AL をトランザクション単位でスタンバイに送信し、スタンバイはそのW AL を適用することでデータレ
プリケートを行っています。
上記の 2.1., 2.2. で処理が異なる通り、Po stgreSQ L のレプリケーション方式は大きく分けて以下の2 つがあります。
非同期ストリーミングレプリケーション
非同期設定(syn ch ro n o u s_stan db y_n ames 設定なし)の場合、プライマリはスタンバイの応答を待たずにトランザクションのコミットを行います。 故に、非同期ストリーミン
グレプリケーションでは、プライマリサーバのデータよりもスタンバイサーバのデータは遅れている事になります。 反面、更新性能の低下は、ネイティブレプリケーションモードほど大きくありません。
同期ストリーミングレプリケーション
同期設定(syn ch ro n o u s_stan db y_n ames 設定あり)の場合、プライマリはスタンバイの応答を待ち、トランザクションのコミットを行います。
以前はスタンバイが W AL をディスク書き込みするまで待つのが限度でしたが、Po stgreSQ L 9.6 からスタンバイ上でデータを見られる状態になるまで待つことが可能になりました。これに伴い、syn ch ro n o u s_co mmit 設定に remo te_ap p ly が追加されました。

synchronous_commit = remote_apply

さらに、以前は同期ストリーミングレプリケーションはただ 1 台のスタンバイのみに適用されるもの(※)でしたが、 Po stgreSQ L 9.6 から複数のスタンバイに対して同期ストリーミ
ングレプリケーションを適用することが可能になりました。 それに伴い、syn ch ro n o u s_stan db y_n ames の書式が追加されました。
例えば、s1, s2, s3 という ap p licatio n _n ame を持ったスタンバイサーバがいるとして、 以下の設定だと s1, s2 が同期先となり、s3 は予備の同期先となります。

synchronous_standby_names = '2 (s1, s2, s3)'

Page 41 of 78

PostgreSQL Enterprise Consortium
また、s1, s2, s3 全てを常に同期先とする場合は以下の設定となります。

synchronous_standby_names = '3 (s1, s2, s3)'

syn ch ro n o u s_co mmit = remo te_ap p ly の同期設定と複数同期ストリーミングレプリケーション設定は同時に設定可能です。 つまり、複数のスタンバイに対して W AL
適用まで待つ同期ストリーミングレプリケーションが可能です。 本検証ではこれを利用して、全スタンバイに対して W AL 適用まで待つ同期ストリーミングレプリケーションを検証対象とします。

(※)以前も複数のスタンバイ名を記述できましたが、あくまで同期先となるのは1 台のみで、 他のスタンバイは予備の同期先でしかありませんでした。 例えば、以下の設定だと s1 が同期先となり、 s2, s3 は予備の同期先となります。

synchronous_standby_names = 's1, s2, s3'

ただし、以前の書式もPo stgreSQ L9.6 では有効です。

5.2.2.3. レプリケ ーショ ン方式まと め
Pgp o o l-II で用いることのできるレプリケーション方式（今回の検証対象）を比較すると以下の表のようになります。 表の「書き込みトランザクション完了までに必要な処理」
は書き込みトランザクション完了までに単一サーバのみの動作に対して各レプリケーション動作に新たに加わる処理を表しています。このとき、[]内に処理を行うサーバを示しています。
表 5.1 レプリケーション方式の比較
スト リーミ ングレプリケ ーショ ン ( 非同期)

ネイ ティブレプリケ ーショ ン

Po stgreSQ L の機能か

No (Pgp o o l-II の機能)

スト リーミ ングレプリケ ーショ ン(apply_remote 同期 )

Yes

Yes

スタンバイで常にプライマリと同じデータを Yes
参照できるかNo

Yes

書き込みトランザクション完了までに必要な処理[プライマリ]スタンバイへW AL 送信[プライマリ]スタンバイへW AL 送信、[スタンバイ]W AL 書き込み、[スタンバイ]W AL
適用、[プライマリ]スタンバイからの適用[プライマリ]スタンバイへクエリ発行、[スタンバイ]クエリ実行、[プライマリ]スタンバイからの実行応答待ち

応答待ち

5.3. 検証構成
5.3.1. 検証構成概要
検証構成は2012 年度検証に倣います。 クライアントマシン(p gb en ch ), サーバマシン(Pgp o o l-II と Po stgreSQ L が同居) をそれぞれ 1~ 4 台で下記の構成を取り、それぞれの構成で各シナリオのパフォーマンスについて検証しました。 クライアントがアクセスする Pgp o o l-II サーバは常に同じです。

図 5.5 検証マシン構成 ※ 2 台目以降の Pgp o o l-II ・ Po stgreSQ L 間の矢印は省略

5.3.2. ハー ドウ ェア構成
Page 42 of 78

PostgreSQL Enterprise Consortium
表 5.2 ハードウェア構成
サーバ

AW S EC2 m4.xlarge

メモリ

16G B

CPU

4 プロセッサ

5.3.3. ソフトウ ェア構成
表 5.3 ソフトウェア構成
Po stgreSQ L 9.6.1

Pgp o o l-II

3.6.0

5.3.4. カー ネ ル 設定
O S デフォルト
ハイパースレッディングは利用しない

5.4. 検証方法
下記の比較対象をそれぞれ組み合わせて、p gb en ch にて TPS を計測しました。
レプリケーション構成
ネイティブレプリケーション
ストリーミングレプリケーション（非同期）
ただし、稼働スタンバイノードは全て非同期
ストリーミングレプリケーション（ remo te_ap p ly同期）
ただし、稼働スタンバイノードは全て remo te_ap p ly同期

p gb en ch シナリオ構成
更新系（ p gb en ch デフォルトシナリオ）
参照系（カスタムシナリオ） (※)
バックエンドサーバ台数 (= クライアント台数)

1~4(※)参照系カスタムシナリオ\set nbranches :scale\set ntellers 10 * :scale\set naccounts 100000 * :scale\set row_count 10000\set aid_max :naccounts - :row_count\set aid random(1, :aid_max)\set bid random(1, :nbranches)\set tid random(1, :ntellers)\set delta random(-5000, 5000)
SELECT count(abalance) FROM pgbench_accounts WHERE aid BETWEEN :aid and :aid + :row_count

5.4.1. 設定
5.4.1.1. 各レプリケ ーショ ン方式に おける共通設定
Po stgreSQ L 設定 (p o stgresql.co n f)

shared_buffers = 8GB
wal_level = replica

Page 43 of 78

PostgreSQL Enterprise ConsortiumPgp o o l-II 設定 (p gp o o l.co n f)

backend_hostname0 = '192.168.1.30'
backend_port0 = 5432
backend_weight0 = 1
backend_data_directory0 = '/home/postgres/data'
backend_flag0 = 'ALLOW_TO_FAILOVER'# 同様にバックエンド4台分登録

スタンバイサーバ設定 (reco very.co n f)

standby_mode = 'on'
primary_conninfo = 'application_name=s1 user=postgres host=<プライマリサーバホスト> port=5432
sslmode=disable sslcompression=1'
primary_slot_name = 's1'
# primary_slot_name, application_name は各スタンバイで s1 - s4 として設定

5.4.1.2. ネイ ティブレプリケ ーショ ン
Pgp o o l-II 設定 (p gp o o l.co n f)

replication_mode = onmaster_slave_mode = off

5.4.1.3. スト リーミ ングレプリケ ーショ ン ( 非同期 )Pgp o o l-II 設定 (p gp o o l.co n f)

replication_mode = offmaster_slave_mode = onmaster_slave_sub_mode = stream

5.4.1.4. スト リーミ ングレプリケ ーショ ン (remote_apply 同期 )Po stgreSQ L 設定 (p o stgresql.co n f)

# 稼働スタンバイノードは全て同期させる(1ノード検証の場合)
synchronous_standby_names = ''(2ノード検証の場合)
synchronous_standby_names = '1 (s1,s2,s3)' (※ ただし、s2, s3 は停止しておく )(3ノード検証の場合)
synchronous_standby_names = '2 (s1,s2,s3)' (※ ただし、s3 は停止しておく )(4ノード検証の場合)
synchronous_standby_names = '3 (s1,s2,s3)'

Pgp o o l-II 設定 (p gp o o l.co n f)

replication_mode = offmaster_slave_mode = onmaster_slave_sub_mode = stream

5.4.2. 環境作成
Page 44 of 78

PostgreSQL Enterprise Consortiump gb en ch のデータベースサイズは 2012 年度検証に合わせて sh ared_b u ffers (8G B ) に入るサイズの 7.5G B としました。

$ initdb --no-locale --encoding=utf8$ pgbench -i -s 500 test # 約7.5GB

5.4.3. 検証実施
p gb en ch 実行前に p g_p rew arm を実行します。これによりテーブルデータはすべてバッファキャッシュに格納されます。

$ psql -c "select pg_prewarm('pgbench_accounts')" test

Pgp o o l-II サーバ台数と同数のクライアントマシンから同時に p gb en ch を走らせました。 (更新系シナリオの場合)$ pgbench -c 100 -T 300 -j 4 -d test

(参照系シナリオの場合)$ pgbench -c 100 -T 300 -j 4 -d test -f ${custom_script}

p gb en ch の設定は実行スクリプトを除き、以下の値で固定しています。
クライアント接続数(-c)： 100
実行時間(-T): 300 秒
スレッド数(-j): 4

5.5. 検証結果
5.5.1. 参照系
参照系シナリオの結果は下図のようになりました。いずれのレプリケーション方式でも同様にサーバ台数が増えるにつれて TPS が比例して上昇しており、異なるレプリケーショ
ン方式においてほぼ同じ値を示していました。
表 5.4 参照系
ネイ ティブレプリケ ーショ ン

非同期スト リーミ ングレプリケ ーショ ン

remote_apply 同期スト リーミ ングレプリケ ーショ ン

また、参考として Pgp o o l-II を経由しない参照性能も計測しています。このとき、サーバとクライアントはともに 1 台の条件で比較しています。
下図の通り、Pgp o o l-II を経由することに依る影響により参照性能が最大で7 ％低下しています。

Page 45 of 78

PostgreSQL Enterprise Consortium

図 5.6 Pgp o o l を経由しない参照性能(サーバとクライアントは1 台ずつ )5.5.2. 更新系
更新系シナリオの結果は下図のようになりました。非同期ストリーミングレプリケーションはサーバ数が増えても全体の更新性能は劣化しない反面、ネイティブレプリケーションとremo te_ap p ly同期ストリーミングレプリケーションは台数が増えるにつれて全体の更新性能は下がっていました。
しかし、ネイティブレプリケーションとremo te_ap p ly同期ストリーミングレプリケーションを比較するとスタンバイが存在する(ノード数が２以上の)場合、remo te_ap p ly同期スト
リーミングレプリケーションの方が高い値を出していました。
表 5.5 更新系
ネイ ティブレプリケ ーショ ン

非同期スト リーミ ングレプリケ ーショ ン

remote_apply 同期スト リーミ ングレプリケ ーショ ン

また、参考として Pgp o o l-II を経由しない更新性能も計測しています。このとき、サーバとクライアントはともに 1 台の条件で比較しています。
下図の通り、Pgp o o l-II を経由することに依る影響により更新性能が最大で16 ％低下しています。

Page 46 of 78

PostgreSQL Enterprise Consortium

図 5.7 (参考) Pgp o o l を経由しない更新性能(サーバとクライアントは1 台ずつ )5.6. 考察
本検証では2012 年度検証の再試及び、Pgp o o l-II で扱える複数のレプリケーション方式について性能比較をしました。 その結果、いずれのレプリケーション方式においても参照系と更新系で大きく性能特性が異なりました。

5.6.1. 参照系
各レプリケーション方式に性能差はほとんど無く、同様にサーバ台数に比例するスケールアウト性能を示していました。 これは、いずれのレプリケーション方式においても負荷分散の実装方式が同じで、参照系クエリは各サーバにおいて平等に並列実行できることから予測される結果でありました。 ネイティブレプリケーションにおいて、この結果は2012 年度検証と同様の結果でありました。

5.6.2. 更新系
サーバ台数が増加するにつれ、各レプリケーション方式の性能差が明らかになりました。まず、非同期ストリーミングレプリケーションでは、サーバ台数が増加しても１台(レプリケーションなし)のときから更新性能はほとんど変化はありませんでした。これは、非同期設定によりスタンバイの応答待ちがない、かつ更新クエリはプライマリサーバで実行される必要があることから予測される結果（同期による遅延もないがスケールアウトもしない）でした。また、サーバ台数が増えるごとに W AL 送受信に関する負荷も増える懸念はありましたが、本結果からはその影響は軽微であるといえます。
ネイティブレプリケーションとremo te_ap p ly同期ストリーミングレプリケーションでは、サーバ台数が2 台(スタンバイが1 台)になると全体の更新性能が下がりました。 この結果はスタンバイからの応答をプライマリサーバが待たなければならないことから予測される結果でありました。ネイティブレプリケーションにおいて、この結果も2012 年度検証と同様の結果でありました。
また、スタンバイ台数が2 台3 台と増えたときはスタンバイ1 台のときとほぼ同じ性能を示していましたが、これはスタンバイが2 台以上の場合レプリケーション処理が並列に実行されるので、1 台のときに比べて性能低下が少ないためです。
しかし、同じ同期レプリケーションでもremo te_ap p ly同期ストリーミングレプリケーションはネイティブレプリケーションに比べて、性能低下は小さいという結果でした。これは両者のレプリケーション実装方式において、ネイティブレプリケーションはスタンバイにクエリを送信および実行させているのに対し、remo te_ap p ly同期ストリーミングレプリケー
ションはW AL 送信および適用していることといった違いによるものと考えられます。

Page 47 of 78

PostgreSQL Enterprise Consortium

5.6.3. まとめ
上記の結果から、性能特性ではネイティブレプリケーションよりもremo te_ap p ly同期ストリーミングレプリケーションが優れていることが示されました。 また、機能特性としてネ
イティブレプリケーションよりもストリーミングレプリケーションが優れている事柄として以下の点が挙げられます。
使用できるSQ L に制限がない (ネイティブレプリケーションには一部制約あり)
同一クラスタに非同期スタンバイと同期スタンバイを混在させることができる
レプリケーションスロットなど、Po stgreSQ L のレプリケーション機能を補助する機能が利用できる
以前はスタンバイがプライマリと同じデータを参照できる状態まで待つ同期レプリケーションを実現するレプリケーション方式として Pgp o o l-II のネイティブレプリケーションは一つの選択肢でした。しかし、現在では9.6 で登場した remo te_ap p ly同期ストリーミングレプリケーションがPgp o o l-II 利用においても優位性を持っているといえます。
今後Pgp o o l-II で利用するレプリケーション方式は以下のような使い分けが考えられます。
レプリケーション遅延を問題とせず更新性能を優先する要件であれば、非同期ストリーミングレプリケーション
レプリケーション遅延が問題となりバックエンドがPo stgreSQ L9.6 以降であれば、remo te_ap p ly同期ストリーミングレプリケーション
レプリケーション遅延が問題となりバックエンドがPo stgreSQ L9.5 以前であれば、ネイティブレプリケーション
ただし、いずれのレプリケーション方式も参照性能に関しては大きな差はありません。

Page 48 of 78

PostgreSQL Enterprise Consortium

6. JSON/JSONB
6.1. 検証概要
Io T(In tern et o f Th in gs)の一種として、多くののセンサデータを格納して分析するケースがあります。 さまざまなセンサデータを集約するケースでは、データ構造(スキーマ)を事前に決定することができず、RDB MS でデータを管理することが難しい場合があります。
Po stgreSQ L では、以前からスキーマレスなデータを格納する手段を提供しています。特に、バージョン 9.2 以降、JSO N データを管理する仕組みが追加されました。
9.2: JSO N 型が追加
9.3: JSO N 型に対する各種演算機能が追加
9.4: JSO N をバイナリ格納するJSO NB 型が追加
本章では、Po stgreSQ L のJSO N 型/JSO NB 型を利用して、センサデータのような多様なデータをPo stgreSQ L で管理可能か検証した結果を報告します。 そして、検証の結果、Io T用途に Po stgreSQ L を適用する場合、RDB のテーブル定義としてどのようなスキーマが適切かを考察します。
今回の検証では、以下の3 つの観点で評価しました。
データ挿入性能
データサイズ
検索性能

6.2. 検証構成
6.2.1. 検証サ ー バ
今回の検証環境の構成を以下に示します。
表 6.1 検証構成
機器項目

Po stgreSQ L 用サーバ CPU

仕様
インテル Xeo n プロセッサE5-2690v4@ 2.60G Hz(14 コア)x2 合計 28 コア

搭載メモリ

256G B

内蔵ストレージ

HDD 1.2TB SAS 10K x 16

DB 格納用ストレージ

Fib er Ch an n el 接続(16G b p s) SAN
以下の2 領域を利用
領域1: Po stgreSQ L のDB 領域
領域2: W AL 領域
それぞれの領域はHDD 1.8TB 6G SAS 10K x 4(RAID10 、実効容量約3TB )で構成

OSRed Hat En terp rise Lin u x 7.2

DB MS

Po stgreSQ L 9.6.1

6.2.2. PostgreSQL
今回の検証では検証時期時点での最新バージョンPo stgreSQ L 9.6.1 を使用しました。 Po stgreSQ L 設定は以下を変更しています。
表 6.2 修正した Po stgreSQ L パラメータ

shared_buffers

26G B

effective_cache_size 128G B

6.3. 検証方法
6.3.1. テー ブル 定義
今回の検証では7 種類のモデルを使用しました。

Page 49 of 78

PostgreSQL Enterprise Consortium
表 6.3 検証モデル

RDB モデル

センサデータ内の各要素を通常のPo stgreSQ L の通常のデータ型として表現したモデル

JSON モデル

センサデータ全体をPo stgreSQ L のJSO N データとして表現したモデル

JSON B モデル

センサデータ全体をPo stgreSQ L のJSO NB データとして表現したモデル

ハイ ブリッド JSON モデル

必ず検索キーとして使用する要素をPo stgreSQ L の通常のデータ型、残りの要素はPo stgreSQ L のJSO N データとして表現したモデル

ハイ ブリッド JSON B モデル

必ず検索キーとして使用する要素をPo stgreSQ L の通常のデータ型、残りの要素はPo stgreSQ L のJSO N データとして表現したモデル。

以下に各テーブル定義(CREATE TAB LE 文)を示します。
リスト 6.1 RDB モデルのテーブル定義

CREATE TABLE IF NOT EXISTS iot (deviceID char(10),ts timestamp,
Latitude real,Longitude real,Temparature real,
Humidite real,
CO2 real,
AtmospheiricPressure real);
リスト 6.2 JSO N モデルのテーブル定義

CREATE TABLE IF NOT EXISTS iot_json (info json);
リスト 6.3 JSO NB モデルのテーブル定義

CREATE TABLE IF NOT EXISTS iot_jsonb (info jsonb);
リスト 6.4 ハイブリッドJSO N モデルのテーブル定義

CREATE TABLE IF NOT EXISTS iot_part_json (deviceID char(10),ts timestamp,
info json);
リスト 6.5 ハイブリッドJSO NB モデルのテーブル定義

CREATE TABLE IF NOT EXISTS iot_part_jsonb (deviceID char(10),ts timestamp,
info jsonb);

6.3.2. イン デ ッ クス定義
今回の検証では以下の2 つのパターンのインデックスを設定しました。

B -tree インデックス
B RIN(B lo ck Ran ge INdex)
B -Tree インデックスはPo stgreSQ L のデフォルトインデックス種別です。 B RIN はPo stgreSQ L 9.5 から導入された特殊なインデックスです。B -tree インデックスのように汎用的なインデックスではありませんが、値の論理的な順序とデータベースへの物理的な格納順序に強い相関関係があるデータに対して効果的なインデックスとなります。例えば、

Page 50 of 78

PostgreSQL Enterprise Consortium
タイムスタンプ情報をもつログデータなどを蓄積するようなケースに於いて、タイムスタンプ情報に対して設定するケースが該当します。
どちらのインデックスもタイムスタンプ情報を対象とします。 JSO N モデルおよびJSO NB モデルでは、JSO N/JSO NB 演算子を用いて取り出したタイムスタンプ情報に対して式
インデックスを設定します。
なお、JSO NB 型に対してはG IN(汎用転置インデックス)を設定することも可能ですが、今回の検証モデルでは検索条件として使うキーが固定であり、JSO NB データ内の全ての名前と値の組をインデックス化対象とするG IN インデックスを使用することは適切ではないと考え、検証対象からは除外しました。

6.3.3. デ ー タ挿入性能
今回の検証では、以下の想定でデータ挿入のモデルを検討しました。
一つのセンサが10 秒に 1 回、気温等のデータを送信すると仮定。
そのデータを100 機器分、3 年間蓄積したと仮定。
データ件数は約9.5 億件。
このデータを以下の方式で挿入し、そのときの時間を測定しました。
ロード時間(CO PY FRO M)。
ロード後にインデックス作成にかかる時間。
今回の検証では1 回のみ測定を行っています。

6.3.4. デ ー タ検索性能
今回の検証では、以下の想定でデータ検索のモデルを検討しました。
最近の(データ上は2019 年10 月)一ヶ月間のある機器(io t-00050)が収集したデータを検索対象として、以下の2 つのパターンの検索性能を測定しました。
単純検索：全データを上記条件で検索しし、その件数を取得。
平均気温取得：全データを上記条件で検索し、気温の平均(AVG )をとる。
検証結果は3 回測定したときの中間値(Median )を使用しました。

6.4. 検証結果
6.4.1. 格納性能とテー ブル サ イズ
表 6.4 データロード時間(秒)RDB モデル2954.592

JSON モデル

4965.902

JSON B モデル

5742.353

ハイ ブリッド JSON モデル

3433.817

ハイ ブリッド JSON B モデル

4920.315

表 6.5 テーブルサイズ(MB )RDB モデル

69077.1

JSON モデル

194506.6

JSON B モデル

254870.7

ハイ ブリッド JSON モデル

164250.0

ハイ ブリッド JSON B モデル

217389.7

Page 51 of 78

PostgreSQL Enterprise Consortium

図 6.1 データロード時間

図 6.2 テーブルサイズ

6.4.2. イン デ ッ クス作成性能とイン デ ッ クスサ イズ

Page 52 of 78

PostgreSQL Enterprise Consortium
表 6.6 インデックス作成時間(秒)方式

B -tree

B RIN

RDB モデル

641.751

153.347

JSON モデル

2472.123

1330.105

JSON B モデル

1672.458

435.233

ハイ ブリッド JSON モデル

822.484

227.385

ハイ ブリッド JSON B モデル

924.307312.148

図 6.3 インデックス作成時間(秒)表 6.7 インデックスサイズ(MB )方式

B -tree

B RIN

RDB モデル20266.1

2.3

JSON モデル

44873.5

13.8

JSON B モデル

44873.5

18.1

ハイ ブリッド JSON モデル

20266.1

5.4

ハイ ブリッド JSON B モデル

20266.1

7.1

Page 53 of 78

PostgreSQL Enterprise Consortium

図 6.4 インデックスサイズ(MB )6.4.3. デ ー タロー ドとイン デ ッ クス作成まとめ
テーブル作成時間とインデックス作成時間を合せた結果を以下に示します。

図 6.5 テーブル作成時間＋インデックス作成時間
テーブルサイズとインデックスサイズを合せた結果を以下に示します。

Page 54 of 78

PostgreSQL Enterprise Consortium

図 6.6 テーブルサイズ＋インデックスサイズ
以下に、データロードとインデックス作成の検証結果から、以下の内容が確認できました。
データロード時間について
ロード時間の長さは想定どおり、通常表＜JSO N ＜JSO NB となります。
JSO N モデルとJSO NB モデルののロード時間差と、インデックス作成時間の総和はほぼ等しくなります。これはJSO NB が格納時にシリアライズすることで、
ロード時間が遅くなる代わりに、インデックス作成背景で実行される取得処理が高速化されているためです。
データサイズについて
通常テーブルと比較するとJSO N で約3 倍、JSO NB で約4 倍のサイズとなります。
件数が非常に大きい場合、JSO N/JSO NB のモデルの場合、データサイズが大きくなることに注意する必要があります。

6.4.4. 検索性能

Page 55 of 78

PostgreSQL Enterprise Consortium

図 6.7 件数カウント検索

図 6.8 平均気温検索

6.4.5. 検索時間の まとめ
検索時間のサマリを示します。

JSO N と比較するとJSO NB の検索時の性能はかなり良くなります。
キーだけ通常列化した場合、通常表の検索性能並になる。また、この場合、JSO NB とJSO N はほぼ同等の性能となります。
今回のモデルのような非常に大きなサイズのテーブルに対して、連続した範囲を検索する場合には、B -tree インデックスとB RIN は同程度の検索性能になります。

Page 56 of 78

PostgreSQL Enterprise Consortium

6.5. 考察
今回の検証から、センサデータのようなIo T機器データの収集に Po stgreSQ L JSO N/JSO NB 型を使用する場合の注意点を列挙します。
必ず検索キーとして使う要素が確定している場合、その要素をJSO N/JSO NB 列とは分離して通常の列に持たせることで、性能の低下を抑えつつ、JSO NB の特色であるスキーマレスな情報の管理も同時に可能になる。
検索キーとして使用しない項目はJSO NB ではなく、JSO N を選択する案もある。
数十億件単位の非常に大量なレコード数を蓄積し、かつタイムスタンプ情報のような論理的な値と物理的な格納順序に強い相関があるケースでは、B RIN イン
デックスが有効である。

Page 57 of 78

PostgreSQL Enterprise Consortium

7. 全文検索7.1. 検証概要
Po stgreSQ L の適用領域の拡大、また取り扱うデータ量の増加に伴い、 Po stgreSQ L に格納されたデータに対する全文検索の重要性がますます高まっています。
標準のSQ L においても、LIKE 文を用いることで文字列パターンを指定した検索は可能ですが、 この場合テーブルのデータを全てシーケンシャルに検索することになるため、検索完了までに多くの時間が必要です。そのため実用面では、Po stgreSQ L に全文検索用の モジュールを導入し、インデックスを利用した高速な検索を実現する手法が一般的です。
本章では、特に国内においてニーズの高い"日本語検索"に対応した代表的な検索手法である p g_trgm （ピージートリグラム）、p g_b igm （ピージーバイグラム）、
PG ro o n ga （ピージールンガ）の特性を様々な視点の検証によって明らかにします。

7.2. 検証構成
7.2.1. マシ ン 構成
本検証に用いたハードウェア構成を 表. %s 、 ソフトウェア構成を 表. %s に示します。 今回はデータベースサーバと負荷クライアントは同じ筐体となっています （ p sql コ
マンドをPo stgreSQ L サーバ上で実行）。

表 7.1 ハードウェア構成
項目

仕様

機種

富士通PC ワークステーション「 CELSIU S R6702」

CPU

インテル Xeo n プロセッサ X5650@ 2.66G Hz(6 コア)x2 合計 12 コア

メモリ

48G B

内蔵ストレージ

HDD 500G B SATA x 2
表 7.2 ソフトウェア構成

ソフト ウェ ア

バージョ ンCen tO S

7.2 （ 64b it ）

用途

備考

OS

Po stgreSQ L 9.6.1

データベース

p g_b igm

1.2

インデックスPG ro o n ga

1.1.9

インデックスG ro o n ga

6.1.5

インデックスPG ro o n ga の動作に必要

7.2.2. 全文検索用モジュ ー ル
本検証で利用した全文検索用モジュールを 表. %s に示します。

表 7.3 検証対象の全文検索用モジュール
名称

p g_trgm

説明

ラ イ センスPo stgreSQ L のco n trib モジュールに同梱されており、標準で利解析方法

Po stgreSQ L Licen se

3-gram用可能

p g_b igm

日本語に対応した全文検索機能を提供するモジュール

Po stgreSQ L Licen se

2-gramPG ro o n ga

日本語に対応した全文検索機能として実績の豊富なG ro o n ga をPo stgreSQ L から利用可能にするモジュール

Po stgreSQ L Licen se

N-gram

7.2.3. postgresql.confの 設定値
p o stgresql.co n f の設定値を 表. %s のように変更しています。 今回は大量のデータに一度にインデックスを作成するため、main ten an ce_w o rk_mem を多めに確保しています。

Page 58 of 78

PostgreSQL Enterprise Consortium
表 7.4 p o stgresql.co n f の設定値
パラ メ ータ

設定値

max_co n n ectio n s

100

sh ared_b u fferes

12G B

max_w al_size

1G B

main ten an ce_w o rk_mem

4G B

考え 方

搭載メモリの1/4 を割り当て

インデックス作成の際に必要となる領域のため、多めに確保

7.3. 検証方法
7.3.1. 全文検索対象の デ ー タ
本検証の検索対象は、日本語版W ikip edia の文章データを抽出して、 Po stgreSQ L へtext 型として格納したものです。 表. %s にテーブル構造とデータの例を示します。

表 7.5 テーブル名「 W ikip edia 」

id （ integer型）

text（ text型）

1

Po stgreSQ L （ぽすとぐれすきゅーえる：発音例）は、オープンソースのオブジェクト関係データベース管理システム(RDB MS)である。…

2

MYSQ L （まい・えすきゅーえる）は、オープンソースで公開されている、関係データベースサーバの一つである。…

3…

W ikip edia は、利用している文章データを全てダウンロード可能な形式で公開しています (h ttp s://ja.w ikip edia.o rg/w iki/W ikip edia: データベースダウンロード)。
本検証では、日本語版W ikip deia の変更履歴を含む全データを対象とします。 ただし、全データは約1TB と非常に容量が大きく、また 14 ファイルに分割して公開されているため、 本検証ではそのうち1 ファイル（約79G B ）に含まれる文章データ（約41G B ）を 一つのテーブルに格納して検索を行っています。

7.3.2. イン デ ッ クスの 作成方法
作成したテーブルの「 text 」カラムに対し、CREATE INDEXコマンドでインデックスを作成します。

p g_trgm の場合

CREATE EXTENSION pg_trgm;
CREATE INDEX idx_text_trgm on wikipedia USING GIN (text gin_trgm_ops);
p g_b igm の場合

CREATE EXTENSION pg_bigm;
CREATE INDEX idx_text_bigm on wikipedia USING GIN (text gin_bigm_ops);
PG ro o n ga の場合

CREATE EXTENSION pgroonga;
CREATE INDEX idx_text_pgroonga on wikipedia USING GIN (text pgroonga.text_regexp_ops);

7.3.3. 検索方法
検索キーワードとしては、以下の英語／日本語の単語を利用します。
英語のみ: 3 文字～12 文字の28 単語（ n p m 、An sib le 、Po stgreSQ L など）
日本語のみ: 2 文字～7 文字の12 単語（日本、東京都、データベース など）
複数の検索キーワードをLIKE を用いて検索します。

SELECT COUNT(id) FROM wikipedia WHERE text LIKE '%keyword%';
検索に当たっては、以下の条件で測定しています。
同一キーワードで3 回測定を行い、中央値を結果として採用。なお、キャッシュは毎回クリアする。

Page 59 of 78

PostgreSQL Enterprise Consortiumsync
sysctl vm.drop_caches = 3
確実にインデックスを利用した検索をするため、シーケンシャルスキャンは「 o ff 」にする。

SET ENABLE_SEQSCAN=OFF;

7.3.4. イン デ ッ クスによる検索ノ イズ の 測定
本検証で対象としている全文検索用モジュールでは、N-gram と呼ばれる方式でインデックスを作成します。 インデックス作成の流れを 図. 7.1 に示します。 まず、データ
ベース中の文章を数文字で区切り、それらをキーと呼びます。 そして、キーが出現する文章のID との組をインデックスとして管理します。 図. 7.1 では2 文字で文章を区切ってキーを作成するため、 2-gram （バイグラム）と呼ばれます。同様に、3 文字で文章を区切るものは3-gram （トリグラム）と呼ばれます。 p g_b igm 、p g_trgm はその名の通り、それぞれ2-gram 、3-gram 方式でインデックスを作成しています。

図 7.1 N-gram によるインデックス作成の流れ
検索の際は、キーワードを同じように数文字で区切り、それらが全て出現する文章のID を 検索結果として返すことで、テーブル全体を走査することなく検索が可能となります。 図. 7.2 に、検索時の流れを示します。 しかし、N-gram による検索では、検索ノイズと呼ばれる誤りが発生する場合があります。 例えば、キーワード「東京都」で検索を行った場合、 図. 7.2 のようにレコード「東京と京都」も 検索結果として扱われることになり、正しい検索結果が得られません。

図 7.2 インデックスを利用した検索
この誤りを防ぐために、Po stgreSQ L ではインデックスによる検索結果を候補として扱い、 本当にキーワードを含むかを再検査するRech eck と呼ばれる処理を行います。 これにより、誤った検索結果を取り除くことが出来ます。

Po stgreSQ L では、EXPLAIN ANALYZE を実行することにより、Rech eck 前の検索件数を 知ることができ、インデックスのみの検索結果の精度を確認することが出来ます。
本検証では、Rech eck 前の検索件数も測定し、Rech eck 処理が検索時間に与える影響を調べます。

EXPLAIN ANALYZE SELECT COUNT(id) FROM wikipedia WHERE text LIKE '%keyword%';Page 60 of 78

PostgreSQL Enterprise Consortium

7.4. 検証結果
7.4.1. イン デ ッ クス作成時間、 デ ー タ増分の 比較
表. 7.6 に各種インデックスにおける インデックスの作成時間、またインデックス作成によるデータの増分を示します。 インデックスの作成時間はPG ro o n ga が最も早く、次いでp g_b igm 、p g_trgm の順となりました。 一方、データ増分はp g_b igm が最も小さく、次いでp g_trgm 、PG ro o n ga の順となり、 インデックスの作成時間とデータの増分にはあまり関係がなく、インデックスの実装によって 傾向が異なるという結果が得られました。

表 7.6 インデックス作成時間、データ増分比較
イ ンデック ス

イ ンデック ス作成時間

データ 増分

p g_trgm

26 時間46 分

20G B

p g_b igm

8 時間16 分

10G B

PG ro o n ga

6 時間46 分

131G B

7.4.2. 英語キ ー ワー ドによる比較
7.4.2.1. 検索時間の比較
図. 7.3 に、英語キーワードによる検索時間を示します。 キーワードによりばらつきはありますが、p g_trgm 、PG ro o n ga に比べて p g_b igm が検索に時間が かかっている
傾向が見られます。

図 7.3 英語キーワードによる検索時間

7.4.2.2. 検索時間と 件数の相関
今度は、検索時間と件数の相関図を 図. 7.4 に示します。 p g_trgm 、PG ro o n ga は、おおよそ件数に比例して検索時間が増加していきますが、 p g_b igm では相関が見られない結果となりました。

Page 61 of 78

PostgreSQL Enterprise Consortium

図 7.4 英語キーワードによる検索時間と件数の相関

7.4.2.3. Recheck 処理に よる影響
図. 7.5 は、Rech eck 処理により 除外された件数をインデックスごと比較したものです。 いずれのキーワードにおいてもp g_b igm が最も件数が多く、Rech eck 処理に時間がかかるため、 処理時間の長さに影響を与えているものと考えられます。

図 7.5 Rech eck 処理により除外された件数（英語）
次に、Rech eck 前にヒットしていた件数と検索時間の相関図を 図. 7.6 に示します。 図. 7.4 とは異なり、p g_b igm にも 検索時間と件数の相関が見えるようになりました。 これらから、p g_b igm ではRech eck 処理により除外される件数が大きい分、 検索時間が他インデックスよりも長くなるケースがあることが確認出来ました。

Page 62 of 78

PostgreSQL Enterprise Consortium

図 7.6 英語キーワードによる検索時間と件数の相関(Rech eck 前)

7.4.3. 日本語キ ー ワー ドによる比較
図. 7.7 に、日本語キーワードによる検索時間を示します。 キーワードが2 文字の場合に p g_b igm が特に速くなっています。 これは、p g_b igm が文章を2 文字で区切ってインデックスを作成しているため、 インデックスの効果が十分に発揮されているためと考えられます。

Page 63 of 78

PostgreSQL Enterprise Consortium

図 7.7 日本語キーワードによる検索時間

7.4.3.1. 検索時間と 件数の相関
また、検索時間と検索件数の相関図を 図. 7.8 に示します。 おおよそ検索時間が件数に比例していますが、キーワードが2 文字の場合に 外れ値が見られます。
p g_b igm については前述のとおり、インデックスが有効に働いているため 検索時間が短くなったものと考えられます。また、p g_trgm については、 インデックスが作成されているにもかかわらずシーケンシャルスキャンが採用されており、 このことが所要時間の増加につながっていると考えられます。

Page 64 of 78

PostgreSQL Enterprise Consortium

図 7.8 英語キーワードによる検索時間と件数の相関

7.4.3.2. Recheck 処理に よる影響
Rech eck 処理により除外された件数を 図. 7.9 に示します。 p g_trgm 、PG ro o n ga においては、今回検証した 12 種類のキーワードのうち10 種類で Rech eck 処理による除外がなされていませんでした。 全てのインデックスにおいて、英語よりも除外された件数が少なくなっているため、 検索件数と検索時間の関係が表れやすかったものと考えます。

図 7.9 Rech eck 処理により除外された件数（日本語）

7.5. 考察
本検証では、Po stgreSQ L の全文検索モジュール3 種を対象に、キーワード検索による 所要時間の比較を行いました。また、検索結果の件数やRech eck 処理との関係を調べることで、 各インデックスの特性を見ることが出来ました。
検索時間は、インデックスの読み取り時間とテーブルデータの読み取り時間の和ということが出来ます。 検索によるヒット件数が多いものでは、テーブルデータの読み取り量が多くなり、 インデックスの検索効率が大きく効いてくるものと考えられます。 一方で、検索によるヒット件数が少ないものでは、テーブルデータの読み取りにほとんど時間がか

Page 65 of 78

PostgreSQL Enterprise Consortium
からず、 インデックスの読み取り時間が検索時間の多くを占めることとなります。
今回の検証環境では、PG ro o n ga においてインデックス自体の容量が物理メモリの容量を超えており、 このことによりI/O が多く発生してしまい、結果として検索に時間がかかった可能性があります。 一方で、本検証で比較したもののうち最もインデックス容量が小さくなった p g_b igm においては、 インデックスの読み取り自体の時間は短くなりますが、Rech eck 処理の対象となるものが多くなるため、 検索時間が伸びてしまうケースが確認できました。
以上から、全文検索用モジュールを選定して利用する際は、各モジュールの特性に加え、 データベースを配置するサーバのリソース、例えばメモリやディスクの容量、 種類（ HDD ／SSD 、SAS 接続／SATA 接続 など）も考慮することが必要になってくると言えます。

Page 66 of 78

PostgreSQL Enterprise Consortium

8. VACUUM改善
8.1. 検証目的
8.1.1. VACUUM FREEZEについ て
Po stgreSQ L では、トランザクションID(以下、XID)を比較することで、MVCC を実現しています。 例えば、現在のトランザクションのXID より新しいXID を持った行は、 トラン
ザクション開始時点よりも未来のトランザクションで挿入されたものであり、 現在のトランザクションからは見ることができないようになっています。
ところで、XID のサイズは32b it in t で表現されているので、20 億トランザクションを超えるような 長時間稼働しているクラスタではトランザクションの周回が起こってしまいます。 このとき、突然、過去にコミットされたはずのトランザクションが未来のものとして見えるようになり、 結果として、データが損失するという事態が起こり得ます。 これを防ぐ手段として、XID 凍結のVACU U M 処理(以下、VACU U M FREEZE)があります。

VACU U M FREEZE では、行に XID 凍結状態という印をつけ、挿入トランザクションが確実に可視になるように、 十分古いコミットされたトランザクションに特別なXID(Fro zen Tran sactio n Id 、デフォルト値は2)を指定します。 このXID は通常のXID の比較規則に従わず、常に通常のXID よりも古いとみなすことで、 XID が周回してもデータの損失が起こらなくなります。 VACU U M FREEZE は、XID がしきい値となるau to vacu u m_freeze_max_age を超えると自動で実行されます。 また、自動でのVACU U M FREEZE では計画的なタイミングで行えないため、手動で実施するという運用も広く行われています。

8.1.2. PostgreSQL 9.6にお け る改善
Po stgreSQ L 9.6 ではVACU U M FREEZE の処理が効率的に実行されるように改善されました。
Po stgreSQ L 9.5 以前では、VACU U M FREEZE は対象テーブルのすべてのページをスキャンしており、 大きなテーブルに対するVACU U M FREEZE は非常に処理時間がかかるものでした。 また、自動VACU U M におけるVACU U M FREEZE は、XID がしきい値となるau to vacu u m_freeze_max_age を超えると実行されるため、 計画的に
VACU U M FREEZE を実行しないシステムでは、不意なタイミングで重い処理が走るという挙動が起こっていました。
Po stgreSQ L 9.6 ではVisib ility Map に対して、ページ内容が全て可視かどうかを表すフラグに加えて、 ページ内容がすべて XID 凍結済みかという情報をもつよう改良が入りました。 XID 凍結済みのフラグがついているページに対してはスキャンを行わなくなるようになりました。
これによって、データのほとんどが古いデータのまま更新されないような、すでに XID 凍結済みのページを多く含むような大きなテーブルに対して、 VACU U M FREEZE の処理が短時間で終わるようになりました。

8.1.3. 検証目的
Po stgreSQ L 9.6 でVACU U M FREEZE の際のXID 凍結済みのページをスキップするようになりましたが、 その基礎性能特性を得るのが今回の検証の目的です。
Po stgreSQ L 9.5 と9.6 でXID 凍結済みのページ数の割合を何パターンか用意し、 それぞれに対して VACU U M FREEZE を実行したときの処理時間を測定して、性能改善の程度を調べます。 また、得られた性能特性に対する考察と、どのような設計・運用で恩恵が得られるかを提示することを目的とします。

8.2. 検証構成
8.2.1. ハー ドウ ェア構成
本検証に用いた構成を 表. 8.1 に示します。今回の検証では、vacu u mdb コマンドをPo stgreSQ L サーバ上で実行しています。

表 8.1 検証構成
機器項目

Po stgreSQ L 用サーバ CPU

仕様
インテル Xeo n プロセッサE5-2690v4@ 2.60G Hz(14 コア)x2 合計 28 コア

搭載メモリ

256G B

内蔵ストレージ

HDD 1.2TB SAS 10K x 16

DB 格納用ストレージ

Fib er Ch an n el 接続(16G b p s) SAN
以下の4 領域を利用
領域1: Po stgreSQ L のDB 領域
領域2: W AL 領域
領域3: バックアップ用領域
領域4: ログ用領域
それぞれの領域はHDD 1.8TB 6G SAS 10K x 4(RAID10 、実効容量約3TB )で構成

OSRed Hat En terp rise Lin u x 7.2

DB MS

Po stgreSQ L 9.6.1
Po stgreSQ L 9.5.5

Page 67 of 78

PostgreSQL Enterprise Consortium

8.2.2. postgresql.confの 設定値
p o stgresql.co n f のパラメータを以下のようにします。VACU U M の性能を見るため、au to vacu u m はオフにしておきます。 加えて、XID 周回問題回避のau to vacu u m が起こりにくくするように、au to vacu u m_freeze_max_age を大きめの値にしておきます。
リスト 8.1 p o stgresql.co n f のデフォルトからの変更内容

autovacuum = off
max_connections = 100
shared_buffers = 192GB
wal_level = replica # PostgreSQL 9.6
wal_level = archive # PostgreSQL 9.5
max_wal_size = 1GBlisten_addresses = '*'logging_collector = on
log_line_prefix = '%t %p %a 'log_checkpoints = on
log_lock_waits = on
log_autovacuum_min_duration = 0
autovacuum_freeze_max_age = 1000000000

8.3. 検証方法
8.3.1. 環境構築
8.3.1.1. PostgreSQL のイ ンスト ール
Po stgreSQ L 9.5.5 と9.6.1 のソースコードを入手し、それぞれ/u sr/lo cal/p gsql95 、/u sr/lo cal/p gsql96 にインストールします。 異なるバージョンのPo stgreSQ L で検証するため、以下のようなスクリプトを使って切り替えます。
リスト 8.2 p gsql95-en v.sh#!/bin/bash
export PATH="$PATH":/usr/local/pgsql95/bin
export POSTGRES_HOME=/usr/local/pgsql95
export PGLIB=$POSTGRES_HOME/lib
export PGDATA=/data1/pgsql95/dataexport MANPATH="$MANPATH":$POSTGRES_HOME/man
export LD_LIBRARY_PATH="$LD_LIBRARY_PATH":"$PGLIB"
リスト 8.3 p gsql96-en v.sh#!/bin/bash
export PATH="$PATH":/usr/local/pgsql96/bin
export POSTGRES_HOME=/usr/local/pgsql96
export PGLIB=$POSTGRES_HOME/lib
export PGDATA=/data1/pgsql96/dataexport MANPATH="$MANPATH":$POSTGRES_HOME/man
export LD_LIBRARY_PATH="$LD_LIBRARY_PATH":"$PGLIB"
8.3.1.2. DB の作成
以下のようなSQ L のテンプレートを用いて検証に用いるテーブルを作成します。

Page 68 of 78

PostgreSQL Enterprise Consortium
リスト 8.4 gen _tab le.sql.temp late\set whole 10000000*"SCALE"\set skip :whole*"PERCENT"/100
CREATE TABLE t1 ( id BIGINT, data TEXT );INSERT INTO t1
SELECT id, repeat( md5( id::TEXT ), 2 )FROM generate_series( 1, :skip ) id;
VACUUM FREEZE;
INSERT INTO t1
SELECT id, repeat( md5( id::TEXT ), 2 )FROM generate_series( :skip+1, :whole ) id;
CHECKPOINT;
ここで、_SCALE_ は128 固定、_PERCENT_ は0, 20, 40, 50, 60, 80, 100 と変化させます。 これは、テーブルサイズがおおよそ128G B で、XID 凍結済みのページ数の割合
を おおよそ_PERCENT_ で指定する割合に合うようにします。
実際に DB を作成するスクリプトを以下に示します。 ここで、/data1 はデータ領域1 、/data2 はデータ領域2 、/data3 はデータ領域3 をマウントしたディレクトリです。
/data1 、/data2 、/data3 、/data4 の配下にはp gsql95 、p gsql96 というディレクトリが作成されているとします。 また、事前に設定した p o stgresql.co n f
は/data1/p gsql95 と/data1/p gsql96 に格納されているとします。
リスト 8.5 gen _db .sh#!/bin/bash
SCALE_LIST="128"
PERCENT_LIST="0 20 40 50 60 80 100"
if [ "$1" == "" ]; thenecho "./gen_db.sh { 95 | 96 }"exit
fi
BACKUP_DIR=/data3/pgsql${1}
CONF_DIR=/data1/pgsql${1}for SCALE in $SCALE_LIST; dofor PERCENT in $PERCENT_LIST; do
DB_NAME=db${SCALE}_${PERCENT}
DB_DIR=${BACKUP_DIR}/${DB_NAME}
echo "generate $DB_NAME"
initdb --locale=C -D $DB_DIR
cp ${CONF_DIR}/postgresql.conf ${DB_DIR}/
cp gen_table.sql.template gen_table.sql
sed -e "s/\"SCALE\"/${SCALE}/" -i gen_table.sql
sed -e "s/\"PERCENT\"/${PERCENT}/" -i gen_table.sql
pg_ctl start -D $DB_DIR
sleep 10
psql -f "gen_table.sql"
pg_ctl stop -D $DB_DIR
sleep 10done
done
8.3.1.3. 性能測定
測定の際は以下のスクリプトを利用します。

Page 69 of 78

PostgreSQL Enterprise Consortium
リスト 8.6 p erf.sh#!/bin/bash
SCALE_LIST="128"
PERCENT_LIST="0 20 40 50 60 80 100"
if [ "$1" == "" ]; thenecho "./perf.sh { 95 | 96 }"exit
fi
BACKUP_DIR=/data3/pgsql${1}PGDATA_DIR=/data1/pgsql${1}/data
WAL_DIR=/data2/pgsql${1}for SCALE in $SCALE_LIST; dofor PERCENT in $PERCENT_LIST; do
DB_NAME=db${SCALE}_${PERCENT}BACKUP_DB_DIR=${BACKUP_DIR}/${DB_NAME}
for TRIAL in `seq 1 3`; doecho "BEGIN PERF ${DB_NAME} ${TRIAL}/3"# DB構築mkdir $PGDATA_DIR
chmod 700 $PGDATA_DIR/
cp -R $BACKUP_DB_DIR/* $PGDATA_DIR/
mv $PGDATA_DIR/pg_xlog $WAL_DIR/
ln -s $WAL_DIR/pg_xlog $PGDATA_DIR/pg_xlog
pg_ctl start -D $PGDATA_DIR
sleep 10
# 測定
LOG_DIR=/data4/pgsql${1}/$DB_NAME/${TRIAL}
mkdir -p $LOG_DIR
LANG=C sar -A -o ${LOG_DIR}/sar.out 1 > /dev/null &LANG=C date > ${LOG_DIR}/begin
vacuumdb --verbose --freeze > ${LOG_DIR}/stdout 2>&1
LANG=C date > ${LOG_DIR}/end
KILLPROC=`ps aux | grep "sar" | cut -d' ' -f 2`
for PROC in $KILLPROC; dokill -15 $PROC
done# DB停止pg_ctl stop -D $PGDATA_DIR
sleep 10
# データ退避cp -R ${PGDATA_DIR}/pg_log ${LOG_DIR}# DB破棄rm -rf $WAL_DIR/pg_xlog
rm -rf $PGDATA_DIR
done
done
done
このスクリプトでは、gen _db .sh で/data3 に作成した DB を/data1 に戻し、W AL 領域を/data2 に設定しています。 そして、VACU U M FREEZE を実行し、sar やログ
を/data4 に書きだしています。 これを、/data3 に作成した DB に対して、3 回実施しています。

Page 70 of 78

PostgreSQL Enterprise Consortium

8.4. 検証結果
図. 8.1 に XID 凍結済みのページ数の割合に対する、スキャンしたページ数の結果を示します。これは仕様通り、9.5 ではすべてのページをスキャンしていますが、
Po sgtreSQ L 9.6 ではXID 未凍結の部分だけスキャンしていることが分かります。

図 8.1 スキャンしたページ数
図. 8.2 に XID 凍結済みのページ数の割合に対する実行時間をプロットしたグラフを示します。未凍結の場合は9.5 、9.6 で13 秒程度の差ですが、次第に処理時間の差が大きくなっていき、100% 凍結の場合、9.5 で100 秒かかる処理が9.6 では1 秒以下となり、その効果が大きいことが分かります。

図 8.2 p g_p rew arm なしの場合の実行時間
図. 8.3 に p g_p rew arm を実行し、sh ared_b u ffers にオンバッファになった状態での性能特性を示します。XID 未凍結の場合でも30 秒ほど9.6 が速く、スキャン性能自体も改善されていることが分かります。そして、全体的に 50 から 60 秒ほど9.6 が高速であることが分かります。

Page 71 of 78

PostgreSQL Enterprise Consortium

図 8.3 p g_p rew arm ありの場合の実行時間

8.5. 考察
検証結果より、確かに VACU U M FREEZE 時に Po stgreSQ L 9.6 ではXID 凍結済みページをスキップしていることが確認できました。 また、ページスキップ以外の要因と思われるものによって、Po stgreSQ L 9.6 が全体的に性能向上していることも確認できました。 これについて、ストレージへの負荷の状況から Po stgreSQ L9.5 と9.6 とでの性能特性の違いを考察してみます。 図. 8.4 、図. 8.5 に p g_p rew arm 実行後のXID 凍結済みのページ数が0% のテーブルに対して VACU U M FREEZE を実行したときの、
sar の%u til を示します。

図 8.4 Po stgreSQ L 9.5 でVACU U M FREEZE を行った場合のI/O 負荷

図 8.5 Po stgreSQ L 9.6 でVACU U M FREEZE を行った場合のI/O 負荷

DB 領域のu til を比較すると、9.6 と9.5 どちらもページスキップをせずに全ページに対して XID 凍結処理を行うにもかかわらず、 負荷の状況が大きく異なっております。また、W AL 領域のu til を比較すると、9.6 は9.5 と比較して負荷が小さくなっていることが分かります。 Po stgreSQ L 9.6 でW AL に関わる改善として、チェックポイントの改善などがあり、 これらの影響によって、ページスキップなしのVACU U M FREEZE でもPo stgreSQ L 9.6 の方が良好な性能が得られるのではないかと推測されます。
以上より、Po stgreSQ L 9.6 はPo stgreSQ L 9.5 と比較して、全体的に VACU U M FREEZE の性能が改善されており、 また、XID 凍結済みページが多い場合に非常に高速になることがわかりました。 したがって、Po stgreSQ L 9.6 では、9.5 以前で問題となっていた、不意なタイミングで発生する動作の重くなるVACU U M FREEZE の動作時
間、 計画的に VACU U M FREEZE を行うシステムにおけるメンテナンス時間を短くすることができ、非常に有益であることが分かりました。

Page 72 of 78

PostgreSQL Enterprise Consortium

Page 73 of 78

PostgreSQL Enterprise Consortium

9. おわりに2016 年度は、PG ECo n s のワーキンググループの位置づけを見直して、ワーキンググループ 1 (W G 1) は従来の「性能ワーキンググループ」から、性能に加えて新技術の検証も行う「新技術検証ワーキンググループ」として活動しました。
この章では各検証の結果を振り返って、Po stgreSQ L の機能・性能の現状をまとめます。

9.1. 検証結果から見る PostgreSQL の今ワーキンググループの新しい位置づけを踏まえて、今年度は以下の検証テーマを実施しました。

Po stgreSQ L 9.6 のスケール性(参照系および更新系)
Po stgreSQ L 9.6 の新技術・機能向上
パラレルクエリ
VACU U M 改善

JSO N/JSO NB
全文検索

Pgp o o l-II のスケール性
これらの検証の結果を、「メニーコアCPU への対応」「大量データの取り扱い」「多様化するデータ型への対応」という観点から、Po stgreSQ L の機能や性能の現状をまとめると、次のように言えるでしょう。
メニーコア CPU への対応

Po stgreSQ L のスケール性の検証では、Po stgreSQ L 9.6 は前バージョン 9.5 に対して参照系で約20% 、更新系で約30% 最大スループットが向上したことを確かめました。また、バージョン 9.6 はコア数が 24 を超える測定ケースで バージョン 9.5 よりもスループットが向上しており、メニーコア CPU でより性能を発揮することを確かめました。
また、1 つのSQ L 文(クエリ)を複数のプロセスで実行するパラレルクエリ機能の検証では、CPU コアが十分多数ある場合に、1 プロセスでのクエリ処理に比べて数十分の一で応答時間となるケースもあり、大幅な高速化が確かめられました。
こうした結果は、近年のCPU の高性能化がコア数を増やす方向に力点を置いていることとマッチしており、Po stgreSQ L は時代に即した高性能化を遂げていることを示しています。
大量データの取り扱い
大量データの取り扱いのための Po stgreSQ L の対応状況という観点では、上に挙げたパラレルクエリ機能が大量データの検索に有効であることを示しています。
従来、テーブルサイズが大きい場合には、テーブル内の古いデータを「凍結」するための VACU U M FREEZE にも時間を要していました。Po stgreSQ L 9.6 では凍結済みデータの処理をスキップすることで処理時間を短縮しています。今回の検証では、定期的に VACU U M FREEZE を実行して未凍結データを少なくすれ
ば、表のサイズとは関係なく十分短い時間で VACU U M FREEZE が完了することを示しました。
データの大量化に伴ってそれに対するアクセスが増えるケースでは、複数の Po stgreSQ L サーバによるデータベースクラスタによって負荷を分散することで、対応することが考えられます。今回の検証では、Pgp o o l-II によるクラスタにおいて Po stgreSQ L サーバの台数によってどのような性能傾向となるかを調査しました。その結果、更新負荷に対してはサーバの台数増加によるスループット向上はないものの、参照負荷に対しては台数に比例してスループットが向上することを示しました。
こうした結果は、Po stgreSQ L ではコア機能・周辺ツールを含めて、大量データを扱うための機能が向上していることを示しています。次バージョン Po stgreSQ L
10 ではパーティショニング機能の改善も予定されており、更なる向上が期待できます。
多様化するデータ型への対応

JSO N 形式のデータを扱う JSO N/JSO NB データ型での性能検証では、Io Tに代表される半構造型データを Po stgreSQ L で適切に扱う手法を検討しました。
JSO N/JSO NB データ型を使うと、半構造データをそのまま格納できる反面、通常のデータ型による格納・検索とはデータサイズ・性能にトレードオフがあることを示しました。
全文検索機能の検証では、日本語文字列を扱える全文検索インデックス3 種を調査しました。検索時間の比較からは、それらのインデックスの種類ごとに検索するデータの性質によって得意・不得意があることを示しました。
こうした結果は、Po stgreSQ L においても、半構造データの格納・検索や日本語の全文検索のための機能が整いつつあることを示す反面、その利用においては
ユースケースに沿った検証が不可欠であることを示唆しています。

9.2. 今後の活動に向けて先にも書いたように、今年度はワーキンググループの取り組み対象として、従来の性能に「新技術検証」を加えて検証を実施しました。取り上げたテーマには、以前から
PG ECo n s が検証してきた新バージョンの性能検証・ VACU U M の改善・ Pgp o o l-II に加えて、パラレルクエリ・全文検索・ JSO N/JSO NB を新たに取り上げました。
これらの検証結果をご利用いただく際には、ご自身のシステムの特性を加味した上で検討していただくことをお勧めします。とりわけ、パラレルクエリと全文検索については、
クエリ・データによって性能が大きく変わることが予想されます。

Page 74 of 78

PostgreSQL Enterprise Consortium
今回の検証を通じて、Po stgreSQ L の性能・機能の向上について確認することが出来ました。次の Po stgreSQ L はバージョン 10.0 となり、パーティショニングやパラレルク
エリの改善、ロジカルレプリケーションの実現など、さまざまな機能・性能の向上が図られる予定です。PG ECo n s はこれらの改善点についての調査・検証を通じて、引き続
き Po stgreSQ L のエンタープライズ領域への普及を推進してまいります。
今回の報告書が皆様の Po stgreSQ L の活用のご参考になれば幸いです。報告書へのご意見がございましたら、PG ECo n s までお寄せください。また、PG ECo n s の活動にご関心をお持ちの方は、是非、参加をご検討ください( ご連絡にはこちらのW eb サイト をご利用ください)。

(終わり)

Page 75 of 78

PostgreSQL Enterprise Consortium

10. 著者（企業・団体名順）
版
第1.0 版(2016 年度W G 1)

所属企業・ 団体名

部署名

SRA O SS, In c. 日本支社

氏名
石井 達夫（取締役支社長）

SRA O SS, In c. 日本支社

マーケティング部

近藤 雄太

NTTテクノクロス株式会社

クラウド＆セキュリティ事業部

原田 登志

NTTテクノクロス株式会社

クラウド＆セキュリティ事業部

勝俣 智成

日本電気株式会社

システムプラットフォームビジネスユニット
クラウドプラットフォーム事業部

川畠 輝聖

日本電気株式会社

システムプラットフォームビジネスユニット
クラウドプラットフォーム事業部

慶松 明嗣

日本電信電話株式会社

オープンソースソフトウェアセンタ

坂田 哲夫

日本ヒューレット・パッカード株式会社

テクノロジーコンサルティング事業統括

北山 貴広

日本ヒューレット・パッカード株式会社

テクノロジーコンサルティング事業統括

高橋 智雄

富士通株式会社

共通ソフトウェア開発技術本部
ソフトウェア開発技術統括部
O SS 技術センター

野山 孝太郎

富士通株式会社

共通ソフトウェア開発技術本部
ソフトウェア開発技術統括部
O SS 技術センター

高澤 亮平

Page 76 of 78

PostgreSQL Enterprise Consortium

11. ライセンス
本作品はCC-B Yライセンスによって許諾されています。 ライセンスの内容を知りたい方は こちら でご確認ください。 文書の内容、表記に関する誤り、ご要望、感想等につきましては、PG ECo n s のサイト を通じてお寄せいただきますようお願いいたします。

Eclip se は、Eclip se Fo u n datio n In c の米国、およびその他の国における商標もしくは登録商標です。
IB M およびDB 2 は、世界の多くの国で登録された In tern atio n al B u sin ess Mach in es Co rp o ratio n の商標です。
In tel 、インテルおよびXeo n は、米国およびその他の国における In tel Co rp o ratio n の商標です。
Java は、O racle Co rp o ratio n 及びその子会社、関連会社の米国及びその他の国における登録商標です。 文中の社名、商品名等は各社の商標または登録商標である場合があります。
Lin u x は、Lin u s To rvalds 氏の日本およびその他の国における登録商標または商標です。
Red Hat およびSh ado w man lo go は、米国およびその他の国におけるRed Hat,In c. の商標または登録商標です。
Micro so ft 、W in do w s Server 、SQ L Server 、米国 Micro so ft Co rp o ratio n の米国及びその他の国における登録商標または商標です。
MySQ L は、O racle Co rp o ratio n 及びその子会社、関連会社の米国及びその他の国における登録商標です。 文中の社名、商品名等は各社の商標または登録商標である場合があります。
O racle は、O racle Co rp o ratio n 及びその子会社、関連会社の米国及びその他の国における登録商標です。 文中の社名、商品名等は各社の商標または登録商標である場合があります。
Po stgreSQ L は、Po stgreSQ L Co mmu n ity Asso ciatio n o f Can ada のカナダにおける登録商標およびその他の国における商標です。
W in do w s は米国 Micro so ft Co rp o ratio n の米国およびその他の国における登録商標です。
TPC, TPC B en ch mark, TPC-B , TPC-C, TPC-E, tp mC, TPC-H, TPC-DS, Q p h H は米国Tran sactio n Pro cessin g Perfo rman ce Co u n cil の商標です。
その他、本資料に記載されている社名及び商品名はそれぞれ各社が 商標または登録商標として使用している場合があります 。

Page 77 of 78

PostgreSQL Enterprise Consortium

12. Appendix 検証環境
提供：日本ヒューレット・パッカード株式会社
定点観測（スケールアップ)/パラレルクエリ/JSO NB 検証での使用機器/設備

Page 78 of 78