■2-05■ データ管理
ここでは、PostgreSQLが論理的にどのようなデータ管理を行っているか、解説します。
追記型
PostgreSQL は追記型のデータ管理(no overwrite storage manager)を行っています。
追記型とは、データの挿入(INSERT)だけでなく更新(UPDATE)のときも、古いデータを無効にするだけで実際のデータ更新は行わず、新たにデータを追加するデータ管理方法です。【図.2-5】を使って簡単に追記型の解説を行います。
データベースクラスタ内において、テーブルデータの各行にはOID(オブジェクトID)とXID(トランザクションID)が割り当てられます。XIDはトランザクションを管理するための内部コードです。挿入や更新が行われた場合、新たに行が追加されてXIDが更新されます。
図.2-5 追記型
追記型の利点は、トランザクションに関する処理を非常に簡単に実装できることです。一方、欠点は物理的なデータ領域を次々に消費してしまうことです。
よって、不要となったデータ領域をOSに返す(開放する)、再利用するなどの対処が不可欠です。
PostgreSQLのデータ管理
バージョン7.1までのデータ管理
バージョン7.1 までは単純な追記型が実装されていたので、VACUUM 文やvacuumdbコマンドを実行して、対象とするテーブルに排他ロックをかけ、他のデータ操作を完全にブロックした状態でデータ領域を開放していました。テーブルの排他ロックは優先順位が一番高いロックですので、VACUUM文やvacuumdbコマンドが実行されている間は、他の一切の操作を行うことができません。不幸なことに、データ領域の開放は比較的時間のかかる処理です。
運用上必要とはいえ、定期的にテーブルが排他ロックされてアクセスできない時間帯が生じるのは大きな欠点であり、PostgreSQLの適用範囲を大幅に狭めていました。
バージョン7.2からのデータ管理
バージョン7.1までの欠点を改善するために、無効となったデータ領域を再利用する方式が提案され、バージョン7.2でこの方式を実現する並行VACUUM(Concurrent VACUUM)機構が実装されました。これに伴いVACUUM 文とvacuumdb コマンドは、無効となったデータ領域を回収する(FSMに不要領域を記録して再利用に備える)ように機能が改変されました(【図.2-7】(1)参照)。
データ領域の回収は、対象となるテーブルの読み取り権限しか必要としませんので、他の処理(検索、挿入、削除、更新)と並行して実行することができます。
これにより、追記型の欠点である物理的なデータ領域の消費を抑制し、かつデータベースを稼働させたままデータ領域の回収が可能となりました(【図.2-6】)。
図.2-6 データ管理方法の違い
バージョン7.2からのデータ領域の開放
PostgreSQLによって確保されているデータ領域のうち、不要になった部分を開放してOS に返す(ハードディスクの空き領域を増やす)には、“vacuumdb -f”コマンドかVACUUM FULL文を実行します。これはバージョン7.1までのVACUUM文の処理です。この場合はテーブルが排他ロックされ、他の操作がすべてブロックされます(【図.2-7】参照)。図.2-7 不要なデータ領域の回収と開放
【表.2-1】に不要なデータ領域の対処についてまとめます。
| 対処 | 機能 | 特徴 | バージョン7.1以前 | バージョン7.2以降 |
| 回収 | 再利用するため、 FSMに不要領域を記録 | 対象テーブルをロックしない。 | 未実装 | VACUUM文 |
| 開放 | OSにデータ領域を返却 | 対象テーブルを排他的ロック。 他のすべての操作をブロック | VACUUM文 | VACUUM FULL文 |
MVCC (多版型同時実行制御)
追記型のデータ管理を行うことで、同時実行制御機構(複数のトランザクション同時処理におけるデータの一貫性を保持する機構)の実現も容易になります。OIDとXIDを参照することで、任意の時点に遡ってテーブルのスナップショットを得ることができるからです。
PostgreSQL は追記型のデータ管理の利点を生かし、MVCC(Multi Version Concurrency Control：多版型同時実行制御)という方式でその機構を実現しています。
MVCCの特徴は問い合わせ(読み込み)ロックの獲得と、書き込みロックの獲得が競合しないことです(読み込みは書き込みをブロックしませんし、書き込みも読み込みをブロックしません)。
[PREVIOUS][UP][NEXT]