Application of postgre sql to large social infrastructure jp

Copyright © 2016 NTT DATA Corporation
2016年12月2日
株式会社NTTデータ
システム技術本部
電力自由化を陰で支えるPostgreSQL
PGCONF.ASIA 発表資料

Copyright © 2016 NTT DATA Corporation 2
社会インフラへPostgreSQLを適用する道のり

3Copyright © 2016 NTT DATA Corporation
スマートメーター運用管理システムの位置づけ
集約装置
SM
SM
SM
スマートメーター
運用管理システム
SM
データセンター
SM
SM
SM
集約装置
託送業務
料金計算
(新メニュー用)
他電力へ
新電力へ
請求処理へ
Ｗｅｂ会員システム
ポイントシステム
スイッチング支援
電力広域機関
（電力広域的運営
推進機関）
★
SM:スマートメーター

システムの主要処理とミッション
スマートメーター運用管理システムの主要処理
30分おきに500万件の
指示数を収集
データの
欠測チェック等
最新の
指示数保存
使用量の
保存
使用量の
計算
10分以内
• 毎日、 2億4000万件増加
• 24ヶ月分
(≒1700億件分)保存が必要
500万件
挿入
500万件
挿入
ミッション 1
ミッション 2
バッチ等
大規模参照
ミッション 3

ミッション
1. 1000万件データを10分以内にロードせよ！
2. 24ヶ月分の大量データを長期保管せよ！
3. 大規模参照の性能を安定化せよ！

(1)1000万件データを10分以内にロードせよ！
★
指示数を収集
データの
最新の
指示数保存
使用量の
保存
使用量の
計算
10分以内
• 24ヶ月分
500万件
挿入
500万件
挿入
ミッション 2
バッチ等
大規模参照
ミッション 3
ミッション 1

格納モデルの選択
データは「機器ID」、「日時」、「指示数」を含む
例）機器ID：1は、8/1 1:00 の指示数は500
方法①：UPDATEモデル
機器ID、日付ごとに行を持ち、該当する時間のカラムの値をUPDATE
機器
ID
日付 0:00 0:30 1:00 1:30 …
1 8/1 100 300 500
2 8/1 200 400
PostgreSQLは追記型アーキテクチャを採用しているため、
高頻度の更新処理は性能がでにくい。

機器
ID
日付時刻値
1 8/1 0:00 100
1 8/1 0:30 300
1 8/1 1:00 500
… … …
○ レコードの追加(INSERT) が速い。
× テーブルサイズが大きくなる。
方法②：INSERTモデル
機器ID、日時ごとに、レコードをINSERT
機器
ID
日付 0:00 0:30 1:00 1:30 …
1 8/1 100 300 500
2 8/1 200 400

機器
ID
日付時刻値
1 8/1 0:00 100
1 8/1 0:30 300
1 8/1 1:00 500
… … …
○ レコードの追加(INSERT) が速い。
× テーブルサイズが大きくなる。
方法②：INSERTモデル
機器ID、日時ごとに、レコードをINSERT
機器
ID
日付 0:00 0:30 1:00 1:30 …
1 8/1 100 300 500
2 8/1 200 400
格納性能重視で採用！

高速ロードにおける性能ファクター
何件おきに
コミットすべき？多重度の
最適値？パラメータ？
データ型？
制約の有無？
インデックス？
バージョン？
性能ファクターを洗い出して事前検証
パーティションへの
ロード方法？

高速ロードにおける性能ファクター
多重度
8
wal_buffers
1GB
サイズが小さい
データ型制約は
最小限
インデックスは
最小限
PostgreSQL
9.4
パーティション子テーブルへ
直接ロード
10000件
コミット
DB設計へのフィードバック
チューニング時の切り札

特に性能改善に寄与した性能ファクター
多重度
8
wal_buffers
1GB
サイズが小さい
データ型制約は
最小限
インデックスは
最小限
PostgreSQL
9.4
パーティション子テーブルへ
直接ロード
10000件
コミット

