PostGISの空間演算を「使いこなす」ということ：パフォーマンスの深淵へ
PostGISを触り始めた頃、`ST_Intersects`や`ST_DWithin`を使って「おっ、地図が出た！」と喜んだ経験は誰にでもあるはずだ。しかし、データ量が数百万、数千万レコードに膨れ上がり、クエリが秒単位で帰ってこなくなったとき、我々は「PostGISの真の姿」を目の当たりにすることになる。
今日は、教科書的な関数の説明は一旦横に置いて、PostGISという強大な武器をどう「調教」すべきか、その設計思想とトラブルシューティングの勘所について語ろうと思う。
—
1. 空間演算関数の「コスト」を正しく見積もる
PostGISの演算は、CPUを容赦なく食いつぶす。特に複雑なポリゴン演算を行う関数は、その裏側で膨大な計算を行っていることを忘れてはならない。
- ST_Intersects: 空間インデックス（GIST/SP-GIST）を活用できる最強の武器だ。しかし、条件句に非決定的な関数や複雑なJOINが含まれると、オプティマイザはインデックスを無視してシーケンシャルスキャンを選択してしまうことがある。
- ST_Buffer: これをWHERE句で使うのは、往々にして「アンチパターン」だ。バッファ生成は動的なジオメトリ作成を伴うため、インデックスが効かない。もし特定の距離内での検索が必要なら、`ST_DWithin`を使うべきだ。これならインデックスをフル活用できる。
- ST_Union: これを大量のレコードに対して実行すると、メモリの圧迫とCPUのスパイクを招く。`ST_Collect`で集約してから最後に`ST_UnaryUnion`をかける、あるいは並列処理を活用するなどの工夫が必要になる。
2. 空間インデックスの「嘘」を見抜く
「GISTインデックスを貼れば速くなる」というのは半分正解で、半分は罠だ。
空間インデックスは、あくまで「MBR（最小外接矩形）」による概算判定だ。つまり、インデックスが返した結果には「疑わしい候補」が含まれている。PostGISはその後、正確な形状演算（Recheck）をCPUで行う。
もし、インデックスの効果が出ていないと感じたら、`EXPLAIN ANALYZE`で `Rows Removed by Filter` を見てほしい。インデックスが広範囲の候補を返しすぎて、その後のフィルタリングに時間を費やしているなら、データのクラスタリングや、より精度の高いインデックス構成を検討する必要がある。
特に、`SP-GIST`への乗り換えは検討に値する。データが空間的に偏っている場合、従来のGISTよりも検索性能が劇的に向上することが多い。
3. パフォーマンストラブルの「現場」でまず確認すること
運用中に「急に重くなった」という相談を受けた際、私がまず確認するのはこの3点だ。
1. 統計情報の鮮度: `ANALYZE`は適切に行われているか？特に空間データは分布が偏りやすいため、デフォルトの統計情報ではオプティマイザが間違った判断を下すことが多い。
2. ジオメトリの不正: `ST_IsValid`でチェックしてほしい。不正なジオメトリが含まれていると、演算関数は例外的な挙動（あるいは極端な低速化）を引き起こすことがある。
3. SRIDの不一致: 異なるSRID同士の演算は、内部で自動変換（`ST_Transform`）を挟むことがある。これがクエリのたびに走っていれば、遅くて当然だ。必ず正規化して持っておくこと。
4. まとめ：エンジニアとしての矜持
PostGISは単なる「地図データベース」ではない。数学的・幾何学的な厳密さと、データベースの並列計算能力が融合した、非常に高度なシステムだ。
空間クエリが遅いとき、それはデータベースが悪いのではなく、我々の「空間の捉え方」が不完全であることの証左かもしれない。複雑な演算をそのまま投げるのではなく、いかにしてインデックスの恩恵を最大化し、CPUの負荷を最小化するか。
そのパズルを解くことこそが、我々データベースエンジニアにとっての醍醐味ではないだろうか。
もしあなたのクエリが重いと感じたら、次は`EXPLAIN (ANALYZE, BUFFERS)`をじっくり眺めてみてほしい。そこには、PostGISがどこで苦しんでいるのか、その断末魔とも言えるヒントが必ず記されているはずだ。
コメント