【実務・中級編】 VACUUMの基本動作 – PostgreSQL

PostgreSQLのVACUUM、その「裏側」と「実践」を語ろうぜ！

やあ、みんな！いつもブログを読んでくれてありがとう。今日は、PostgreSQLの心臓部とも言える、ちょっと奥深い「VACUUM」について、教科書じゃ語り尽くせないような、現場で本当に役立つ話をしようと思うんだ。

「VACUUM」って聞くと、なんか「お掃除コマンド」みたいなイメージがあるかもしれないけど、実はこれ、PostgreSQLのパフォーマンスと安定性を維持するために、めちゃくちゃ重要な役割を担ってるんだ。特に、更新や削除が頻繁に発生するシステムでは、VACUUMのことを理解していないと、いつの間にかパフォーマンスがガタ落ち…なんてことにもなりかねない。

だから今日は、VACUUMの「基本動作」を、君たちが現場で「なるほど！」って思えるように、具体例を交えながら、じっくり解説していくぜ！

まずはここから！ VACUUMって、一体何をしているのか？

PostgreSQLは、MVCC（Multi-Version Concurrency Control）っていう仕組みで、複数のユーザーが同時にデータを読み書きできるようにしてるんだ。このMVCCのおかげで、ロック待ちで処理が止まることが少なくて済むんだけど、その裏側では、データを「更新」するたびに、新しいバージョン（タプル）が作られる。

で、古いバージョンのタプルっていうのは、もう使われることはないんだけど、すぐには消えないんだ。なぜかって？それは、他のトランザクションがまだその古いバージョンを参照している可能性があるから。

ここで登場するのが、VACUUMだ！ VACUUMは、

「もう誰も使ってない古いデータ（デッドタプル）はどれだ？」

ってのを特定して、

「この領域はもう安全に再利用できるよ！」

ってマークしてくれる、そんな「お掃除係」なんだ。

ヒープ（テーブル本体）のお掃除

テーブル本体、つまり「ヒープ」には、行データが格納されている。VACUUMは、このヒープからデッドタプルを見つけて、その領域を「空き」としてマークする。この空いた領域は、新しいデータが入ってくる時に再利用されることになるんだ。

イメージとしては、本棚に本を並べているのを想像してみてくれ。古い本を処分しても、すぐにはそのスペースが空くわけじゃない。でも、VACUUMが「このスペース、もう使わないよ！」って印をつけてくれることで、新しい本をその場所に置けるようになる、みたいな感じだ。

インデックスのお掃除

テーブル本体だけじゃなく、インデックスもVACUUMの対象になる。インデックスも、データの更新や削除によって、古くなったエントリが残ってしまうことがあるんだ。VACUUMは、インデックスから無効になったエントリを削除したり、構造を整理したりしてくれる。

インデックスが綺麗に保たれていると、データの検索が速くなるのはもちろん、ディスク容量の節約にも繋がる。これは、もう「本棚の整理整頓」って感じだね。使われなくなった本の索引を削除したり、索引の順番を並べ替えたりするイメージだ。

VACUUMの「種類」と「使い分け」

VACUUMって一言で言っても、実はいくつか種類があるんだ。それぞれ得意なこと、苦手なことがあるから、状況に応じて使い分けるのが大事。

1. AUTO VACUUM (自動バキューム)

これはPostgreSQLが自動でやってくれるVACUUMだ。設定ファイル (`postgresql.conf`) で色々なパラメータを調整できるんだけど、デフォルトでもちゃんと動いてくれる、頼もしいやつなんだ。

何をしてくれる？
テーブルへの更新・削除の頻度や量に応じて、自動的にVACUUMを実行してくれる。
デッドタプルの割合がある程度超えたら、実行する、みたいなロジックで動いてる。
メリット:
管理者が意識しなくても、ある程度は自動でテーブルを綺麗にしてくれる。
デフォルト設定でも、ほとんどのケースで問題なく動作する。
デメリット:
実行タイミングや頻度が、必ずしも最適なタイミングとは限らない。
すごく大量の更新・削除があった場合、AUTO VACUUMだけでは追いつかないことがある。