ボトルネックはWAL処理だった！
19.83% postgres postgres [.] XLogInsert ★
6.45% postgres postgres [.] LWLockRelease
4.41% postgres postgres [.] PinBuffer
3.03% postgres postgres [.] LWLockAcquire
WALがネック！
perf（Linux性能解析ツール）
WAL処理
WAL
ファイル
ディスク
I/O
メモリ
WALバッファ
処理内容の
書込み
・コミットされた
・メモリが一杯になった
★ここを速くしたい

まずは…wal_buffersパラメータ
「デフォルト設定の-1で選択される自動チュー
ニングによると、ほとんどの場合妥当な結果
が得られます。」
PostgreSQLドキュメントより

wal_buffers検証結果
※格納時間のみ
（参照時間等除く）
0:00:00
0:01:00
0:02:00
0:03:00
0:04:00
0:05:00
0:06:00
0:07:00
0:08:00
0:09:00
16MB 1GB
処理時間
wal_buffersの効果

PostgreSQLバージョン
・WAL性能向上
・JSONB
・GINインデックス性能向上
・ロジカル・デコーディング
9.3 9.4
2014年12月リリース

バージョンアップによる高速化
• 当初PostgreSQL9.3を採用予定から9.4に変更
0:00:00
0:01:00
0:02:00
0:03:00
0:04:00
0:05:00
0:06:00
0:07:00
0:08:00
9.3 9.4
処理時間
バージョンアップの効果
※格納時間のみ
（参照時間等除く）

0:07:57
0:06:59
0:05:49
0:03:29
0:03:29
0:03:29
0:00:00
0:02:00
0:04:00
0:06:00
0:08:00
0:10:00
0:12:01
9.3, 16MB 9.3, 1GB 9.4, 1GB
処理時間
格納その他
改善の効果
目標値
目標達成！！
その他処理（参
照、計算など）は
チューニング済み。
※終局時ピークを想定した試験

(2) 24ヶ月分の大量データを長期保管せよ！
★
指示数を収集
データの
最新の
指示数保存
使用量の
保存
使用量の
計算
10分以内
• 24ヶ月分
500万件
挿入
500万件
挿入
ミッション 1
バッチ等
大規模参照
ミッション 3
ミッション 2

データ型を選んでサイズを小さく
• 整数
 範囲、精度をカバーできる最も小さいデータ型を使う！
• 真偽値
 CHAR(1)ではなく、フラグを使う！
型精度サイズ
SMALLINT 4桁(約±3.2万) 2 byte
INTEGER 9桁(約±21億) 4 byte
BIGINT 18桁(約±922京) 8 byte
NUMERIC 1000桁 3 or 6 or 8 + ceiling(桁数 / 4) * 2
型表現可能なデータサイズ
CHAR(1) 文字列長1の文字列 5 byte
BOOLEAN 真または偽の状態 1 byte

カラムの順番を変えてデータサイズを小さく
• アライメント（配置境界）
• PostgreSQLはアライメントをまたがってカラムを格納しない
1 2 3 4 5 6 7 8
column_1(4byte) ***PADDING***
column_2(8byte)
8 byteの場合

Column Type
column_1 integer
column_2 timestamp without time zone
column_3 integer
column_4 smallint
column_6 smallint
1 2 3 4 5 6 7 8
column_1 ***PADDING***
column_2
column_3 column_4 *PADDING*
column_5
column_6 ********PADDING*********
column_7
1 2 3 4 5 6 7 8
column_2
column_5
column_7
column_1 column_3
column_4 column_6
72 60
1行あたり12byte
節約すると…
一日あたり2.8GB！

格納モデルの変換
項
番
対象データ参照
頻度
更新
頻度
方針方式
1 当日
～65日分
高高更新性能重視 INSERTモデル
2 66日
～24ヶ月分
低低参照容易なレベルで
ストレージ量削減
UPDATEモデル
挿入時は性能重視でINSERTモデルを選択
• サイズが大きいので、長期保管には向いていない
アクセス頻度が低くなる期間からモデルを変換

