【実務・中級編】空間インデックス (GiST/SP-GiST) – PostgreSQL

みんな、元気にしてるか？
最近、位置情報サービスとか、IoTデバイスからのセンシングデータとか、空間データを扱う機会が増えてないか？僕もね、最近とあるプロジェクトで膨大な地理空間データを扱うことになって、改めてPostgreSQLの空間インデックスの奥深さを痛感したんだ。

「大量の地図データから、特定のエリア内の施設を瞬時に検索したい！」
「GPSデータを使った移動経路の分析を、もっと高速にできないか？」

こんな悩み、抱えてないか？
もし心当たりがあるなら、今日の話は君にとってきっと役立つはずだ。
今回は、PostgreSQLで空間データ検索を爆速にするための二大巨頭、GiSTインデックスとSP-GiSTインデックスについて、その仕組みから具体的な使い方、そして「どっちを使えばいいの？」っていう実務的な判断基準まで、みっちり解説していくぞ。

教科書的な説明はもう飽き飽きだよな？現場で本当に使える知識を、先輩エンジニアの僕がしっかり伝授するから、安心してついてきてくれ！

—

1. 空間データ、そのままじゃ遅いぞ！検索のボトルネックを理解しよう

まず最初に、なぜ空間データ検索がネックになりやすいのか、軽くおさらいしておこう。
例えば、日本全国のコンビニの位置情報が10万件あったとする。
「今いる場所から半径5km以内にあるコンビニを探してくれ」
こんなクエリを実行する時、インデックスがなければどうなると思う？

PostgreSQLは、テーブルの全行をなめて、一つ一つ距離計算をしていく羽目になる。これがシーケンシャルスキャンってやつだ。10万件ならまだしも、1000万件、1億件になったらどうなる？途方もない時間がかかってしまうのは目に見えているよな。

そこで登場するのが、空間インデックスだ。
通常のB-treeインデックスは数値や文字列の「順序」に特化しているけど、空間データは「位置」や「形状」といった多次元的な情報を扱う。これを効率的に検索するためには、専用のインデックス構造が必要なんだ。
PostgreSQLは、この空間データ処理を強力にサポートするPostGISという拡張機能と組み合わせることで、まさに最強の地理空間データベースになる。

—

2. 環境構築とサンプルデータの準備：まずはPostGISを導入だ！

空間インデックスの話をする前に、まずはPostGISの準備からだ。
まだ入れてない人は、これを機に導入しちゃおう。

— PostGIS拡張機能を有効にする
CREATE EXTENSION postgis;

— 試しに、店舗情報を格納するテーブルを作ってみよう
CREATE TABLE stores (
id SERIAL PRIMARY KEY,
name VARCHAR(255),
location GEOMETRY(Point, 4326) — ポイント型で、SRIDは4326 (WGS84緯度経度)
);

— 適当なデータをいくつか投入してみる
INSERT INTO stores (name, location) VALUES
(‘東京駅店’, ST_SetSRID(ST_MakePoint(139.767125, 35.681236), 4326)),
(‘新宿駅店’, ST_SetSRID(ST_MakePoint(139.700572, 35.689487), 4326)),
(‘渋谷駅店’, ST_SetSRID(ST_MakePoint(139.701636, 35.659092), 4326)),
(‘横浜駅店’, ST_SetSRID(ST_MakePoint(139.622543, 35.443708), 4326)),
(‘大阪駅店’, ST_SetSRID(ST_MakePoint(135.495963, 34.702485), 4326)),
(‘名古屋駅店’, ST_SetSRID(ST_MakePoint(136.881525, 35.170915), 4326));

— さらに、広範囲にわたるランダムなデータを10万件ほど追加してみよう（テスト用）
INSERT INTO stores (name, location)
SELECT
‘店舗_’ || generate_series,
ST_SetSRID(ST_MakePoint(
120 + (random() 30), — 経度: 120から150度くらい
20 + (random() 30) — 緯度: 20から50度くらい
), 4326)
FROM generate_series(7, 100000);

これで、日本とその周辺にランダムに配置された10万件の店舗データができた。
ちなみに`GEOMETRY(Point, 4326)`は、「ジオメトリ型で、点(Point)を表し、SRIDは4326（WGS84座標系）」という意味だ。SRIDは空間参照系を識別するIDで、緯度経度を扱うならWGS84 (SRID: 4326) が一般的だな。

—

3. 多次元データを箱で管理！GiSTインデックスの仕組みと使い方

