Erklärung von JSONB, eingeführt von PostgreSQL

Question

PostgreSQL hat gerade JSONB in Version 9.4 eingeführt, und es ist bereits ein Trend auf Hacker News. Was unterscheidet es von Hstore und JSON, die zuvor in PostgreSQL vorhanden waren?

Was sind seine Vorteile und Einschränkungen und wann sollte man darüber nachdenken, es zu verwenden?

Answer 1

Zunächst handelt es sich bei hstore um ein Contrib-Modul, das es nur ermöglicht, Schlüssel-Wert-Paare zu speichern, wobei sowohl die Schlüssel als auch die Werte nur text-Werte sein können (die Werte können jedoch auch sql NULL-Werte sein).

Sowohl json als auch jsonb ermöglichen es Ihnen, einen gültigen JSON-Wert zu speichern (definiert in dessen Spezifikation).

Zum Beispiel sind dies gültige JSON-Repräsentationen: null, true, [1,false,"string",{"foo":"bar"}], {"foo":"bar","baz":[null]} - hstore ist nur ein kleiner Teil im Vergleich zu dem, wozu JSON fähig ist (aber wenn Sie nur diesen Teil benötigen, ist das in Ordnung).

Der einzige Unterschied zwischen json und jsonb liegt in deren Speicherung:

• json wird im reinen Textformat gespeichert, während
• jsonb in einer binären Repräsentation gespeichert wird

Daraus ergeben sich 3 Hauptkonsequenzen:

• jsonb benötigt normalerweise mehr Speicherplatz zum Speichern als json (manchmal nicht)
• jsonb benötigt mehr Zeit, um aus seiner Eingangsrepräsentation aufgebaut zu werden als json
• json-Operationen dauern signifikant länger als jsonb (& das Parsen muss auch jedes Mal erfolgen, wenn Sie eine Operation an einem als json getypten Wert vornehmen)

Wenn jsonb mit einer stabilen Version verfügbar ist, wird es zwei Hauptanwendungsfälle geben, zwischen denen Sie leicht wählen können:

1. Wenn Sie nur mit der JSON-Repräsentation in Ihrer Anwendung arbeiten und PostgreSQL nur zum Speichern und Abrufen dieser Repräsentation verwendet wird, sollten Sie json verwenden.
2. Wenn Sie viele Operationen am JSON-Wert in PostgreSQL durchführen oder Indizierungen auf einem JSON-Feld verwenden, sollten Sie jsonb verwenden.

Answer 2

Peeyush:

Die kurze Antwort ist:

• Wenn Sie innerhalb von PostgreSQL viele JSON-Manipulationen wie Sortieren, Slicing, Splicing usw. durchführen, sollten Sie aus Gründen der Geschwindigkeit JSONB verwenden.
• Wenn Sie indizierte Suchvorgänge für beliebige Schlüsselsuchen in JSON benötigen, sollten Sie JSONB verwenden.
• Wenn Sie keines der oben genannten Kriterien erfüllen, sollten Sie wahrscheinlich JSON verwenden.
• Wenn Sie die Schlüsselreihenfolge, Leerzeichen und doppelte Schlüssel beibehalten müssen, sollten Sie JSON verwenden.

Für eine ausführlichere Antwort müssen Sie auf meine vollständige "HowTo"-Anleitung warten, die näher an der Veröffentlichung von 9.4 liegt.

Answer 3

Eine einfache Erklärung des Unterschieds zwischen json und jsonb (Originalbild von 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: textuelle Speicherung "wie vorliegend"
• jsonb: keine Leerzeichen
• jsonb: keine doppelten Schlüssel, der letzte Schlüssel gewinnt
• jsonb: Schlüssel sind sortiert

Mehr in Videovortrag und Präsentation der Dia-Show von den jsonb-Entwicklern. Außerdem haben sie JsQuery eingeführt, eine pg.extension, die die leistungsstarke jsonb-Abfragesprache bereitstellt.

Answer 4

• hstore ist eher ein "wide column" Speichertyp, es handelt sich um ein flaches (nicht geschachteltes) Wörterbuch von Schlüssel-Wert-Paaren, das immer in einem relativ effizienten binären Format gespeichert wird (eine Hash-Tabelle, daher der Name).
• json speichert JSON-Dokumente als Text, führt Validierung durch, wenn die Dokumente gespeichert werden, und analysiert sie bei Bedarf auf Ausgabe (d. h. Zugriff auf einzelne Felder); es sollte die gesamte JSON-Spezifikation unterstützen. Da der gesamte JSON-Text gespeichert wird, bleibt das Format erhalten.
• jsonb umgeht aus Leistungsgründen bestimmte Schritte: JSON-Daten werden beim Eingabe geparst und im binären Format gespeichert, die Reihenfolge der Schlüssel in Wörterbüchern wird nicht beibehalten, ebenso wenig wie doppelte Schlüssel. Der Zugriff auf einzelne Elemente im JSONB-Feld ist schnell, da nicht ständig der JSON-Text analysiert werden muss. Bei der Ausgabe werden die JSON-Daten rekonstruiert und das ursprüngliche Format geht verloren.

Meiner Meinung nach gibt es keinen signifikanten Grund dafür, nicht jsonb zu verwenden, sobald es verfügbar ist, wenn Sie mit maschinenlesbaren Daten arbeiten.

Answer 5

JSONB ist eine "bessere" Version von JSON.

Lassen Sie uns ein Beispiel ansehen:

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)

1. JSON speichert Leerzeichen, daher sehen wir Leerzeichen, wenn der Schlüssel "a" gespeichert ist, während JSONB dies nicht tut.
2. JSON speichert alle Werte eines Schlüssels. Das ist der Grund, warum Sie mehrere Werte (2 und 1) gegen den Schlüssel "a" sehen können, während JSONB nur den letzten Wert "speichert".
3. JSON bewahrt die Reihenfolge, in der Elemente eingefügt werden, während JSONB die "sortierte" Reihenfolge beibehält.
4. JSONB-Objekte werden als dekomprimierte Binärdaten gespeichert, im Gegensatz zu "rohen Daten" in JSON, bei denen keine Neuinterpretation der Daten beim Abruf erforderlich ist.
5. JSONB unterstützt auch Indexierung, was ein signifikanter Vorteil sein kann.

Im Allgemeinen sollte man JSONB bevorzugen, es sei denn, es gibt spezielle Anforderungen, wie z. B. legacy-Annahmen über die Reihenfolge von Objektschlüsseln.