バキューム・VACUUM ばきゅーむ
PostgreSQLMVCC不要データ回収autovacuum統計情報トランザクションID
バキューム・VACUUMについて教えて
簡単に言うとこんな感じ！
VACUUMは「PostgreSQLの定期掃除機」だよ！ MVCCの仕組みで更新・削除されたデータの「ゴミ（デッドタプル）」がディスクに溜まり続けるから、それを定期的に掃除してスペースを取り戻す必要があるんだ。普段は自動でやってくれるけど、存在を知らないとDBが肥大化して困るってこと！
バキューム・VACUUMとは
VACUUMとは、PostgreSQLが不要になったデータ（デッドタプル）を回収し、ディスク領域を再利用可能な状態にする保守コマンドです。“vacuum”（掃除機）の名の通り、DBのゴミを吸い取る役割を持ちます。
PostgreSQLのMVCC（多版型同時実行制御）では、UPDATE・DELETEを行っても古いデータをすぐ物理削除しません。古いバージョンを参照しているトランザクションがいるかもしれないためです。この不要になった古いデータをデッドタプル（dead tuple）と呼び、VACUUMが回収するまでディスクに残り続けます。
また、PostgreSQLにはトランザクションID（XID）が32ビットの整数で管理されており、約20億回のトランザクション後に「XIDラップアラウンド」という問題が発生する可能性があります。VACUUMはこの問題も防ぐ役割を担っています。
通常はautovacuumデーモンが自動的にVACUUMを実行しますが、大量のデータ更新後や本番障害の際には手動実行が必要になるケースもあります。
VACUUMの種類と動作
| コマンド | 動作 | 特徴 |
|---|---|---|
| VACUUM | デッドタプルを回収し、再利用可能とする | テーブルはロックされず通常操作可能。領域はOS に返却されない |
| VACUUM FULL | テーブルを完全に書き直してディスクを圧縮 | テーブル全体をロック。実ディスク領域をOSに返却できる |
| VACUUM ANALYZE | VACUUMに加え、統計情報（ANALYZE）も更新 | クエリオプティマイザが最新の統計を使える |
| ANALYZE | 統計情報のみ更新。デッドタプル回収は行わない | 実行計画が改善されることが多い |
autovacuumの設定（postgresql.confの主なパラメータ）
| パラメータ | デフォルト | 説明 |
|---|---|---|
autovacuum | on | autovacuumの有効/無効 |
autovacuum_vacuum_threshold | 50行 | VACUUM開始の最低デッドタプル行数 |
autovacuum_vacuum_scale_factor | 0.2（20%） | テーブル行数の何%のデッドタプルでVACUUM開始 |
autovacuum_analyze_threshold | 50行 | ANALYZE開始の最低変更行数 |
歴史と背景
- 1996年：PostgreSQL 6.0 で MVCC が実装される。デッドタプル問題が発生し VACUUM コマンドが導入
- 2005年：PostgreSQL 8.1 で autovacuum がデフォルトで有効に。それ以前は DBA が手動でスケジュールを組む必要があった
- 2012年：PostgreSQL 9.2 で VACUUM FULL のパフォーマンス改善・可視性マップの改善
- 現在：クラウドマネージドDB（RDS for PostgreSQL等）はautovacuumをデフォルトで適切に設定しているが、大量更新のあるテーブルでは個別チューニングが推奨される
関連する規格・RFC
| 規格 | 内容 |
|---|---|
| PostgreSQL VACUUM仕様 | PostgreSQL固有の機能（Oracle・MySQLには同様の手動コマンドなし） |
関連用語
- MVCC — デッドタプルを生み出す並行処理技術。VACUUMが必要な根本原因
- クエリ最適化・実行計画 — VACUUM ANALYZEで統計情報を更新し実行計画の精度を上げる
- トランザクション — 一連のDB操作をひとまとめに扱う仕組み
- インデックス — VACUUMによってインデックスの肥大化も抑制される
- バックアップ・リストア — DBのデータを保護・復元する仕組み
- ポイントインタイムリカバリ — 障害発生時に任意の時点のDB状態に復元する技術
- パーティショニング — テーブルを分割してVACUUMの対象を小さくする最適化にも有効