さあ、本題の一つ目、GiST（Generalized Search Tree）インデックスだ。
GiSTはPostgreSQLが提供する汎用的なインデックスフレームワークで、R-tree（R木）のような多次元空間インデックスを構築するのに使われる。PostGISの空間インデックスも、このGiSTをベースにしているんだ。

3.1. GiSTインデックスって、どんな構造？（R-treeのイメージ）

R-treeというのは、簡単に言うと「箱の中に箱を入れ子にして、空間を分割していく」ようなイメージだ。
例えば、たくさんの点やポリゴンが地図上にあるとする。R-treeは、それらを包含する最小の矩形（Minimum Bounding Rectangle: MBR）でグループ化していく。
大きなMBRの中に、いくつかの小さなMBRがあり、さらにその中にデータ本体がある、という階層構造を作るんだ。

検索時には、まずルートノードのMBRを見て、検索条件と重なるMBRを持つ子ノードだけを辿っていく。これによって、関係のない大部分のデータをスキップし、検索範囲を効率的に絞り込むことができるわけだ。

3.2. GiSTインデックスが輝く場面

GiSTインデックスは、以下のようなシーンで特にその威力を発揮する。

範囲検索: `ST_Intersects`（交差する）、`ST_Contains`（包含する）、`ST_Within`（内部にある）など、特定の範囲内にあるオブジェクトを探す場合。
近傍検索: `ST_DWithin`（指定距離内にある）、`ORDER BY <->`（距離順ソート）など、特定の地点から近いオブジェクトを探す場合。

点、線、ポリゴンなど、PostGISが扱う多様なジオメトリ型に対応しているのが強みだ。

3.3. GiSTインデックスの作成と効果確認

実際にインデックスを作成して、その効果を体感してみよう。

— まずはインデックスなしで検索してみる
— 東京駅周辺から半径0.01度（WGS84座標系での0.01度は、経度方向で約1.1km、緯度方向で約1.1kmに相当）以内にある店舗を検索
EXPLAIN ANALYZE
SELECT id, name, ST_AsText(location)
FROM stores
WHERE ST_DWithin(location, ST_SetSRID(ST_MakePoint(139.767125, 35.681236), 4326), 0.01);

この時、`EXPLAIN ANALYZE`の結果を見てほしい。おそらく`Seq Scan`（シーケンシャルスキャン）になっているはずだ。10万件のテーブルで、`Planning Time`と`Execution Time`がそれぞれ数十ミリ秒〜数百ミリ秒かかるだろう。データ量が増えれば増えるほど、この時間は雪だるま式に増えていく。

さて、いよいよGiSTインデックスの登場だ。

— GiSTインデックスを作成する
CREATE INDEX idx_stores_location_gist ON stores USING GIST (location);

インデックス作成には少し時間がかかるかもしれないが、データ量にもよる。
作成が終わったら、もう一度同じクエリを実行してみよう。

— GiSTインデックス作成後、再度検索してみる
EXPLAIN ANALYZE
SELECT id, name, ST_AsText(location)
FROM stores
WHERE ST_DWithin(location, ST_SetSRID(ST_MakePoint(139.767125, 35.681236), 4326), 0.01);

どうだ？ `Index Scan using idx_stores_location_gist`になっているはずだ！
`Execution Time`も劇的に短縮されているはず。僕の環境では、数百ミリ秒かかっていたものが、数ミリ秒、あるいは1ミリ秒以下になったりする。これがインデックスの力だ！

`ST_DWithin`のような距離検索だけでなく、以下のような範囲検索でも効果を発揮する。

— 指定したポリゴン（矩形）と交差する店舗を検索
— 東京駅周辺を囲む矩形 (例: 経度139.7度～139.8度、緯度35.6度～35.7度)
EXPLAIN ANALYZE
SELECT id, name, ST_AsText(location)
FROM stores
WHERE ST_Intersects(location, ST_SetSRID(ST_MakeEnvelope(139.7, 35.6, 139.8, 35.7), 4326));

これもバッチリ`Index Scan`になるはずだ。

3.4. GiSTインデックスの注意点

