![13Copyright © 2016 NTT DATA Corporation
ボトルネックは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バッファ
処理内容の
書込み
・コミットされた
・メモリが一杯になった
★ここを速くしたい](https://image.slidesharecdn.com/applicationofpostgresqltolargesocialinfrastructurejp-161208114357/85/Application-of-postgre-sql-to-large-social-infrastructure-jp-13-320.jpg)
![JAVA_HOME/binにあるコマンド、いくつ使っていますか？[JVM関連ツール編]（JJUGナイトセミナー「Java解析ツール特集」 発表資料）](https://cdn.slidesharecdn.com/ss_thumbnails/javajvmtoolsjjug20211007nttdata-211008124040-thumbnail.jpg?width=560&fit=bounds)
Ad
More Related Content
What's hot (20)
Viewers also liked (20)
Ad
Similar to Application of postgre sql to large social infrastructure jp (20)
![[db tech showcase Tokyo 2015] B15:最新PostgreSQLはパフォーマンスが飛躍的に向上する！？ - PostgreSQ...](https://cdn.slidesharecdn.com/ss_thumbnails/dbts-tokyo-2015b15postgresqlntt-oss-center-150619073139-lva1-app6891-thumbnail.jpg?width=560&fit=bounds)
Ad
More from NTT DATA OSS Professional Services (20)
Application of postgre sql to large social infrastructure jp
- 1. Copyright © 2016 NTT DATA Corporation 2016年12月2日 株式会社NTTデータ システム技術本部 電力自由化を陰で支えるPostgreSQL PGCONF.ASIA 発表資料
- 2. Copyright © 2016 NTT DATA Corporation 2 社会インフラへPostgreSQLを適用する道のり
- 3. 3Copyright © 2016 NTT DATA Corporation スマートメーター運用管理システムの位置づけ 集約装置 SM SM SM スマートメーター 運用管理システム SM データセンター SM SM SM 集約装置 託送業務 料金計算 (新メニュー用) 他電力へ 新電力へ 請求処理へ Ｗｅｂ会員システム ポイントシステム スイッチング支援 電力広域機関 （電力広域的運営 推進機関） ★ SM:スマートメーター
- 4. 4Copyright © 2016 NTT DATA Corporation システムの主要処理とミッション スマートメーター運用管理システムの主要処理 30分おきに500万件の 指示数を収集 データの 欠測チェック等 最新の 指示数保存 使用量の 保存 使用量の 計算 10分以内 • 毎日、 2億4000万件増加 • 24ヶ月分 (≒1700億件分)保存が必要 500万件 挿入 500万件 挿入 ミッション 1 ミッション 2 バッチ等 大規模参照 ミッション 3
- 5. 5Copyright © 2016 NTT DATA Corporation ミッション 1. 1000万件データを10分以内にロードせよ！ 2. 24ヶ月分の大量データを長期保管せよ！ 3. 大規模参照の性能を安定化せよ！
- 6. 6Copyright © 2016 NTT DATA Corporation (1)1000万件データを10分以内にロードせよ！ スマートメーター運用管理システムの主要処理 ★ 30分おきに500万件の 指示数を収集 データの 欠測チェック等 最新の 指示数保存 使用量の 保存 使用量の 計算 10分以内 • 毎日、 2億4000万件増加 • 24ヶ月分 (≒1700億件分)保存が必要 500万件 挿入 500万件 挿入 ミッション 2 バッチ等 大規模参照 ミッション 3 ミッション 1
- 7. 7Copyright © 2016 NTT DATA Corporation 格納モデルの選択 データは「機器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は追記型アーキテクチャを採用しているため、 高頻度の更新処理は性能がでにくい。
- 8. 8Copyright © 2016 NTT DATA Corporation 格納モデルの選択 機器 ID 日付時刻 値 1 8/1 0:00 100 1 8/1 0:30 300 1 8/1 1:00 500 … … … ○ レコードの追加(INSERT) が速い。 × テーブルサイズが大きくなる。 方法②：INSERTモデル 機器ID、日時ごとに、レコードをINSERT 方法①：UPDATEモデル 機器 ID 日付 0:00 0:30 1:00 1:30 … 1 8/1 100 300 500 2 8/1 200 400
- 9. 9Copyright © 2016 NTT DATA Corporation 格納モデルの選択 機器 ID 日付時刻 値 1 8/1 0:00 100 1 8/1 0:30 300 1 8/1 1:00 500 … … … ○ レコードの追加(INSERT) が速い。 × テーブルサイズが大きくなる。 方法②：INSERTモデル 機器ID、日時ごとに、レコードをINSERT 方法①：UPDATEモデル 機器 ID 日付 0:00 0:30 1:00 1:30 … 1 8/1 100 300 500 2 8/1 200 400 格納性能重視で採用！
- 10. 10Copyright © 2016 NTT DATA Corporation 高速ロードにおける性能ファクター 何件おきに コミットすべき？多重度の 最適値？ パラメータ？ データ型？ 制約の有無？ インデックス？ バージョン？ 性能ファクターを洗い出して事前検証 パーティションへの ロード方法？
- 11. 11Copyright © 2016 NTT DATA Corporation 高速ロードにおける性能ファクター 多重度 8 wal_buffers 1GB サイズが小さい データ型制約は 最小限 インデックスは 最小限 PostgreSQL 9.4 パーティション子テーブルへ 直接ロード 10000件 コミット DB設計へのフィードバック チューニング時の切り札
- 12. 12Copyright © 2016 NTT DATA Corporation 特に性能改善に寄与した性能ファクター 多重度 8 wal_buffers 1GB サイズが小さい データ型制約は 最小限 インデックスは 最小限 PostgreSQL 9.4 パーティション子テーブルへ 直接ロード 10000件 コミット
- 13. 13Copyright © 2016 NTT DATA Corporation ボトルネックは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バッファ 処理内容の 書込み ・コミットされた ・メモリが一杯になった ★ここを速くしたい
- 14. 14Copyright © 2016 NTT DATA Corporation まずは…wal_buffersパラメータ 「デフォルト設定の-1で選択される自動チュー ニングによると、ほとんどの場合妥当な結果 が得られます。 」 PostgreSQLドキュメントより
- 15. 15Copyright © 2016 NTT DATA Corporation 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の効果
- 16. 16Copyright © 2016 NTT DATA Corporation PostgreSQLバージョン ・WAL性能向上 ・JSONB ・GINインデックス性能向上 ・ロジカル・デコーディング 9.3 9.4 2014年12月リリース
- 17. 17Copyright © 2016 NTT DATA Corporation バージョンアップによる高速化 • 当初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 処理時間 バージョンアップの効果 ※格納時間のみ （参照時間等除く）
- 18. 18Copyright © 2016 NTT DATA Corporation 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 処理時間 格納 その他 改善の効果 目標値 目標達成！！ その他処理（参 照、計算など）は チューニング済み。 ※終局時ピークを想定した試験
- 19. 19Copyright © 2016 NTT DATA Corporation (2) 24ヶ月分の大量データを長期保管せよ！ スマートメーター運用管理システムの主要処理 ★ 30分おきに500万件の 指示数を収集 データの 欠測チェック等 最新の 指示数保存 使用量の 保存 使用量の 計算 10分以内 • 毎日、 2億4000万件増加 • 24ヶ月分 (≒1700億件分)保存が必要 500万件 挿入 500万件 挿入 ミッション 1 バッチ等 大規模参照 ミッション 3 ミッション 2
- 20. 108TB
- 21. 21Copyright © 2016 NTT DATA Corporation データ型を選んでサイズを小さく • 整数 範囲、精度をカバーできる最も小さいデータ型を使う！ • 真偽値 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
- 22. 22Copyright © 2016 NTT DATA Corporation カラムの順番を変えてデータサイズを小さく • アライメント（配置境界） • PostgreSQLはアライメントをまたがってカラムを格納しない 1 2 3 4 5 6 7 8 column_1(4byte) ***PADDING*** column_2(8byte) 8 byteの場合
- 23. Column Type column_1 integer column_2 timestamp without time zone column_3 integer column_4 smallint column_5 timestamp without time zone column_6 smallint column_7 timestamp without time zone 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！
- 24. 24Copyright © 2016 NTT DATA Corporation 格納モデルの変換 項 番 対象データ 参照 頻度 更新 頻度 方針 方式 1 当日 ～65日分 高 高 更新性能重視 INSERTモデル 2 66日 ～24ヶ月分 低 低 参照容易なレベルで ストレージ量削減 UPDATEモデル 挿入時は性能重視でINSERTモデルを選択 • サイズが大きいので、長期保管には向いていない アクセス頻度が低くなる期間からモデルを変換
- 25. 25Copyright © 2016 NTT DATA Corporation 格納モデル変換 機器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
- 26. 26Copyright © 2016 NTT DATA Corporation 改善の効果 108 11 0 20 40 60 80 100 120 前 後 データサイズ（TB) データサイズの縮小
- 27. 27Copyright © 2016 NTT DATA Corporation (3) 大規模参照の性能を安定化せよ！ スマートメーター運用管理システムの主要処理 ★ ミッション 3 30分おきに500万件の 指示数を収集 データの 欠測チェック等 最新の 指示数保存 使用量の 保存 使用量の 計算 10分以内 • 毎日、 2億4000万件増加 • 24ヶ月分 (≒1700億件分)保存が必要 500万件 挿入 500万件 挿入 ミッション 1 ミッション 2 バッチ等 大規模参照
- 28. 28Copyright © 2016 NTT DATA Corporation 大規模参照の性能を安定化せよ！ 本案件では、「安定して性能要件を満たすこと」が大切 • 突然の実行計画の変化による性能劣化は避けたい 実行計画制御 特定のプランを選ばせる pg_hint_plan 統計情報固定化 プランを変更させない pg_dbms_stats 安定稼動
- 29. 29Copyright © 2016 NTT DATA Corporation pg_hint_planとpg_dbms_statsを使用する前に PostgreSQLのプランナはほとんどの場合は正しい実行計画を選ぶ 実行計画を固定すると、むしろ性能問題を引き起こすかもしれない • ある時点で最適な実行計画でも、データの内容/サイズの変化により、 遅い実行計画になりうる それでも、プランナが間違えるリスクを極力ゼロにしなければならない。 →デメリットを理解したうえで採用 • バッチ処理のあと直後のANALYZEが終わるまで • テーブルの結合数が非常に多いケース • …
- 30. 30Copyright © 2016 NTT DATA Corporation pg_dbms_statsによる固定化 プランナ pg_dbms_stats PostgreSQL 本来の 統計情報 実行計画 生成 固定化 “固定化された” 統計情報
- 31. 31Copyright © 2016 NTT DATA Corporation 本プロジェクトのpg_dbms_stats使いこなし 指示数 データ 日テーブル 固定 統計情報 日テーブル 固定 統計情報 日テーブル 固定 統計情報 日パーティション 新しいパーティション子テーブルの追加と同 時に準備された固定統計情報をセット コピー 一部の統計情報はテーブルによって異なる ANALYZEをしなくても、 テーブル作成直後から すぐに最適なプランが得られる • テーブルOID、テーブル名 • パーティションキー、時刻
- 32. 32Copyright © 2016 NTT DATA Corporation テーブルによって変わるべき統計情報の付け替え • 値は想定可能なので、ダミーデータを作成。 • ダミーデータをANALYZEした結果をセット 格納された値を元にした統計情報 最頻値・頻度 ヒストグラム たとえば、”8/1 0:00” “8/1 0:30” “8/1 1:00” など。 1日で48種類。分布は一様になる。 子テーブルによって格納される値が 大きく違うカラム パーティションキー 時刻
- 33. 33Copyright © 2016 NTT DATA Corporation ミッション 1. 1000万件データを10分以内にロードせよ！ 2. 24ヶ月分の大量データを長期保管せよ！ 3. 大規模参照の性能を安定化せよ！ COMPLETE
- 34. 34Copyright © 2016 NTT DATA Corporation まとめ 2016年、PostgreSQL20周年 PostgreSQLはついに大規模社会インフラに採用されるまでとなりました。 しかし巨大なサイズ、厳しい性能要件を持った高難易度のシステムには、 PostgreSQLのノウハウに加え、業務特性も活かした工夫が必要です。 システムの成功のために、徹底した事前検証とノウハウで PostgreSQLのポテンシャルを引き出しましょう！
- 35. Copyright © 2011 NTT DATA Corporation Copyright © 2016 NTT DATA Corporation