タイトルを１～２行で入力（長文の場合はフォントサイズを縮小）

Size: px

Start display at page:

Download "タイトルを１～２行で入力（長文の場合はフォントサイズを縮小）"

ゆゆことべ
5 years ago
Views:

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

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

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

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

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

8 8 格納モデルの選択方法 1:UPDATE モデル機器 ID 日付 0:00 0:30 1:00 1:30 1 8/ / 方法 2:INSERT モデル機器 ID 日時ごとにレコードを INSERT 機器 ID 日付時刻値 1 8/1 0: /1 0: /1 1: レコードの追加 (INSERT) が速いテーブルサイズが大きくなる

9 9 格納モデルの選択方法 1:UPDATE モデル機器 ID 日付 0:00 0:30 1:00 1:30 1 8/ / 格納性能重視で採用! 方法 2:INSERT モデル機器 ID 日時ごとにレコードを INSERT 機器 ID 日付時刻値 1 8/1 0: /1 0: /1 1: レコードの追加 (INSERT) が速いテーブルサイズが大きくなる

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

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

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

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

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

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

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

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

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

20 108TB

21 21 データ型を選んでサイズを小さく整数範囲精度をカバーできる最も小さいデータ型を使う! 型精度サイズ 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) ではなくフラグを使う! 型表現可能なデータサイズ CHAR(1) 文字列長 1の文字列 5 byte BOOLEAN 真または偽の状態 1 byte

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

23 column_6 column_1 ***PADDING*** column_2 column_3 column_4 *PADDING* column_5 ********PADDING********* column_ column_2 column_5 column_7 column_1 column_3 column_4 column_6 Column column_1 column_2 column_3 column_4 column_5 column_6 column_7 Type integer timestamp without time zone integer smallint timestamp without time zone smallint timestamp without time zone 1 行あたり 12byte 節約すると一日あたり 2.8GB!

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

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

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

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

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

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

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

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

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

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

intra-mart Accel Platform — TableMaintenance ユーザ操作ガイド第7版 None

intra-mart Accel Platform — TableMaintenance ユーザ操作ガイド第7版 None クイック検索検索目次 Copyright 2012 NTT DATA INTRAMART CORPORATION 1 Top 目次改訂情報概要レコードの追加 / 更新 / 削除レコードの編集レコードを削除するレコードの一括インポートとエクスポート日本語のキャプション表示 2 改訂情報変更年月日変更内容 2012-10-01 初版 2013-10-01 第 2 版下記が追加変更されました対応するフィールドの型

タイトルを１～２行で入力 （長文の場合はフォントサイズを縮小）

タイトルを１～２行で入力（長文の場合はフォントサイズを縮小）