更新コスト: GiSTインデックスは多次元構造を維持するため、データの挿入、更新、削除の際にはそれなりにオーバーヘッドがある。頻繁に更新される巨大なテーブルでは、そのコストと検索性能のバランスを考慮する必要がある。
インデックスサイズ: MBRを階層的に管理するため、インデックス自体のサイズもそれなりに大きくなる傾向がある。
VACUUMの重要性: GiSTインデックスもB-treeと同じく、削除されたタプルによる「デッドタプル」が発生する。定期的な`VACUUM`（特に`VACUUM FULL`ではなく通常の`VACUUM`または`autovacuum`）で、インデックスの肥大化を防ぎ、効率を保つことが重要だ。

—

4. 空間を分割して高速化！SP-GiSTインデックスの仕組みと使い方

次に紹介するのは、もう一つの空間インデックス、SP-GiST（Space-Partitioned Generalized Search Tree）インデックスだ。GiSTとはまた違ったアプローチで空間データを効率的に管理する。

4.1. SP-GiSTインデックスって、どんな構造？（四分木のイメージ）

SP-GiSTは、その名の通り「空間を分割していく」ことに特化したインデックスだ。
代表的な構造としては、四分木（Quadtree）やkd-tree、パトリシアトライなどがある。
イメージとしては、地図全体をまず4分割し、さらにデータが存在する範囲を4分割、また4分割…というように、再帰的に空間を小さく分割していく。データが密集している場所は細かく分割され、そうでない場所は粗く分割される。

これにより、検索時には「いま探しているデータはこの区画にはないな」と判断できれば、その区画全体をスキップできるため、効率的に検索範囲を絞り込めるんだ。

4.2. SP-GiSTインデックスが輝く場面

SP-GiSTは、特定のアクセスパターンでGiSTよりも優れた性能を発揮することがある。

点データ（Point）の検索: 特に、広範囲に散らばった点データを効率的に扱うのに向いている。四分木のような分割構造は、点の密度に応じて柔軟に調整されるため、大量の点データから特定の点を高速に検索するのに強い。
階層的なデータ: データを階層的に分類するようなケース（例えばIPアドレス範囲の検索など）にも応用できる。

特に、点データが非常に多く、かつ特定の場所（例えば都市部）に集中し、他の場所は疎らといったデータ分布の場合、SP-GiSTの空間分割はGiSTのMBRよりも効率的になることが多い。

4.3. SP-GiSTインデックスの作成と効果確認

さっきの`stores`テーブルの`location`は点データだから、SP-GiSTも試すのにぴったりだ。

— まずはGiSTインデックスを削除して、SP-GiSTを試す準備
DROP INDEX idx_stores_location_gist;

— SP-GiSTインデックスを作成する
CREATE INDEX idx_stores_location_spgist ON stores USING SPGIST (location);

インデックス作成後、GiSTの時と同じクエリを実行してみよう。

— SP-GiSTインデックス作成後、再度検索してみる
EXPLAIN ANALYZE
SELECT id, name, ST_AsText(location)
FROM stores
WHERE ST_DWithin(location, ST_SetSRID(ST_MakePoint(139.767125, 35.681236), 4326), 0.01);

これもまた`Index Scan using idx_stores_location_spgist`になっているはずだ。
実行時間もGiSTと同等か、場合によっては少し速くなることもあるかもしれない。データ分布やクエリの内容によって得意不得意があるから、両方試して比較してみるのが一番だな。

4.4. SP-GiSTインデックスの注意点

対応ジオメトリ型: GiSTに比べると、SP-GiSTがサポートするジオメトリ型は限定的だ。特に、複雑なポリゴンやラインストリングの検索にはGiSTの方が適している場合が多い。PostGISのSP-GiSTは主に点データに最適化されている。
更新コスト: GiSTと同様に、空間構造を維持するための更新コストは発生する。
インデックスサイズ: GiSTよりは少しコンパクトになる傾向があるが、やはりデータ量が多いとそれなりのサイズになる。

—

5. GiSTとSP-GiST、どっちを選べばいいんだ？実務での判断基準

さて、GiSTとSP-GiST、どちらも空間検索を高速化してくれる強力なツールだが、それぞれ得意なことと苦手なことがある。じゃあ、実務ではどうやって選べばいいんだ？

結論から言うと、「試してみて、一番パフォーマンスの良い方を選ぶ」が鉄則だ。
ただし、一般的な傾向として、以下のポイントを参考にしてみてほしい。

ざっくりとした使い分けの目安:

