PostgreSQLの「禁じ手」？ いや、UNLOGGEDテーブルこそが最強の武器になる理由
やあ。最近、PostgreSQLのパフォーマンスチューニングで頭を抱えてるって聞いたよ。インデックスを貼りすぎても遅くなるし、かといって放っておくとクエリは重くなる。悩ましいよね。
そんなとき、ふと「これ、本当にディスクに書き込み続ける必要があるのか？」って立ち止まること、あるだろ？
今日は、そんな悩みを抱える君に「UNLOGGEDテーブル」という、ちょっとワイルドだけど使いこなせば強力な武器を紹介するよ。
—
UNLOGGEDテーブルって何者？
簡単に言うと、「WAL（Write Ahead Log）への書き込みをサボるテーブル」のことだ。
PostgreSQLは通常、データの整合性を守るために、すべての変更を「WAL」というログファイルに書き込んでから、本体のデータファイルに反映させる。これが「ACID特性」を担保するための仕組みなんだけど、裏を返せば、常に二重書き込みが発生してるってことだよね。
UNLOGGEDテーブルは、このWALへの書き込みをバイパスする。つまり、ディスクI/Oが劇的に減るわけだ。
でも、リスクはあるんだよ
魔法のような話だけど、タダ飯はない。最大のデメリットは、「クラッシュしたときにデータが吹っ飛ぶ」ということだ。
PostgreSQLが予期せずシャットダウン（停電とかカーネルパニックとか）すると、UNLOGGEDテーブルのデータは初期化される。正確には、再起動時に空っぽになるんだ。だから、「失われても再生成可能なデータ」以外には絶対に使っちゃダメだ。
—
具体的な使い所：どんなときに使う？
現場でよく見る「UNLOGGEDが輝くシーン」をいくつか挙げておくね。
1. ETL処理の一時的なステージングテーブル
外部から大量のCSVを流し込んで、加工して本番テーブルにマージする。そんなとき、中継地点のテーブルはUNLOGGEDで十分だ。
2. 複雑な解析のキャッシュ
何分もかかる集計結果を一度どこかに退避したいとき。再計算できるなら、ログに残すコストを払う必要はないよね。
3. 高速なバッチ処理のワークテーブル
数百万行のデータをJOINしてソートするような重いバッチ。一時的にデータを保持するためのテーブルをUNLOGGEDにすると、体感速度がガラッと変わるはずだ。
—
実践：どうやって使うのか？
使い方は驚くほどシンプルだ。`CREATE TABLE`のときにキーワードを添えるだけ。
— 通常のテーブル
CREATE TABLE staging_data (
id serial PRIMARY KEY,
payload jsonb
);
— UNLOGGEDテーブル
CREATE UNLOGGED TABLE staging_data_fast (
id serial PRIMARY KEY,
payload jsonb
);
もし、すでに存在するテーブルを変換したいなら、こうするんだ。
ALTER TABLE staging_data SET UNLOGGED;
（※注意：戻すときは `ALTER TABLE staging_data SET LOGGED;` だ。覚えておいてくれよ。）
—
先輩からのアドバイス：ここだけは気をつけろ！
UNLOGGEDテーブルを使うときに、必ず自問自答してほしいことがある。
- 「このデータ、今日消えても明日また作り直せる？」
これがYesなら、迷わずUNLOGGEDだ。Noなら、たとえ遅くてもLOGGED（通常）テーブルを使うべきだ。
- レプリケーションとの関係
実は、スタンバイサーバー側でもUNLOGGEDテーブルは空っぽになる。レプリケーション先で「あれ？データがないぞ」って慌てないようにね。
- 「速い」だけで選ばない
パフォーマンス向上は魅力だけど、何でもかんでもUNLOGGEDにするのは危険だ。あくまで、「再生成コスト」と「I/O負荷」のトレードオフを天秤にかけて判断すること。
—
最後に
データベース設計って、結局は「何を諦めて、何を優先するか」の決断の連続なんだ。
UNLOGGEDテーブルは、その決断を助けてくれる優秀なツールだよ。最初は怖くて使えないかもしれないけど、一度試して、その爆速っぷりを体験してみてくれ。きっと、君のクエリチューニングの引き出しが一つ増えるはずさ。
また何か詰まったら、いつでも聞きに来てよ。エンジニア同士、一緒に腕を上げていこうぜ！
コメント