【テクニカル・上級編】 JSONB型 – PostgreSQL

PostgreSQLを長年触っていると、必ず一度は「JSONBを使うべきか、それとも従来のRDB的な正規化を貫くべきか」という問いに直面します。

かつては「JSONをDBに突っ込むなんて邪道だ」という風潮もありましたが、PostgreSQLのJSONBはもはや単なる「テキストの保管場所」ではありません。適切に扱えば、それはRDBの堅牢性とNoSQLの柔軟性を併せ持つ、最強の武器になります。

今日は、JSONBが内部でどのように息づいているのか、そしてそれを現場でどう飼い慣らすかについて、少し深い話をしようと思います。

—

JSONB（Binary JSON）の最大の強みは、その名が示す通り「バイナリ形式」で保持される点にあります。

テキストとして保存されるJSON型とは異なり、JSONBはパース済みの状態で格納されます。検索のたびに `json_parse` が走るような非効率なことは起きません。内部的には、キーと値のペアがソートされた状態で保存されており、これによってバイナリ検索（二分探索）が可能になっています。

この「静的な構造」こそが、JSONBがRDBの型システムの中で違和感なく共存できる理由です。

—

JSONBを実戦投入する際、最も頭を悩ませるのがインデックスです。ここで「とりあえずGINインデックスを貼ればいいや」と安易に考えていると、思わぬ落とし穴にハマります。

JSONBのキーと値をすべてインデックス化する `jsonb_path_ops` を使うか、デフォルトの `jsonb_ops` を使うか。

`jsonb_ops`: キーと値の両方をインデックス化。汎用性は高いが、インデックスサイズが肥大化しやすい。
`jsonb_path_ops`: キーと値のハッシュを格納。インデックスサイズが小さくなり、特定パスへの検索はデフォルトより高速だが、`@>`（包含演算子）以外の検索ができないという制約がある。

大規模データセットを扱うなら、迷わず `jsonb_path_ops` を検討してください。ストレージとクエリ効率のトレードオフを計算できるのが、熟練エンジニアの腕の見せ所です。

「特定のステータスを持つJSONBレコードだけ検索対象にしたい」といったケースでは、インデックスに `WHERE` 句を組み込みましょう。

CREATE INDEX idx_user_metadata ON users USING GIN ((metadata->’tags’)) WHERE metadata->>’active’ = ‘true’;

これだけで、インデックスサイズを劇的に圧縮しつつ、クエリプランナの迷いを消し去ることができます。

—

JSONBの運用で泣きを見ないために、以下のチェックポイントを脳内に刻んでおいてください。

一つのカラムに数メガバイトのJSONを詰め込んでいませんか？ PostgreSQLのTOASTテーブルに追いやられたデータは、アクセスするたびにI/O負荷を増大させます。頻繁に検索するキーがあるなら、それはJSONBから切り出して「普通のカラム」に昇格させるべきです。

`@>` (包含) と `?` (キーの存在確認) はGINインデックスを活用できますが、`->>` による抽出はインデックスをフル活用できないことがあります。実行計画（`EXPLAIN ANALYZE`）を見て、Seq Scanが発生していないかを常に監視してください。

JSONBはバイナリです。一部の値を更新する際も、基本的にはレコード単位の書き換え（Tupleの更新）が発生します。頻繁な更新と巨大なJSONBの組み合わせは、MVCCのオーバーヘッドを増大させ、Bloat（肥大化）の原因となります。

—

JSONBは、いわば「RDBという重厚な城の中にある、便利な隠し部屋」です。

すべてをJSONBにする必要はありません。堅牢なスキーマが必要な部分はテーブルのカラムとして定義し、進化の速いデータや構造が予測できない属性値だけをJSONBに任せる。この「ハイブリッド・アプローチ」こそが、長期運用において最もメンテナンスコストの低い設計になります。

技術は常にトレードオフの連続です。JSONBの便利さに溺れることなく、その内部構造を理解し、クエリプランナの意図を汲み取れるエンジニアであり続けたいですね。

それでは、良いデータモデリングライフを。