インデックスを「別の場所」へ。PostgreSQLにおけるテーブルスペース戦略の真実
PostgreSQLを長年触っていると、一度は「インデックスだけ別のディスクに逃がしたい」という誘惑に駆られるはずです。特に、I/O負荷が突き抜けている高トラフィックなシステムを担当していると、物理的なストレージ構成で無理やりパフォーマンスを絞り出したくなる。
今日は、PostgreSQLにおける「インデックスのテーブルスペース分離」という、一見古典的で、実は非常に奥が深いトピックについて、現場の視点から掘り下げてみようと思う。
なぜ、インデックスを分けるのか？
教科書的な回答は「I/O負荷の分散」だ。テーブルとインデックスが同じディスクにあると、クエリ実行時にデータファイルとインデックスファイルの間でヘッドのシーク（HDD時代なら致命的だった）やI/O競合が発生する。
しかし、現代のNVMe SSD全盛の時代に、この「I/O分散」という理屈はどれほど意味があるのだろうか。
実は、インデックスを別テーブルスペースに配置する真のメリットは、純粋なスループットよりも「運用の分離」と「物理特性の最適化」にある。
- ストレージ階層の適材適所: 更新頻度が非常に高いテーブルは耐久性（書き込み耐性）を重視したSSDへ、逆に読み取り専用の巨大なインデックスは、コスト効率の良い大容量ストレージへ配置するといった戦略が可能だ。
- I/Oプロファイルの分離: インデックスはランダムアクセスが主、テーブルはシーケンシャルスキャンが主というケースが多い。この特性の違いをOSやストレージコントローラーレベルで区別することで、キャッシュの汚染やI/Oのコンテンションを最小限に抑えられる。
内部アーキテクチャから紐解く配置の作法
PostgreSQLでテーブルスペースを指定するのは簡単だ。`CREATE INDEX … TABLESPACE tbs_index` を叩くだけ。だが、内部で何が起きているかを理解していないと、かえってトラブルの元になる。
PostgreSQLのストレージマネージャは、ファイルパスをテーブルスペースOIDとデータベースOID、リレーションOIDの組み合わせで管理している。テーブルスペースを分けるということは、ファイルシステムレベルで物理的なマウントポイントを分けることを意味する。
ここで注意すべきなのは、「fsyncの連鎖」だ。
PostgreSQLはトランザクションの整合性を保つために、チェックポイント時に各ファイルに対して `fsync` を発行する。もし、テーブルとインデックスが全く異なる特性を持つストレージ（例えば、超高速なNVMeと、低速なHDD）に配置されている場合、チェックポイントの完了時間は「最も遅いストレージ」に引きずられることになる。
パフォーマンストラブルシューティングの落とし穴
「インデックスを別ディスクに逃がしたのに、なぜかクエリが速くならない」という相談をよく受ける。原因の多くは、ストレージそのものではなく「論理的なボトルネック」にある。
1. インデックスの肥大化（Bloat）: インデックスを別の場所に置いても、インデックスが肥大化していればI/Oは減らない。むしろ、別ディスクに置いたことで「遅いディスクに巨大なインデックスがある」という最悪の状況を生み出している可能性がある。まずは `pgstattuple` でインデックスの有効利用率を確認してほしい。
2. OSレベルのI/Oスケジューラ: ストレージが別であっても、カーネルが同じI/Oスケジューラ（例えば `mq-deadline` や `kyber`）を適用している場合、I/Oの割り込み処理が競合する。NVMeを使うなら `none` や `none` に近い設定を検討するのも一つの手だ。
3. WALの配置: インデックス配置に気を取られすぎて、WAL（Write Ahead Log）が同じディスク上に残っていないか？ インデックスの構築や更新はWALの書き込みを伴う。ここがボトルネックになっていては、インデックスをどこへ移しても無意味だ。
結論：魔法の杖ではない
インデックスを別テーブルスペースに配置するのは、非常に強力なチューニング手法だが、決して魔法の杖ではない。
私の経験上、本当に効果が出るのは「I/O帯域の限界に達している巨大データベース」か「ストレージのコストと性能のバランスを極限まで最適化したい」というケースに限られる。まずは標準構成で限界までチューニングし、`pg_stat_io` などの統計情報を睨みながら、「どこに物理的制約があるのか」を明確に突き止めることが先決だ。
インデックスの配置をいじるのは、外科手術と同じだ。メスを入れる前に、今の構成が本当に最適なのか、もう一度アーキテクチャのレイヤーまで遡って考えてみてほしい。
さて、次はどの統計情報を掘り下げようか。データベースの内部構造を知ることは、いつだって最高にエキサイティングな冒険だよ。
コメント