やあ。最近、PostgreSQLの設計レビューをしていて、「あ、ここ配列型を使えばもっと綺麗に書けるのに」とか「インデックスの貼り方を間違えて沼にハマってるな」と感じることが多いんだよね。
PostgreSQLの配列型（`ARRAY`）って、正直「正規化の原則」から見ると少し異端児扱いされがちなんだけど、適切に使えばRDBの柔軟性を爆発的に引き上げることができる強力な武器なんだ。今日は、実務で現場のエンジニアが躓きやすい「配列とインデックス」の話を、少し深掘りしてみようと思う。
—
1. なぜ配列型とGINインデックスが必要なのか
まず大前提として、配列型を使う理由は「スキーマの動的な拡張」や「1対多の密な関係を1行で表現したい」ときだよね。
例えば、ユーザーが持つ「興味のあるタグ」や「アクセス権限のリスト」を別のテーブルに切り出すと、JOINだらけでクエリが重くなる。そんな時に配列型が輝くわけだ。でも、普通に `SELECT FROM users WHERE tags = ‘{“golang”}’` なんてやっても、全件走査（シーケンシャルスキャン）で死ぬ。
ここで登場するのが GIN (Generalized Inverted Index) インデックスだ。
— GINインデックスの作成
CREATE INDEX idx_users_tags ON users USING GIN (tags);
GINインデックスは、簡単に言えば「配列の中身をバラして、単語帳のように逆引きインデックスを作る」仕組み。これがあるだけで、検索速度は桁違いになる。
2. 包含演算子 `@>` を使いこなす
配列検索で一番よく使うのが、包含演算子 `@>` だ。「左側の配列に、右側の配列の要素が含まれているか？」を判定する。
— ‘golang’ を含むレコードを爆速で検索
SELECT FROM users WHERE tags @> ARRAY[‘golang’];
これ、初心者がやりがちなミスとして「`tags @> ‘{golang}’::text[]`」のようにキャストを忘れてクエリプランが狂うケースがある。PostgreSQLは型に厳しいから、しっかり `ARRAY[]` コンストラクタを使うか、キャストを明示する癖をつけておこう。
ちなみに、`&&`（オーバーラップ演算子）も便利だ。「配列同士に共通要素があるか？」を判定するんだけど、これもGINインデックスが効く。タグの推奨システムなんかを作る時は、この辺りの演算子が命綱になるよ。
3. 多次元配列の罠と実務的な向き合い方
「多次元配列を使えば、もっと高度なデータが持てるのでは？」なんて思うかもしれないけど、ちょっと待ってほしい。
PostgreSQLは多次元配列（`int[][]` みたいやつ）をサポートしてるけど、インデックスの恩恵を受けにくいという現実があるんだ。GINインデックスは基本的に「フラットな要素」の検索に最適化されているから、多次元になるとクエリの書き方も複雑になるし、パフォーマンスも安定しにくい。
現場の経験則で言うと、多次元配列が必要になった時点で、それは配列型でやるべき設計じゃない。 潔く別テーブルに切り出して、リレーションを貼る設計に切り替えるのが、結果的にシステムの寿命を延ばすことになるよ。
4. 最後に：インデックスは「魔法」じゃない
GINインデックスを貼る時の注意点をもう一つ。
GINは読み取り（検索）には最強だけど、書き込み（INSERT/UPDATE）のコストはかなり重いんだ。配列の中身が変わるたびに、インデックスのツリーを再構築するような動きをするからね。
- 頻繁に更新されるカラムなのか？
- 読み取りがメインのログデータやタグ付けデータなのか？
このバランスを考えずに「とりあえずGIN貼っとけ」とやると、後で書き込み負荷で泣くことになる。ここだけは、ぜひ設計段階で意識しておいてくれ。
—
配列型は、PostgreSQLという「RDBの皮を被った多目的ツール」の象徴みたいな機能だ。うまく付き合えば、複雑なSQLを劇的にシンプルにできる。
もし「この設計で本当にいいのかな？」と迷ったら、まずは `EXPLAIN ANALYZE` を叩いて、インデックスがちゃんと使われているか確認するところから始めよう。エンジニアの腕の見せ所は、いつだってその「確認」の先にあるんだから。
それじゃ、また現場で会おう。良いデータベースライフを！
コメント