2. MANUAL VACUUM (手動バキューム)

これは、君たちがSQLコマンドで直接実行するVACUUMのことだ。

VACUUM;

これを実行すると、データベース全体に対して、デッドタプルを回収する処理が行われる。

何をしてくれる？
データベース全体のテーブルを対象に、デッドタプルを回収し、領域を再利用可能にする。
メリット:
好きなタイミングで、必要なテーブルを（あるいはデータベース全体を）綺麗にできる。
AUTO VACUUMで追いつかなかった場合や、特定のタイミングでクリーンアップしたい場合に有効。
デメリット:
実行には時間がかかる場合がある。
実行中は、他の処理に影響を与える可能性がある（後述）。
ユーザーが自分で管理する必要がある。

3. VACUUM FULL

これは、ちょっと強力なVACUUMだ。通常のVACUUMが「領域を再利用可能にする」のに対し、`VACUUM FULL` は「ディスク上の実際の領域を解放する」ことを目指す。

VACUUM FULL table_name;

何をしてくれる？
テーブル全体を再構築する。
デッドタプルだけでなく、テーブルのデータそのものを物理的に削除して、ディスク上の空き領域をOSに返却する。
メリット:
ディスク使用量を大幅に削減できる可能性がある。
テーブルの断片化（フラグメンテーション）を解消できる。
デメリット:
めちゃくちゃ時間がかかる！
テーブルをロックする！ (他の処理が一切できなくなる)
ディスク容量を一時的に多く消費する！ (新しいテーブルを書き出すため)
実行中の負荷が高い！

※注意！ `VACUUM FULL` は、その強力さゆえに、実行には細心の注意が必要だ。本当にディスク容量を圧迫していて、かつ、長時間サービスを停止させられる場合に限定して使うべき。普段使いは、通常のVACUUMで十分だ。

4. ANALYZE

VACUUMとは直接関係ないんだけど、セットで語られることが多いのが `ANALYZE` だ。

ANALYZE table_name;

何をしてくれる？
テーブルのデータの統計情報を収集・更新する。
この統計情報をもとに、PostgreSQLのクエリプランナーは、最も効率の良い実行計画を立てる。
なぜVACUUMとセットなのか？
VACUUMでデッドタプルが片付けられて、新しいデータが入ってくると、データの分布が変わる。
データの分布が変わると、古い統計情報が役に立たなくなる。
だから、VACUUMの後に `ANALYZE` を実行して、統計情報を最新の状態に保つことが、パフォーマンス維持のために重要なんだ。
AUTO VACUUMには、`ANALYZE` も含まれていることが多い。

VACUUM実行時の「注意点」と「実践的なアドバイス」

さて、VACUUMの基本動作は分かったところで、現場で「うわっ！」ってならないための注意点と、実践的なアドバイスをいくつかしておこう。

1. 実行時のロックについて

通常のVACUUMは、デッドタプルを回収するだけで、テーブルへの書き込みをブロックするような強いロックはかけない。だから、SELECTやUPDATE、DELETEといった他の操作と並行して実行できるんだ。これは、PostgreSQLの強みの一つだね。

ただし！

`VACUUM FULL` は、テーブル全体を再構築するので、実行中はテーブルへの全てのアクセス（読み書き）がブロックされる。
非常に稀だけど、VACUUM実行中に他のトランザクションが特定の行をロックしていると、VACUUM側が待つこともある。

2. AUTO VACUUMの設定は重要！

AUTO VACUUMは便利だけど、デフォルト設定が常に最適とは限らない。特に、以下のようなケースでは、設定の見直しを検討した方が良い。

大量の更新・削除が頻繁に発生するシステム: AUTO VACUUMの実行頻度や、トリガーとなる閾値（`autovacuum_vacuum_threshold`, `autovacuum_vacuum_scale_factor` など）を調整して、もっと頻繁にVACUUMが走るようにする。
テーブルのサイズが大きいシステム: 巨大なテーブルだと、AUTO VACUUMが完了するのに時間がかかり、追いつかなくなることがある。この場合も、閾値の調整や、手動VACUUMとの併用を検討する。
INSERTが多いシステム: INSERTだけでも、古いトランザクションが残っていると、デッドタプルが発生することがある。

