PostgreSQLアーキテクチャ入門

PostgreSQLアーキテクチャ入門

アップタイム・テクノロジーズ合同会社

永安悟史

2011.2.25

Copyright 2011 Uptime Technologies LLC, All rights reserved. 1

アジェンダ
• アーキテクチャ概要 • パフォーマンス管理
– PostgreSQLの構成要素 – パフォーマンスは何で決まるか？
– PostgreSQLの基本的なアーキテクチャ – パフォーマンス改善の基本手順
– プロセス – SQLパフォーマンス分析
– ファイル
– 発生する3種類のI/O • 可用性管理
– メモリ – バックアップ
– コールドバックアップ
• クエリの処理 – ホットバックアップ
– SQL文の処理される流れ – アーカイブログとPITRを用いたバックアップ
– クエリとクエリプラン – アーカイブログとPITRを用いたリカバリ
– クエリプランの詳細 – 冗長化方式の選定
– クエリプランの確認方法
– データアクセスのパターン
– テーブルスキャン
– インデックスアクセス
– 結合

• I/O処理の詳細
– テーブルに対する更新処理
– タプルの更新とインデックスの更新
– VACUUM処理
– トランザクションロギング
※本資料の最新版は以下に掲載されています。
http://www.uptime.jp/
（ホーム→リソース→技術情報）


PostgreSQLの構成要素
PostgreSQLは、さまざまなプロセス・メモリ領域・ファイル
によって構成されている。

writer
postmaster logger wal writer autovacuum
（バックグラウンド
（リスナプロセス）（サーバログ）（WALライタ）（自動vacuum）
ライタ）
プロセス群
archiver stat collector postgres wal sender wal receiver
（WALアーカイバ）（統計情報収集）（サーバプロセス）（レプリケーション）（レプリケーション）

shared_buffers wal_buffers freespacemap トランザクション
メモリ群（共有バッファ）（WALバッファ）（空き領域情報）制御情報

ファイル群テーブルインデックストランザクションアーカイブ
設定ファイル
ファイルファイルログファイルログファイル


PostgreSQLの基本的なアーキテクチャ
共有バッファを中心として、複数のプロセス間で連携し
ながら処理を行うマルチプロセス構造。

postmaster
（リスナプロセス）

（

shared_buffers
postgres 共
postgres 有
（サーバプロセス）バ
postgres
（サーバプロセス）
クライアントッ
（サーバプロセス）フ
ァ
）
writer
（バックグラウンド
ライタ）

トランザクション
ログファイル
テーブル
ファイル

インデックス
ファイル


プロセス
• Postmasterプロセス
– PostgreSQLを起動すると最初に開始されるプロセス。
– クライアントからの接続を受け付け、認証処理を行う。
– 認証されたクライアントに対して、Postgresプロセスを生成（fork)して処理
を引き渡す。

• Postgresプロセス
– クライアントに対して1対1で存在する。
– クライアントからSQL文を受け付け、構文解析、最適化、実行、結果返却
を行う。
– 共有バッファを介してデータを読み書きし、トランザクションログを書く。

• Writerプロセス
– 共有バッファの内容をディスク（テーブルファイル、インデックスファイル）
に非同期的に書き戻す。


テーブルファイル
• 8kB単位のブロック単位で管理
• ブロックの中に実データのレコード（タプル）を配置
– 基本的に追記のみ
– 削除したら削除マーク（VACUUMで回収）
– 更新時は「削除＋追記」
DBT1=# SELECT * FROM
pgstattuple('customer');
-[ RECORD 1 ]------+-----------
レコード１ table_len | 1754857472
レコード２ブロック１ tuple_count | 3456656
レコード３
tuple_len | 1703225491
レコード４ tuple_percent | 97.06
レコード５ブロック２ dead_tuple_count | 695
dead_tuple_len | 350038
dead_tuple_percent | 0.02
free_space | 31391624
ブロック３
free_percent | 1.79

DBT1=#


トランザクションログ
• テーブルやインデックスの更新情報が記録（追記）される
– 共有バッファのデータを更新する「前」に記録（Write-ahead）
– 16MBずつのセグメント（ファイル）に分割されている。
– リカバリの際に読み込まれる（pg_xlog/ 以下に配置）

WAL 1 WAL 2

Aテーブルのレコード1をmに変更
Bテーブルのレコード6をnに変更
Aテーブルのレコード4をxに変更
Aテーブルのレコード1をyに変更
Bテーブルのレコード2をzに変更

ファイルの先頭から
順番に更新情報が
追記されていく


発生する3種類のI/O
• 例えば、主キーで検索して該当レコードを更新する場合
– プライマリーキーでインデックスエントリを探す
– インデックスのポインタを元に、テーブル内のレコードを探す
– テーブルレコードを更新する前にトランザクションログに記録する
– テーブルファイルを更新する

