web-dev-qa-db-ja.com

PostgreSQLによるJSONBの紹介

PostgreSQLが導入したばかりの JSONB 、すでに ハッカーニュース の傾向にあります。 PostgreSQLに以前から存在していたHstoreやJSONとはどう違うのかを誰かが説明できたら素晴らしいでしょう。それの利点と制限は何ですか、そして誰かがそれを使うことをいつ検討すべきですか?

277
Peeyush

まず、 hstore は、key => valueのペアのみを格納できるcontribモジュールです。ここで、キーと値はtextsにしかできません(ただし、値はSQL NULLsでもあります。

jsonjsonbの両方で、有効なJSONspec で定義されている)を格納できます。

F.ex.これらは有効なJSON表現です:nulltrue[1,false,"string",{"foo":"bar"}]{"foo":"bar","baz":[null]} - hstoreは、JSONが対応しているものと比べてほんの少しのサブセットです(ただし、このサブセットのみが必要な場合は問題ありません)。

jsonjsonbの唯一の違いはそれらのストレージです:

  • jsonはプレーンテキスト形式で保存されますが、
  • jsonbは何らかのバイナリ表現で格納されています

これには3つの大きな影響があります。

  • jsonbは通常jsonよりも多くのディスク容量を格納するために消費します(時々そうではありません)
  • jsonbjsonより入力表現から構築するのにより多くの時間がかかります
  • json操作は、jsonbよりもかなり時間がかかります(json型の値で何らかの操作を行うたびに、解析も実行する必要があります)。

jsonbが安定版リリースで利用可能になるとき、あなたがそれらの間で簡単に選択できるとき、2つの主要なユースケースがあるでしょう:

  1. アプリケーションでJSON表現のみを扱う場合、PostgreSQLはこの表現の格納と取得にのみ使用されます。jsonを使用する必要があります。
  2. PostgreSQLのJSON値に対して多くの操作を行う場合、または何らかのJSONフィールドでインデックスを使用する場合は、jsonbを使用する必要があります。
392
pozs

Peeyush:

簡単な答えは:

  • ソート、スライス、スプライシングなど、たくさんのJSON操作insidePostgreSQLを使用している場合は、速度上の理由からJSONBを使用する必要があります。
  • JSONで任意のキーを検索するために索引付き検索が必要な場合は、JSONBを使用してください。
  • 上記のどちらでもない場合は、おそらくJSONを使用する必要があります。
  • キーの順序、空白、および重複キーを保持する必要がある場合は、JSONを使用してください。

もっと長い答えを出すには、9.4リリースに近い「HowTo」の完全な記事を書くのを待つ必要があります。

109
FuzzyChef

Jsonとjsonbの違いの簡単な説明( PostgresProfessionalによるオリジナル画像 ):

SELECT '{"c":0,   "a":2,"a":1}'::json, '{"c":0,   "a":2,"a":1}'::jsonb;

          json          |        jsonb 
------------------------+--------------------- 
 {"c":0,   "a":2,"a":1} | {"a": 1, "c": 0} 
(1 row)
  • json:テキスト形式のストレージ"現状のまま"
  • jsonb:空白はありません
  • jsonb:重複キーはありません、最後のキーの獲得
  • jsonb:キーはソートされています

Jsonb開発者による スピーチビデオ および スライドショープレゼンテーション の詳細。また彼らはJsQueryを導入し、pg.extensionは強力なjsonbクエリ言語を提供します。

53
ChelowekKot
  • hstoreは「ワイドカラム」のストレージタイプで、キーと値のペアのフラットな(ネストされていない)ディクショナリです。常に効率的なバイナリ形式(ハッシュテーブル、したがって名前)で格納されます。
  • jsonはJSONドキュメントをテキストとして保存し、ドキュメントが保存されたときに検証を行い、必要に応じてそれらを出力時に解析します(つまり個々のフィールドへのアクセス)。 JSON仕様全体をサポートするはずです。 JSONテキスト全体が保存されているので、そのフォーマットは維持されます。
  • パフォーマンス上の理由からjsonbはショートカットを使用します。JSONデータは入力で解析され、バイナリ形式で格納され、辞書内のキーの順序は維持されず、重複キーもありません。 JSONテキストを常に解析する必要がないため、JSONBフィールドの個々の要素にアクセスするのは高速です。出力時には、JSONデータは再構築され、初期フォーマットは失われます。