`postgresql.conf` には、AUTO VACUUMに関するパラメータがたくさんある。最初は戸惑うかもしれないけど、よく使われるものをいくつか紹介しておこう。

`autovacuum = on` : AUTO VACUUMを有効にするか (デフォルトは on)
`autovacuum_max_workers` : 同時に実行できるAUTO VACUUMプロセスの数
`autovacuum_vacuum_threshold` : VACUUMを実行するための最小のデッドタプル数
`autovacuum_vacuum_scale_factor` : VACUUMを実行するためのデッドタプルの割合 (テーブルサイズに対する割合)
`autovacuum_analyze_threshold` : ANALYZEを実行するための最小の変更タプル数
`autovacuum_analyze_scale_factor` : ANALYZEを実行するための変更タプルの割合

これらのパラメータは、テーブルごとに設定することも可能だ。例えば、特定のテーブルだけ、もっと頻繁にVACUUMしたい、なんて場合に便利だ。

ALTER TABLE your_table SET (autovacuum_vacuum_threshold = 1000, autovacuum_vacuum_scale_factor = 0.05);

3. 手動VACUUMの「タイミング」

AUTO VACUUMで大抵は大丈夫なんだけど、どうしても手動でVACUUMを実行したい、という場面もあるだろう。例えば、

定期的なメンテナンスウィンドウ: サービスへの影響が少ない時間帯に、データベース全体を綺麗にしたい。
パフォーマンスの急激な低下: 何か原因でパフォーマンスが落ちた時に、VACUUMが原因の一つではないか？と疑って実行してみる。
ディスク使用量の増加: AUTO VACUUMが追いつかず、ディスク使用量がどんどん増えている時。

手動VACUUMを実行する際は、対象のテーブルやデータベースの規模、他の処理への影響を考慮して、慎重に実行しよう。いきなりデータベース全体ではなく、まずは影響の少ないテーブルから試してみるのがセオリーだ。

4. VACUUMとトランザクションIDラッパーラップ

これはちょっと専門的な話になるんだけど、PostgreSQLのトランザクションID (XID) には、限りがある。全部使い切ってしまうと、新しいトランザクションができなくなってしまう、という問題が起こりうるんだ。これを「トランザクションIDラッパーラップ」と呼ぶ。

VACUUMは、このXIDの枯渇を防ぐためにも重要な役割を果たしている。古いトランザクションIDに関連付けられたデッドタプルを片付けることで、XIDが再利用されるようにしているんだ。

もし、VACUUMが全く実行されないような状況が続くと、このXIDラッパーラップが発生し、データベースが機能停止してしまう、なんて最悪の事態もあり得る。だから、VACUUMは「お掃除」だけでなく、「システム全体の安定稼働」のために不可欠なんだ。

まとめ：VACUUMは「縁の下の力持ち」

今日は、PostgreSQLのVACUUMについて、その基本動作から実践的な注意点まで、色々と話してきた。

VACUUMは、MVCC環境下で発生するデッドタプルを整理し、領域を再利用可能にするための重要なプロセス。
ヒープ（テーブル本体）とインデックスの両方をクリーンアップする。
AUTO VACUUM は自動でやってくれるが、設定の見直しも重要。
MANUAL VACUUM は、手動で実行する。
VACUUM FULL は強力だが、リスクも高いので注意が必要。
ANALYZE はVACUUMとセットで、クエリプランナーのために統計情報を更新する。

VACUUMは、普段はあまり意識しないかもしれないけど、PostgreSQLのパフォーマンスと安定性を支える、まさに「縁の下の力持ち」なんだ。

君たちが担当するシステムで、もしパフォーマンスの低下を感じたり、ディスク使用量が気になることがあったら、まずはVACUUMのことを思い出してみてほしい。そして、AUTO VACUUMの設定や、手動VACUUMの実行タイミングなどを検討してみてくれ。

これからも、現場で役立つ情報をどんどん発信していくから、楽しみにしててくれよな！

質問や感想があったら、気軽にコメントで教えてくれ！それじゃ、また次の記事で！