格納モデル変換
機器ID 日付 0:00 0:30 1:00 … 22:30 23:00 23:30
1 8/1 100 300 500 … 1000 1100 1200
2 8/1 100 200 300 … 800 900 1000
機器ID 日付時刻値
1 8/1 0:00 100
2 8/1 0:00 100
1 8/1 0:30 300
2 8/1 0:30 200
1 8/1 1:00 500
2 8/1 1:00 300
… … …
1 8/1 22:30 1000
2 8/1 22:30 800
1 8/1 23:00 1100
2 8/1 23:00 900
1 8/1 23:30 1200
2 8/1 23:30 1000
INSERTモデル UPDATEモデル
機器ID、日時ごとに1レコードから
機器ID、日付ごとに1レコードに変換
毎レコードに存在する機器ID,日付の情報を重複して
持たない。
1日の件数： 2億4000万件→500万件
サイズ： 22GB→3GB

改善の効果
108
11
0
20
40
60
80
100
120
前後
データサイズ（TB)
データサイズの縮小

(3) 大規模参照の性能を安定化せよ！
★
ミッション 3
指示数を収集
データの
最新の
指示数保存
使用量の
保存
使用量の
計算
10分以内
• 24ヶ月分
500万件
挿入
500万件
挿入
ミッション 1
ミッション 2
バッチ等
大規模参照

大規模参照の性能を安定化せよ！
本案件では、「安定して性能要件を満たすこと」が大切
• 突然の実行計画の変化による性能劣化は避けたい
実行計画制御
特定のプランを選ばせる
pg_hint_plan
統計情報固定化
プランを変更させない
pg_dbms_stats
安定稼動

pg_hint_planとpg_dbms_statsを使用する前に
PostgreSQLのプランナはほとんどの場合は正しい実行計画を選ぶ
実行計画を固定すると、むしろ性能問題を引き起こすかもしれない
• ある時点で最適な実行計画でも、データの内容/サイズの変化により、
遅い実行計画になりうる
それでも、プランナが間違えるリスクを極力ゼロにしなければならない。
→デメリットを理解したうえで採用
• バッチ処理のあと直後のANALYZEが終わるまで
• テーブルの結合数が非常に多いケース
• …

pg_dbms_statsによる固定化
プランナ
pg_dbms_stats
PostgreSQL
本来の
統計情報
実行計画
生成
固定化
“固定化された”
統計情報

本プロジェクトのpg_dbms_stats使いこなし
指示数
データ
日テーブル
固定
統計情報
日テーブル
固定
統計情報
日テーブル
固定
統計情報
日パーティション
新しいパーティション子テーブルの追加と同
時に準備された固定統計情報をセット
コピー
一部の統計情報はテーブルによって異なる
ANALYZEをしなくても、
テーブル作成直後から
すぐに最適なプランが得られる
• テーブルOID、テーブル名
• パーティションキー、時刻

テーブルによって変わるべき統計情報の付け替え
• 値は想定可能なので、ダミーデータを作成。
• ダミーデータをANALYZEした結果をセット
格納された値を元にした統計情報
最頻値・頻度
ヒストグラム
たとえば、”8/1 0:00” “8/1 0:30” “8/1 1:00” など。
1日で48種類。分布は一様になる。
子テーブルによって格納される値が
大きく違うカラム
パーティションキー
時刻

ミッション
1. 1000万件データを10分以内にロードせよ！
2. 24ヶ月分の大量データを長期保管せよ！
3. 大規模参照の性能を安定化せよ！
COMPLETE

まとめ
2016年、PostgreSQL20周年
PostgreSQLはついに大規模社会インフラに採用されるまでとなりました。
しかし巨大なサイズ、厳しい性能要件を持った高難易度のシステムには、
PostgreSQLのノウハウに加え、業務特性も活かした工夫が必要です。
システムの成功のために、徹底した事前検証とノウハウで
PostgreSQLのポテンシャルを引き出しましょう！

Application of postgre sql to large social infrastructure jp

More Related Content

What's hot

Viewers also liked

Similar to Application of postgre sql to large social infrastructure jp

More from NTT DATA OSS Professional Services

Application of postgre sql to large social infrastructure jp