JSONB時代の今、あえて「hstore」を語る意味
最近のPostgreSQL界隈では、JSONBが完全に市民権を得ていますよね。スキーマレスなデータ構造をリレーショナルな世界に持ち込むならJSONB一択、というのが現在の定石です。
でも、ベテランのエンジニア諸氏なら一度は経験があるはずです。「あ、ここはJSONBほど複雑なネストはいらないな」とか「単なるキー・値のフラットなペアさえあれば十分なんだよな」というシーン。そんな時、古くからある拡張モジュール `hstore` が、実は極めて渋い仕事をしてくれることをご存知でしょうか。
今日は、あえて今、`hstore` の内部アーキテクチャに少し深く潜り込み、なぜこれが依然として「使える」選択肢なのかを紐解いていきたいと思います。
—
hstoreの内部構造：なぜ「速い」のか
`hstore` は、キーと値のペアを単一のカラムに詰め込むためのモジュールです。内部的には、これらは基本的に「ハッシュマップ」として管理されています。
特筆すべきは、その物理的な格納形式です。`hstore` は、格納されたデータをソート済みの配列として保持します。これにより、特定のキーに対する検索（`->` 演算子など）は、単なる全走査ではなく、二分探索に近い効率で処理されます。
構造的な特徴と注意点
- フラットな構造: JSONBが木構造を許容するのに対し、hstoreはあくまで「キーと値」の1階層のみ。この制限が、逆にパフォーマンスの一貫性を生んでいます。
- メモリ配置: 多くの場合はインラインで格納されますが、データが大きくなるとTOAST領域へ追い出されます。この挙動はJSONBと似ていますが、パースコストが非常に低い点がhstoreの強みです。
—
現場で遭遇する「hstore特有」のパフォーマンストラブル
JSONBよりも単純だからといって、運用を甘く見てはいけません。実際に本番環境で運用していて、僕が頭を抱えたポイントを共有します。
1. GINインデックスの肥大化
hstoreを多用するテーブルで最も多いのが、GINインデックスの爆発です。`CREATE INDEX … USING GIN (col)` を行うと、すべてのキーと値の組み合わせがインデックス化されます。
特に、値の種類が極めて多い（カーディナリティが高い）データを突っ込むと、インデックスの更新コストが書き込み性能を著しく劣化させます。
教訓: 「とりあえず全部インデックス」は禁物。必要なキーだけを抽出する `expression index` を活用するか、本当にそのキーでの検索が必要か、今一度スキーマを見直すべきです。
2. `hstore` vs `jsonb` の変換コスト
たまに「JSONBに移行したいから」といって、アプリケーション層でhstoreとJSONBの変換を頻繁に行っているコードを見かけます。これ、PostgreSQLの内部では意外と無視できないオーバーヘッドになります。
もし既存のシステムでhstoreを使い続けているなら、無理にJSONBへ移行するよりも、hstoreで完結させる方が、型変換のオーバーヘッドを抑えられるという側面もあります。
—
結局、今どう使い分けるべきか
私の結論はこうです。
- JSONBを選ぶべきケース:
- ネストしたデータ構造が必要。
- 値の型（数値、ブール値、NULL）を厳密に区別したい。
- 演算子や関数をフル活用した複雑なクエリを書く。
- hstoreを選ぶべきケース:
- キーと値は常に文字列であり、構造がフラット。
- 読み取り性能が極めて重要で、かつ「型」のパースコストすら惜しい単純な辞書データ。
- 既存のレガシーシステムで、すでにhstoreで運用が回っている。
—
最後に：ツールに振り回されないために
技術のトレンドを追うことは重要ですが、アーキテクチャの根底にある「なぜそのデータ構造なのか」という設計思想を理解することは、もっと重要です。
`hstore` は、PostgreSQLの拡張性の歴史を物語る、非常に洗練された「道具」です。最新のJSONBという強力な武器がある今だからこそ、あえて古い武器の切れ味を再確認してみる。そんな作業が、データベースエンジニアとしての引き出しを、もう一段深くしてくれるのではないかと思っています。
皆さんの現場では、まだhstoreは現役で頑張っていますか？ もし興味深いハマりどころや、独自の活用術があれば、ぜひ聞かせてください。
コメント