まずはGiSTを試してみる: もし扱うジオメトリ型が多様（点、線、ポリゴンが混在するなど）だったり、データ分布がそこまで偏っていないなら、GiSTがオールラウンダーとして安定した性能を発揮することが多い。特に、複雑なポリゴンやラインストリングを扱う場合は、迷わずGiSTを選ぶべきだ。
点データが多く、分布に偏りがあるならSP-GiSTも候補に: 大量の点データ（例えばGPSログなど）を扱う場合で、特定の地域にデータが集中しているようなケースでは、SP-GiSTがGiSTよりも優れた性能を発揮する可能性がある。ぜひ両方で`EXPLAIN ANALYZE`を比較してみてほしい。

重要なのは、これらのインデックスはあくまで「候補を絞り込む」ためのものだということ。最終的な距離計算や複雑なジオメトリ演算は、インデックススキャンで絞り込まれた少ないデータに対して行われる。この「候補を絞り込む」フェーズをどれだけ効率的にできるかが、高速化の鍵なんだ。

—

6. 実務で役立つ！空間インデックスを使いこなすためのアドバイス

最後に、空間インデックスを実務で効果的に使いこなすための、僕なりのアドバイスをいくつか伝えておこう。

6.1. SRIDの一貫性を保つ

空間データを扱う上で、SRID（Spatial Reference ID）は非常に重要だ。テーブル内で同じジオメトリカラムを扱うなら、必ず同じSRIDを使うように徹底しよう。異なるSRIDのデータが混在すると、PostGIS関数が正しく動作しなかったり、インデックスが使われなかったりする原因になる。
例えば緯度経度なら`4326`、日本の測地系なら`6668`（JGD2011測地系平面直角座標系）など、目的に合ったSRIDを選び、統一すること。

6.2. 複合インデックスも検討する

空間検索だけでなく、他の条件（例えば`store_type = ‘コンビニ’`など）で絞り込みたい場合もあるだろう。そんな時は、空間インデックスとB-treeインデックスを組み合わせた複合インデックス、あるいはGiST/SP-GiST自体が複合インデックスに対応している場合もあるので検討してみよう。
ただし、GiST/SP-GiSTで複数カラムを指定できるのは特定の演算子クラスに限られることが多いので、ドキュメントを確認するか、別々にインデックスを貼ってオプティマイザに任せるのが一般的だ。
もし、特定の属性で絞り込んでから空間検索するケースが多いなら、B-treeで属性を絞り込んでから空間インデックスを使う、という流れになるだろう。

6.3. 統計情報を最新に保つ

PostgreSQLのオプティマイザは、インデックスを使うべきかどうか、どのインデックスを使うべきかを判断するために、テーブルの統計情報に大きく依存している。データが大幅に更新された後は、`ANALYZE TABLE ;` を実行して、統計情報を最新の状態に保つようにしよう。`autovacuum`が適切に設定されていれば、ほとんどの場合は自動でやってくれるはずだけど、大規模なデータ投入後は手動で実行するのもアリだ。

6.4. EXPLAIN ANALYZE は友達

「インデックス貼ったのに遅いぞ！」と思ったら、まずは`EXPLAIN ANALYZE`だ。
どのステップで時間がかかっているのか、本当にインデックスが使われているのか、使われているなら効率的に使われているのか、といったことを確認できる。SQLチューニングの基本中の基本だから、必ず実行する癖をつけておこう。

—

まとめ：空間インデックスを使いこなして、アプリのパフォーマンスを一段引き上げよう！

今日はPostgreSQLの空間インデックス、GiSTとSP-GiSTについて、その仕組みから具体的な使い方、そして実務での使い分けまで、たっぷり解説してきた。

GiSTインデックス: R-treeベースで、多様なジオメトリ型に対応するオールラウンダー。範囲検索や近傍検索で広く活躍する。
SP-GiSTインデックス: 四分木などの空間分割構造で、特に大量の点データ検索に強みを発揮する可能性がある。

どちらのインデックスも、空間データの検索性能を劇的に向上させるための強力な武器だ。
最初はちょっと難しく感じるかもしれないが、実際に手を動かして、`EXPLAIN ANALYZE`でその効果を肌で感じてみることが、理解を深める一番の近道だ。

君のアプリケーションが、ユーザーの位置情報に基づいて最適な情報を提供したり、広大な地図の中から必要なデータだけを瞬時に見つけ出したり…そんな未来を、これらの空間インデックスがきっと実現してくれるはずだ。
さあ、今日学んだ知識を活かして、アプリのパフォーマンスを一段階引き上げてやろうじゃないか！

何か疑問があれば、いつでも聞いてくれよな！
じゃあ、また次の記事で会おう！