PostgreSQLのJSONBとどう付き合うか：関数という名の「外科手術」を極める
PostgreSQLの `JSONB` が登場したとき、RDBMSの世界は大きく変わりました。それまで「リレーショナルであること」と「スキーマレスであること」は水と油でしたが、PostgreSQLはそれを同じテーブルの中に共存させるという、ある種の魔法を実現したわけです。
しかし、現場で多くのデータベースを診断していると、JSONBを単なる「ゴミ箱」として使い、クエリのたびに壊滅的なパフォーマンス低下を招いているケースをよく目にします。JSONBは強力ですが、その内部構造を理解せずに関数を叩くと、それは「データに対する外科手術」を麻酔なしで行うようなものです。
今日は、JSONBを扱う際に避けては通れない主要関数たちを、エンジニアの視点で深掘りしてみましょう。
—
変換の美学：構造をどう組み立てるか
データモデリングにおいて、アプリ側でJSONを組み立ててDBに投げ込むのはよくあるパターンですが、DB側で直接整形したい場面も多いはずです。
jsonb_build_object と jsonb_object_agg
これらは「動的なJSON構築」における最強の武器です。
特に `jsonb_object_agg(key, value)` は、集計クエリ（GROUP BY）の中で非常に強力に機能します。
- アーキテクチャのヒント: `jsonb_object_agg` は集計関数なので、内部的には状態遷移関数として動作します。大量のレコードを対象にする場合、ハッシュ集計が効くかどうかが勝負です。もし集計対象が数百万行を超えるなら、一時的なメモリ消費（work_mem）を考慮し、適切にインデックスを利用したスキャンを先行させるべきです。
jsonb_strip_nulls
「NULLを含めない」という要件は、APIのレスポンス設計で頻出します。
`jsonb_strip_nulls` は便利ですが、再帰的な処理であることに注意してください。深いネスト構造を持つJSONBに対して頻繁に実行すると、CPUサイクルを想像以上に食いつぶします。クエリの投影時に都度適用するのではなく、データ書き込み時のトリガーや、あるいはアプリケーション層でのフィルタリングを検討する方が、長期的なスケーラビリティには貢献するはずです。
—
展開と更新：内部構造への介入
JSONBはバイナリ形式で保持されています。したがって、値の変更には「パース→再構築」というコストが必ず伴います。
jsonb_array_elements の罠
この関数は、配列を展開して別々の行（Row）として出力します。
SELECT FROM my_table, jsonb_array_elements(data->’items’) AS item;
この書き方は、一見すると便利ですが、内部的には `LATERAL` 結合として機能します。もしこの結果に対してフィルタリングをかけるなら、必ずGINインデックスを併用してください。そうしないと、PostgreSQLはフルスキャンを選択し、数万行のJSONB配列をすべてメモリ上で展開するという「地獄」を見る羽目になります。
jsonb_set：外科手術の難しさ
特定のパスの値を書き換える `jsonb_set` は、非常に強力ですが、やりすぎると「断片化」を招きます。
PostgreSQLの更新処理はMVCC（多版同時実行制御）に基づいています。大きなJSONBの一部を `jsonb_set` で更新するたびに、そのJSONB全体が「新しいバージョン」として書き込まれます。
- トラブルシューティング: 更新頻度が高いJSONBフィールドがある場合、テーブル全体がBloat（肥大化）しやすくなります。もし頻繁に更新が必要な項目があるなら、それはJSONBに入れるべきではない「正規化が必要なデータ」かもしれません。
—
パフォーマンスの極意：インデックスをどう効かせるか
JSONBの操作関数を多用するクエリを最適化する際、インデックス設計で一番やってはいけないのは「関数インデックスに頼りすぎること」です。
例えば `jsonb_set` や `jsonb_strip_nulls` を含んだ複雑な計算式でインデックスを作ると、オプティマイザは統計情報をうまく使えなくなります。基本は以下のルールを守ってください。
1. GINインデックス（jsonb_path_ops）: 検索対象が特定のキーや値なら、まずはこれ。
2. パス指定のインデックス: `CREATE INDEX ON table ((data->>’id’))` のように、頻繁にアクセスするパスを個別に切り出す。JSONB全体を検索するより遥かに高速です。
3. 統計情報の更新: JSONBは構造が複雑なため、`ANALYZE` が統計を誤ることがあります。必要に応じて `ALTER TABLE … SET STATISTICS` を調整し、頻出するキーの密度をDBに教えてやることも、熟練のエンジニアの嗜みです。
—
最後に：JSONBは「最後の切り札」
JSONBは、スキーマ設計が困難な場面や、疎なデータを扱うための「最後の切り札」です。しかし、RDBMSとしての規律を放棄していいわけではありません。
関数を使ってJSONを自在に操れることは技術的な自信になりますが、本当にそのデータをJSONで持つべきか？という問いを常に持ち続けてください。SQLの美しさと、JSONの柔軟性。その二つの境界線をどこに引くかこそが、データベースエンジニアとしての腕の見せ所だと思いませんか。
現場のコードが、少しでも軽快に動くことを願っています。また別のトピックでお会いしましょう。
コメント