PostgreSQL はJSONBを導入したばかりで、すでにハッカー ニュースで話題になっています。以前に PostgreSQL に存在した Hstore および JSON との違いは何ですか?
その利点と制限は何ですか? また、いつ使用を検討する必要がありますか?
ピーユッシュ:
簡単な答えは次のとおりです。
より長い回答については、私が 9.4 リリースに近づいて完全な「ハウツー」の記事を作成するまで待つ必要があります。
hstore
より「ワイドカラム」ストレージタイプであり、キーと値のペアのフラットな (ネストされていない) ディクショナリであり、常に合理的に効率的なバイナリ形式 (ハッシュテーブル、したがって名前) で格納されます。json
JSON ドキュメントをテキストとして保存し、ドキュメントの保存時に検証を実行し、必要に応じて出力時に解析します (つまり、個々のフィールドにアクセスします)。JSON 仕様全体をサポートする必要があります。JSON テキスト全体が保存されるため、そのフォーマットは保持されます。jsonb
パフォーマンス上の理由からショートカットを使用します。JSON データは入力時に解析され、バイナリ形式で保存されます。辞書内のキーの順序は維持されず、キーの重複もありません。JSONB フィールドの個々の要素へのアクセスは、JSON テキストを常に解析する必要がないため高速です。出力時に、JSON データが再構築され、初期のフォーマットが失われます。IMO、機械可読データを使用している場合、利用可能になったら使用しない重大な理由はありません。jsonb
私は今日PostgresOpenに参加しましたが、ベンチマークはMongoDBよりもはるかに高速です。select の方が約 500% 高速だったと思います。MongoDB と比較すると、少なくとも 200% 高速でした。それから、現在の 1 つの例外は、JSON 列全体を完全に書き直す必要がある更新です。これは、MongoDB がより適切に処理できるものです。
JSONB での gin のインデックス作成は素晴らしいですね。
また、PostgreSQL は JSONB の型を内部的に保持し、基本的にこれを数値、テキスト、ブール値などの型と一致させます。
JSONB を使用した結合も可能になります。
ストアド プロシージャに PLv8 を追加すると、これは基本的にNode.js開発者にとって夢の実現です。
バイナリとして保存されるため、JSONB はすべての空白を削除し、プロパティの順序を変更し、最後に出現したプロパティを使用して重複するプロパティを削除します。
JSON 列とは対照的に、JSONB 列に対してクエリを実行するときのインデックスに加えて、PostgreSQL はすべての行でテキストを JSON に変換する機能を実際に実行する必要がないため、単独で膨大な時間を節約できる可能性があります。
私の知る限り、
現在 (PostgreSQL 9.3 に) 存在する hstore では、キーと値のペアの値として他のオブジェクトや配列をネストすることはできません。ただし、将来の hstore パッチではネストが可能になります。このパッチは 9.4 リリースには含まれず、すぐには含まれない可能性があります。
現在存在する json ではネストが許可されていますが、テキストベースであり、インデックス作成が許可されていないため、「遅い」です。
9.4 でリリースされる jsonb には、json の現在のネスト機能と、hstore の GIN/GIST インデックスが含まれているため、高速になります。
PostgreSQL 9.4 に取り組んでいる人々は、MongoDBのようなNoSQLデータ ストアを使用することを選択した人々にとって、新しい高速な jsonb タイプが魅力的であると言っているようですが、リレーショナル データベースとクエリ可能な非構造化データを 1 つの屋根の下で組み合わせることができるようになりました。
HStore2/jsonb が 9.4 の最も重要なパッチである理由
PostgreSQL 9.4 jsonb のベンチマークは、MongoDB と同等か、場合によってはそれよりも速いようです。
http://texture.io/alphabetum/postgresql-incl-hstore-vs-mongodb