更新：2021/07
前回、【第1回】基本から始める Azure Database for PostgreSQL 【PostgreSQL アーキテクチャ 1】で、PostgreSQL の主要プロセス、接続確立までの流れなどについてまとめてみました。
今回は、ファイルシステム、メモリアーキテクチャ、追記型アーキテクチャ などの内容について、自分の整理も兼ねて、まとめてみようと思います。
※ PostgreSQL (オンプレミス) は、Azure Database for PostgreSQLで選択可能なバージョン「11」を使用しています。
PostgreSQL の アーキテクチャ 2
PostgreSQLのファイルシステム
- initdb コマンドを実行することでディスク上に各種データ格納領域を用意し、データファイル、WAL (トランザクションログ)、設定ファイルが作成される。
- initdb コマンドで作成される単位は データベース クラスタ と呼ばれる。
- データベース クラスタには 複数のデータベース が含まれる。
- データベース クラスタとインスタンスは 1:1 の関係となっている。
※ PostgreSQLの データベース クラスタ は、SQL Server で言えば インスタンス みたいなものでしょうか。
■ データベース クラスタ (ファイルの構造)
データベース クラスタ を作成後、以下のようなファイル構造でデータファイルなどが作成／配置されます。
- SQL Server では、データベース物理ファイル (.mdf/.ndf) の中にすべてのオブジェクト (テーブルなど) が含まれるが、PostgreSQLでは、テーブル毎にデータファイルが作成される。
- データページのサイズは、SQL Server と同じく 8KB。
- SQL Serverと同様に、１インスタンス (データベース クラスタ) に複数のデータベースを保持する。
- base フォルダ配下に データベースID (OID) フォルダが作成され、その配下にテールファイルが配置される。
- テーブルファイルは、データが増えると ファイルノード番号(OID).N (1247, 1247.1, 1247.2 など) のファイルが増えていく。(既定: 1GB 毎にファイルが分割れる。)
data
├──base (実データの格納領域)
│ ├──1
│ └──16393
├ ・・・
├──log (ログ情報の格納領域)
│ └──postgresql-2020-07-28_173940.log
├──pg_wal (トランザクションログの格納領域)
├ ・・・
└──postgresql.conf (設定ファイル)
[その他フォルダ／ファイル]
- PG_VERSION : PostgreSQLのバージョン番号を保有するファイル
- global : データベース クラスタで共有するテーブルを保有するサブディレクトリ
- postgresql.conf : パラメータ設定ファイル (SQL Server で言えば サーバー構成オプションのようなもの)
- postmaster.opts : 最後にデータベースを起動した際のコマンドラインオプションを保持するファイル
- postmaster.pid : 現在の postmaster プロセス ID、データベース クラスタのデータ ディレクトリパス情報、postmaster プロセス起動時のタイムスタンプ、リッスンされたポート番号 (TCP) などの情報を保持するファイル
[postgresql.conf]
※一部抜粋
PostgreSQLのメモリシステム
PostgreSQLのメモリシステム アーキテクチャをまとめてみます。
SQL Server は、一つのプロセス内で多数のスレッドが動作するマルチスレッド アプリケーションとなり、スレッド間でメモリを共有する動作が行われますが、PostgreSQL は複数プロセスが起動する実装になっているので、プロセス間でメモリを共有するアーキテクチャになっているもようです。
■ グローバル メモリ
PostgreSQLの全プロセスが共有するメモリ
・PostgreSQL (マスタプロセス) により確保／解放される。
・OSの共有メモリ空間内に確保される。
・PostgreSQLの全プロセスで共有するデータ (テーブルデータなど) がキャッシュされる。
■ 各プロセス単位で確保するメモリ
・各プロセスの生成／終了のタイミングで確保／解放される。
・個々の処理 (ソート処理など) などに使用される。
各種メモリオブジェクトについて、SQL Server／Oracle と対比する形でまとめてみようと思います。
[補足]
SQL Server では、ソート処理、ハッシュ結合処理がメモリの範囲内で行えない場合、代わりに tempdb が使用されることになる。
PostgreSQLのチェックポイント
共有バッファ上の変更されたデータについては、データの更新とは非同期にある程度の間隔でディスクへの書き込みが実施されます。この処理のことを チェックポイント と呼ばれています。
チェックポイントは、特定の間隔、WALファイルの量によって自動的に実施される動作になります。
SQL Server でも同様に チェックポイント処理が実装されており、同様の動作が行われています。
■ チェックポイントに関連するパラメータ
設定ファイルのパラメータの内容については、以下の URL を参照。
その他 アーキテクチャ
■ WAL
WAL (Write Ahead Log) は、SQL Server で言えば トランザクション ログと類似のアーキテクチャであり、クラッシュ時、最後のチェックポイント以降に蓄積されたWALからリカバリ処理を実施するために使用されています。
■ 追記型アーキテクチャ
更新／削除時、変更前のタプル(行)を残したまま、新規に変更後のタプルを追加するというアーキテクチャとなります。
※ SQL Server/Oracle は「更新型アーキテクチャ」で変更対象のデータに対してロックを獲得し、更新するという アーキテクチャ が採用されています。
◆メリット
- 更新時にロックを必要としないため、ロック競合(ブロッキング)が発生しにくい。
- 更新前、削除対象のタプルが残っているため、ロールバック処理が容易。
- UNDOセグメント管理が不要
◆デメリット
- 不要となったタプルを削除するため、VACUUM処理を実施する必要がある。
※ 追加型アーキテクチャの場合、上記の更新クエリを実行した場合、更新後の新しいデータがテーブルに追記され、更新前のデータは不要タプルとしてテーブルに保持されます。
■ VACUUM
更新によって不要となったタプルを回収して、再利⽤可能にする操作となり、VACUUMにより、テーブルの肥大化を防ぐことが可能となります。
SQL Server でも ゴースト クリーンナップ (Ghost Creanup) 処理があり、削除したデータは 一旦 ゴースト レコードとして保持され、ゴースト クリーンナップ処理にて VACUUM のような動作 (再利用可能な状態に変更) が行われますが、PostgreSQL では 挿入操作 (Insert) でも不要タプルが増えていくため、処理しなければならないデータ量は必然的に増えることが想定されます。
※ VACCUM を実行後、不要タプルが解放され、再利用可能な状態になる。更新／削除が頻繁に行われるテーブルに対して VACUUMを実行しなければ、不要なタプルが増加し、テーブルが肥大化する要因になります。
[まとめ]
今回は、Azure Database for PostgreSQL を理解するうえで、PostgreSQLの ファイルシステム、メモリアーキテクチャ、追記型アーキテクチャ などについてまとめてみました。
次回は、PostgreSQLの ユーザーアカウント、バックアップ、テーブル メンテナンスの方法などについて、まとめてみようと思います。
【第3回】基本から始める Azure Database for PostgreSQL 【PostgreSQL アーキテクチャ 3】へ