【テクニカル・上級編】配列型 (Array Types) – PostgreSQL

PostgreSQLを長く触っていると、一度は「配列型（Array Types）」の誘惑に駆られるはずです。「正規化して別テーブルに切り出すまでもない、この1対多の関係を一つのカラムに押し込めないか？」という、あの甘美な誘惑です。

確かに、PostgreSQLの配列型は強力です。柔軟で、記述も簡潔。しかし、データベースの深淵を覗くエンジニアとしては、単なる「便利な入れ物」として扱うのは少し危険だと感じています。今日は、配列型の内部構造と、パフォーマンスという現実的な壁について、少し突っ込んだ話をしましょう。

—

まず理解しておくべきは、PostgreSQLにおいて配列がどのように格納されているかです。

配列は、PostgreSQLの「可変長データ型（varlena）」として実装されています。内部的には、データの先頭にヘッダー情報（次元数、要素数、NULLビットマップ、データ型OIDなど）が配置され、その後に各要素がメモリ上に連続して並ぶ構造をとっています。

ここで重要なのは、「配列の要素に対するインデックス検索は、デフォルトでは不可能」という点です。配列全体を一つの値として扱う限り、B-treeインデックスは単なる「配列の比較」しか行えません。これでは検索エンジンとしてあまりに非力です。

配列を活用するなら、避けて通れないのが「GIN（Generalized Inverted Index）」です。

配列内の各要素に対してインデックスを張るには、`CREATE INDEX … USING GIN` が必須です。GINは配列の各要素を「トークン」として分解し、転置インデックスを作成します。これにより、`@>`（包含演算子）や `&&`（重複演算子）を使ったクエリが劇的に高速化します。

しかし、ここで注意が必要なのが「インデックスの肥大化」です。要素数が多い配列を大量に格納すれば、GINインデックスは指数関数的に膨らみ、更新時のオーバーヘッドは無視できないレベルに達します。書き込み頻度が高いテーブルでの乱用は、データベースのパフォーマンスを確実に蝕みます。

PostgreSQLは `int[][]` のような多次元配列も許容します。一見すると行列計算やグリッドデータの保持に最適に見えますが、実際の現場ではどうでしょうか。

私の経験上、多次元配列は「クエリの複雑性」という代償を伴います。
例えば、特定の次元を抽出したり、要素を入れ替えたりする操作は、SQLレベルでは非常に記述が困難です。結局、アプリケーション側でパースする羽目になり、DB側でのバリデーションも効きにくくなる。

「DBが何であるか」を考えれば、多次元配列はあくまで「読み取り専用に近い静的データ」の保持に留めるのが、精神衛生上もパフォーマンス上も賢明です。

もし、あなたが「配列を使ったクエリが遅い」というトラブルに直面しているなら、まずは以下の3点を確認してみてください。

`WHERE array_col @> ‘{100}’` は速いですが、配列の中身に対して関数を噛ませたり、配列の特定の添字に対して操作を行うと、インデックスは即座に無効になります。

配列はデータサイズが大きくなりがちです。頻繁に更新される配列カラムは、テーブルのページ分割を誘発し、HOT更新を阻害します。結果、Vacuumの負荷が増大し、テーブル全体がフラグメント化します。

`text[]` を使うより、定型的なデータなら `enum[]` や、小さい数値なら `int2[]` を検討してください。メモリ上での連続したバイト列が小さくなれば、それだけTOAST（大規模データ格納領域）に追い出される確率を減らせます。

—

配列型は、RDBの純粋主義（Normalization）に対する、非常に実用的な妥協点です。しかし、その利便性に甘えて「何でも配列に突っ込む」ようになると、将来的に必ず技術的負債として跳ね返ってきます。

「この配列は、本当に検索の対象になるのか？」「更新頻度はどれくらいか？」「データサイズはTOASTに落ちるほど肥大化しないか？」

これらを自問自答した上で、正しく設計された配列型は、極めて強力な武器になります。PostgreSQLの器の大きさを活かすも殺すも、最後は我々エンジニアの設計センスに委ねられているのです。

皆さんの設計が、パフォーマンスという名の神に祝福されることを願っています。それでは、また。