TOASTという「最後の砦」を飼いならす：PostgreSQLの巨大データとの付き合い方
PostgreSQLを長く触っていると、必ず一度は壁にぶつかるのが「巨大なテキストやバイナリデータの扱い」です。JSONBの肥大化、あるいは長大なログデータ。これらをデータベースに放り込んでいると、いつの間にかクエリのレイテンシが跳ね上がり、インデックススキャンが悲鳴を上げ始める。
そう、皆さんがよくご存知の「TOAST（The Oversized-Attribute Storage Technique）」の話です。
今回は、このPostgreSQLの隠れた功労者であるTOASTについて、単なる仕組みの解説を超えて、「なぜコイツがパフォーマンスのボトルネックになるのか」、そして「どう設計すれば平和に運用できるのか」という、少し踏み込んだ話をしようと思います。
—
TOASTは「別腹」であるという認識
まず、大前提を共有しましょう。PostgreSQLのページサイズ（デフォルト8KB）に収まらないデータは、自動的にメインのテーブルから切り離され、TOASTテーブルという「別腹」に押し込まれます。
ここで多くのエンジニアが勘違いしがちなのが、「TOASTに追い出されたから、クエリ性能には影響しないだろう」という楽観論です。これは半分正解で、半分は大きな間違いです。
- メインテーブル側の恩恵: メインのページ内に小さな参照ポインタ（chunkのポインタ）しか残らないため、行の密度が高まり、インデックススキャンやシーケンシャルスキャンの効率は劇的に向上します。これは素晴らしい設計です。
- コストの罠: しかし、そのデータが必要になった瞬間、PostgreSQLはメインテーブルとは別のTOASTテーブルへランダムアクセスを発生させます。さらに、TOASTされたデータは圧縮されることが多いため、読み込み後のCPU負荷も相応にかかります。
ストレージ戦略の「しきい値」をハックする
デフォルトでは、2KBを超えるとTOASTの検討が始まります。ですが、すべてのカラムに対してこのデフォルト設定が最適だとは限りません。
ALTER TABLE my_table ALTER COLUMN my_large_json SET STORAGE EXTERNAL;
`STORAGE`設定をいじることで、挙動を制御できます。
- EXTENDED (デフォルト): 圧縮と外部格納の両方を行う。CPUとディスクI/Oのトレードオフです。
- EXTERNAL: 圧縮はしないが外部格納はする。CPU負荷を下げたい場合に有効です。
- MAIN: 圧縮はするが、できるだけインライン（メインテーブル）に留めようとする。
- PLAIN: 絶対に外部格納しない。
もし、頻繁にアクセスするが圧縮が効きにくい（すでに圧縮済みのバイナリなど）データを扱っているなら、`EXTERNAL`への変更を検討してください。CPUの無駄な展開時間を削るだけで、スループットが数％改善することは珍しくありません。
インデックス性能への「見えないダメージ」
これが今回一番伝えたいポイントです。「TOASTされたカラムに対してインデックスを貼るな」というのはエンジニアの常識ですが、実はそれだけでは不十分です。
TOASTテーブルの仕組み上、巨大なデータは「チャンク」に分割されて保存されます。もし、不適切な設計でインデックスを貼ろうとすれば、オプティマイザは巨大なデータの海を渡る羽目になります。
特に注意すべきは、`pg_toast`配下のテーブルに対するメンテナンスです。
- BLOAT（断片化）: TOASTテーブルは通常のテーブルよりもBLOATの影響を受けやすく、VACUUMが追いつかなくなると、ランダムI/Oが爆発的に増えます。
- Visibility Mapの欠如: TOASTテーブルにはVisibility Mapがないため、Index-Only Scanの恩恵を一切受けられません。
もしインデックスが必要なら、巨大なカラムそのものではなく、そのカラムから抽出した「ハッシュ値」や「必要な一部のフィールド」に対するFunctional Index（関数インデックス）を検討してください。`tsvector`や`jsonb_path_ops`を駆使して、TOAST領域を直接触らない設計にするのが、プロのやり方です。
パフォーマンストラブルシューティングの勘所
もしあなたのDBで「なぜかI/Oが高い」「特定のクエリが遅い」と感じたら、まずは以下のクエリでTOASTテーブルの肥大化を確認してください。
SELECT relname, relpages
FROM pg_class
WHERE relname LIKE ‘pg_toast_table_OID%’;
`relpages`が異常に大きい場合、それは物理的にデータが散らばっている証拠です。`VACUUM FULL`や`pg_repack`で物理的な配置を整理するだけで、劇的に改善することがあります。
最後に：データベースは「引き算」の美学
TOASTという強力な機能があるからといって、何でもかんでもDBに突っ込めばいいわけではありません。
本当にそのデータはデータベースのACIDトランザクションの保護下にあるべきでしょうか？ 巨大なオブジェクトはS3などのオブジェクトストレージに逃がし、PostgreSQLにはそのポインタ（URLなど）だけを持たせる。この「疎結合な設計」こそが、数年後の運用であなたを救うことになります。
データベースエンジニアとしての腕の見せ所は、いかに「複雑な機能を使いこなすか」ではなく、いかに「機能を無力化（最適化）してシンプルに保つか」にあります。
それでは、良いデータモデリングを。
コメント