物理ディスク
テーブルファイル ②読む
④書く
ディスク
ヘッド
①読む
インデックスファイル

③書く
ログファイル


メモリ（共有バッファ）
• ディスク上のブロックをキャッシュするメモリ領域
– ディスク上のブロックのうち、アクセスするものだけを読み込む
– すべてのバックエンドプロセスで共有
• キャッシュすることで、ディスクI/Oを抑えて高速化
– 更新の永続性はトランザクションログで担保する

postgres
9 17 5 14
postgres

postgres 共有バッファ 1 2 3 4 5 6
7 8 9 10 11 12
バックエンド 13 14 15 16 17 18
19 ・・・・
ログファイル
テーブル／インデックスファイル


SQL文の処理される流れ
クエリ受信

•SQL構文の解析、文法エラーの検出
構文解析（parse） •構文木（parse tree）の生成

•VIEW / RULE に基づいた構文木の書き換え
書き換え（rewrite）

実行計画生成 / 最適化 •最適なクエリプラン（実行計画）の生成
（plan / optimize） •統計情報などを用いて実行コストを最小化
（コストベース最適化）

•クエリプランに沿ったデータアクセス、抽出／結合／
実行（execute）並べ替えなどの演算処理
•（更新時）トランザクションログ追記、共有バッファ更新

結果送信

クエリとクエリプラン

ネステッドループ
ジョイン

テーブル
スキャン

集約 count()

インデックス
スキャン


クエリプランの詳細


クエリプランの確認方法
• EXPLAINコマンド
– 最適であると判断された「実行計画」を表示。
– 入力されたSQL文を、PostgreSQLがどのように解釈して処理しよう
としているのかを表示。

• EXPLAIN ANALYZEコマンド
– 「実行結果」を表示。
– 実際に、どのアクセスにどの程度の時間がかかっているのか、何件
のレコードを処理したのか、などを表示。

• その他（pgAdminIII）
– 「クエリー解釈」、「アナライズ解釈」は、EXPLAIN、EXPLAIN
ANALYZEと同等。


データアクセスのパターン
• シーケンシャルアクセス
– 全レコード、または多くのレコードを処理する必要がある場合
– 集約処理、LIKE文の中間一致など
• ランダムアクセス
– 特定のレコード（を含むブロック）だけにアクセスする必要がある場合
– 主にインデックスを用いたアクセス

シーケンシャルランダム
アクセスアクセス

ファイルの先頭から
順番に読み込んでいく必要なブロックだけ
ピンポイントで読み込む

テーブルファイルテーブルファイル


テーブルスキャン
SELECT count(*) FROM customer;
Customer
テーブルからの
ブロック読込
×214,216

Customer_pkey
インデックスの
ブロック読込×0


テーブルスキャン cont’d
• すべてのデータを確認する必要があるため、customerテー
ブルファイルを構成するブロックを先頭から読み込む
– よって、データが増えれば増えるほど時間がかかるようになる。
– この例では、214,216 ブロック（約1.7GB）を読んでいる。

Customer_pkeyインデックス Customerテーブル

レコード１
root レコード２
レコード３

レコード４
レコード５

1～5 6～10 11～17 18～25


インデックスアクセス
SELECT * FROM customer c WHERE c.c_id=7;
Customer
テーブルからの
ブロック読込×１

Customer_pkey
インデックスの
ブロック読込×３


インデックスアクセス cont’d
• “c_id=7” レコードの位置を探すため、customer_pkeyを辿っ
てポインタを見つけ、レコードを含むテーブルファイルのブ
ロックを読み込む。
– この例では、customer_pkeyインデックスから3ブロック、customer
テーブルから1ブロックを読んでいる。
– レコードの量とディスクアクセス量が比例しない。
Customer_pkeyインデックス Customerテーブル

レコード１
root レコード２
レコード３

レコード４
レコード５

1～5 6～10 11～17 18～25


結合（Nested Loop Join）
• SELECT count(*) FROM orders o, customer c
WHERE o.o_c_id=c.c_id AND c.c_uname=‘UL’;
– customer を c_uname=‘UL’ でインデックススキャン
– customer のレコードの c_id を使って orders をインデックススキャン

i_c_uname customer i_o_c_id orders


テーブルに対する更新処理
レコード1 「レコード5」を追加レコード1
レコードレコード2 レコード2
追加処理レコード3 レコード3
レコード4 レコード4
（INSERT）レコード5
ファイル中に4件のレコードが
順番に並んでいるレコード5がファイル末尾に追加され、
ファイルサイズが増える