機械可読データを扱う場合、IMOでは、利用可能になった時点でjsonbを使用しないしないのための重要な理由はありません。

48
Ivan Voras

私は今日pgopenにいましたが、ベンチマークはmongodbよりはるかに速いのですが、selectの方が約500%速くなったと思います。 mongodbと比較した場合、ほぼすべてが少なくとも200%高速化されました。ただ1つの例外は、mongodbが処理するjson列全体を完全に書き換える必要がある更新です。

Jsonbのジンインデックスはすごいね。

またpostgresはjsonbの型を内部的に保持し、基本的に数値、テキスト、ブールなどの型とこれを一致させます。

結合もjsonbを使用して可能になります

ストアドプロシージャにPLv8を追加すると、これは基本的にnode.js開発者にとって夢のようになります。

バイナリのjsonbとして保存されているため、空白もすべて削除され、プロパティの順序が変更され、最後に出現したプロパティを使用して重複したプロパティが削除されます。

Jsonbカラムに対してクエリするときのインデックスの他に、jsonカラムと対比されます。postgresは実際にすべての行でテキストをjsonに変換する機能を実行する必要はありません。

12
John

jsonbはJSONの「より良い」バージョンです。例を使って確認しましょう。

Comparison by Professional Postgres

  1. JSONは空白を格納します。キー "a"が格納されているときに空白が表示されるのに対して、JSONBは格納されません。
  2. JSONはkeyのすべての値を格納します。これが、JSONBが最後の値のみを「格納する」のに対し、キー「a」に対して複数の値(2と1)を表示できる理由です。
  3. JSONBは「ソートされた」順序を維持しながら、JSONは要素が抑制される順序を維持します。
  4. JSONBオブジェクトは、検索時にデータの再解析が不要なJSONの「生データ」とは対照的に、解凍されたバイナリとして格納されます。
  5. JSONBは索引付けもサポートしています。これは大きな利点です。

一般に、オブジェクトキーの順序付けに関するレガシーな仮定など、非常に特殊なニーズがある場合を除き、JSONBをお勧めします。

6
subodhkarwa

私の知る限り、

  • 現在存在しているhstore(Postgresql 9.3)では、他のオブジェクトや配列をそのキー/値ペアの値としてネストすることはできません。しかし、将来のhstoreパッチは入れ子にすることを可能にするでしょう。このパッチは9.4リリースには含まれず、近いうちに含まれる予定もありません。

  • 現在存在するjsonは入れ子を許可しますができますが、テキストベースであり、索引付けは許可されていないため、「低速」です。

  • 9.4でリリースされるjsonbには、jsonの現在のネスト機能、およびhstoreのGIN/Gistインデックスがあるため、高速になります。

Postgresql 9.4を扱っている人たちは、新しい、速いjsonbタイプがMongoDBのようなnoSQLデータストアを使うことを選んだ人たちに訴えるだろうと言っているように見えます。

http://www.databasesoup.com/2014/02/why-hstore2jsonb-is-most-important.html

Postgresql 9.4 jsonbのベンチマークは、MongoDBと同等かそれより速い場合があります。

http://texture.io/alphabetum/postgresql-incl-hstore-vs-mongodb

6
erik swedberg

他の重要な違いは、上記のどの回答にも記載されていませんが、json型には等価演算子がありませんが、jsonbには等価演算子があることです。

つまり、テーブルからこのDISTINCTtypeや他のフィールドを選択するときにjsonキーワードを使用することはできません(代わりにDISTINCT ONを使用することもできますが、 のような理由で常に可能とは限りません。 ).

1
vlasiak