「レコード2」を削除
レコードレコード2 （レコード2）
削除処理レコード3 レコード3
（DELETE）
ファイル中に4件のレコードがレコード2に削除マークが付けられる
順番に並んでいる

「レコード2」を
レコード1 「レコード2’」として更新レコード1
レコードレコード2 （レコード2）
更新処理レコード3 レコード3
（UPDATE）
レコード2’
ファイル中に4件のレコードがレコード2に削除マークが付けられ、
順番に並んでいるレコード2’が新たに追加、ファイルサイズ増加

タプルの更新とインデックスの更新
8.2以前
インデックス付きカラム

ヒープタプルレコード1 レコード1
インデックスのない
（テーブル）レコード2 カラムを更新すると・・・ (レコード2)
レコード2’

エントリ1 エントリ1 インデックスサイズも
インデックス
エントリ2 (エントリ2) 増える
エントリ2’

8.3以降インデックス付きカラム

ヒープタプルレコード1 レコード1
（テーブル）インデックスのない
レコード2 カラムを更新すると・・・
(レコード2)
レコード2’

エントリ1 エントリ1 インデックスサイズは
インデックス
エントリ2 エントリ2 増えない

インデックスの張られていないカラムを更新すると、
ヒープのみの（インデックスエントリが無い）カラムができる。

これが、HOT（Heap Only Tuple）

VACUUM処理
VACUUM前 VACUUM後
（レコード2）
VACUUM処理
空き領域
VACUUM レコード3 レコード3
処理レコード4 レコード4
レコード2’ レコード2’
レコード2に削除マークがレコード2の領域が「空き領域」として
付いている再利用可能になる。

追記前追記後
レコード1 レコード5を追記レコード1
空き領域レコード5
してあるとレコード4 レコード4
「空き領域」があるファイルサイズを変えずに追記できる

レコード5を追記
(レコード2） (レコード2)
してないとレコード4 レコード4
レコード2の領域が埋まったままレコード5
ファイルサイズが増加

パフォーマンスは何で決まるか？
• 「単一クエリのレスポンス×クエリの同時実行数」
– 単一クエリのレスポンス
• サーバ・クライアント間通信（ネットワーク）
• SQLの構文解析、最適化（CPU処理）
• ロックの競合（ロック待ち、デッドロックの発生）
• テーブル、インデックス、ログへのI/O量（ディスクI/O）
• ソート、結合などの演算処理（CPU処理）
– クエリの同時実行数
• 接続クライアント数（いわゆるWebユーザ）
• コネクションプール接続数

• これらが全体としてハードウェアのキャパシティの範囲内で
ある必要がある。
– ネットワーク、ディスクI/O、メモリ、CPUなどがボトルネックとなり得る。
– ただし、サーバリソースネック自体は「結果」であり、「原因」ではない。
– 「なぜ、それがボトルネックになっているのか？」が重要。

パフォーマンス改善の基本手順
• 遅いSQL文を特定する or 実行回数の多いSQLを特定する
– log_min_durationオプション
– pgFouine

• SQLの実行プランを確認する
– EXPLAIN / EXPLAIN ANALYZE

• 対策をする
– SQL文を書き換える、インデックスを張る、テーブル設計を修正する
– アプリケーションを修正する
– ハードウェアを増強する
– 他・・・


SQLパフォーマンス分析
• pgFouineによる問題SQL文の抽出
– 総実行時間＝レスポンスタイム（実行時間）×実行回数
– 最長レスポンスタイム
– 他・・・


バックアップ
• バックアップの難しさ
– データはファイルの中にだけあるのではない！
– 通常は、共有バッファの内容が最新
– ファイルだけバックアップを取ってもダメ
– ミリ秒単位で処理が進む中、すべてを一貫性を保った状態で

• バックアップの種類
– コールドバックアップ
– ホットバックアップ
– アーカイブログバックアップ

• バックアップ＆リカバリはリハーサルをしよう！
– 簡単な試験や手順書を作るだけで満足してはいけない・・・


コールドバックアップ
• サーバプロセスをすべてシャットダウンしてデータファイル全体をバック
アップ
– バックアップの間、サービス停止が発生する。
– リカバリの際には、バックアップ時のデータに戻る。
• 利用ケース
– 前回バックアップ以降の更新データを復旧できる場合。
– ストレージスナップショットが一般化した今、案外現実的。

Crash

①ファイルを WAL1 WAL2 WAL3
②障害発生
バックアップ
（サービス中断）
③レストア

Index
Table


ホットバックアップ（pg_dump）
• あるタイミングでデータの一貫性を保ちつつバックアップ
– シンプルかつ柔軟（テーブル単位のバックアップも可）
– バックアップ時にサービス停止は起こらない。
– リカバリの際には、バックアップ時のデータに戻る。
• 利用ケース
– 前回バックアップ以降の更新データを復旧できる場合。
– データベース単位、テーブル単位でバックアップを取りたい場合。
– 論理バックアップが必要な場合（メジャーバージョンアップなど）

Crash
WAL1 WAL2 WAL3
①pg_dumpで ②障害発生
スナップショットを
バックアップ
③レストア

Index
Table


アーカイブログとPITRを用いたバックアップ
• ベースバックアップ（基準点）＋アーカイブログ（更新差分）
– サービスを継続したままベースバックアップを取得可能
– クラッシュ直前のWALの内容まで復旧することが可能
• 利用ケース
– データベースクラスタ全体の完全なバックアップを取りたい場合。
– クラッシュ直前の更新まで復旧させる必要がある場合。

Crash
WAL1 WAL2 WAL3

①ベースバック
アップの取得 ②WAL1を ③WAL2を ④WAL3を
アーカイブアーカイブアーカイブ

Index
WAL1 WAL2 WAL3
Table
PITRに必要なファイル類


アーカイブログとPITRを用いたリカバリ
• ベースバックアップ（基準点）＋アーカイブログ（更新差分）
– 前回のベースバックアップ以降、長期間が経過しているとアーカイブログが
多くなり、リカバリの時間が長くなる。
– ベースバックアップレストア時間＋アーカイブログ適用時間×アーカイブログ
数
WAL3適用完了
リカバリ完了

WAL1 WAL2 WAL3

①ベースバック
アップを展開 ②WAL1を ③WAL2を ④WAL3を
適用適用適用

Index
WAL1 WAL2 WAL3
Table


冗長化方式の選定
• 実現方式を評価するに当たって特に重視すべき点
– 負荷分散の必要性の有無。
– 単一障害点（Single Point of Failure、SPoF）の有無。
– 運用が容易であるかどうか（運用の作業負荷、ノウハウの蓄積）。
– データ一貫性の厳密性（レプリケーション遅延）の程度。

実現方式アーキテクチャ負荷分散同期遅延運用性備考
アーカイブログ転送アクティブ／スタンバイ × 数十秒 ◎ ウォームスタンバイ方式。
～数分
DRBDディスク同期アクティブ／スタンバイ × なし △ 要DRBD運用ノウハウ。
共有ディスク方式アクティブ／スタンバイ × なし △ 共有ディスクが高価でSPOF。
Slony-Iレプリケーアクティブ／アクティブ、 ○ 数秒 △ 公開されているSlony-Iの運用ノウハ
ションマスター／スレーブウが少ない。バージョン混在可。
pgpool-II アクティブ／アクティブ、 ○ なし ○ pgpoolサーバがSPOF（冗長化可）。
マスター／スレーブ一部、APへの影響有り（now()等）。
ストリーミング・レプリアクティブ／アクティブ、 ○ 数百ms △ 公開されている運用ノウハウが少な
ケーション（9.0～）マスター／スレーブい。


冗長化方式の選定 cont’d
• PostgreSQLの代表的な冗長化方式の構成は以下の通り。
– シンプルな冗長化のみで良い場合は共有ディスク方式。
– スケールアウトが必要な場合は pgpool か Slony-I。
– 9.0以降はストリーミングレプリケーション（SR+HS）構成が可能。
共有ディスク方式 pgpool方式 SR+HS方式

Web/APサーバ Web/APサーバ
Web/APサーバ Web/APサーバ Web/APサーバ Web/APサーバ

読み書き読み込み可
不可

pgpoolサーバ
マスタDB スレーブDB
SQL転送

ログ（レコード）転送

共有ストレージ


参考文献
• 書籍・雑誌
– WEB+DB PRESS vol.32～37 「PostgreSQL安定運用のコツ」（技術評論社）
– データベースパフォーマンスアップの教科書基本原理編（翔泳社）

• オンラインドキュメント類
– PostgreSQL 9.0.2文書
http://www.postgresql.jp/document/pg902doc/html/index.html
– Explaining Explain ～ PostgreSQLの実行計画を読む～ (PDF版)
http://lets.postgresql.jp/documents/technical/query_tuning/explaining_explain_ja.pdf
– HOTの仕組み (1) - Let's Postgres
http://lets.postgresql.jp/documents/tutorial/hot_2/
– ソーシャルゲームのためのデータベース設計
http://www.slideshare.net/matsunobu/ss-6584540


PostgreSQLアーキテクチャ入門

Recommended

More Related Content

What's hot (20)

Similar to PostgreSQLアーキテクチャ入門 (20)

More from Uptime Technologies LLC (JP) (8)

PostgreSQLアーキテクチャ入門