Erklärung des von PostgreSQL eingeführten JSONB

Erstens ist hstore ein Contrib-Modul, mit dem Sie nur Schlüssel => Wertepaare speichern können, wobei Schlüssel und Werte nur texts sein können (Werte können es jedoch sein) sql NULLs auch).

Mit json & jsonb können Sie einen gültigen JSON-Wert speichern (definiert in dessen spec ).

ZB Dies sind gültige JSON-Darstellungen: null, true, [1,false,"string",{"foo":"bar"}], {"foo":"bar","baz":[null]} - hstore ist nur eine kleine Teilmenge im Vergleich zu den Funktionen von JSON (aber wenn Sie nur diese Teilmenge benötigen, ist dies in Ordnung).

Der einzige Unterschied zwischen json & jsonb ist ihre Speicherung:

• json wird im Nur-Text-Format gespeichert, während
• jsonb wird in einer binären Darstellung gespeichert

Hieraus ergeben sich drei wichtige Konsequenzen:

• jsonb beansprucht normalerweise mehr Speicherplatz als json (manchmal nicht)
• jsonb benötigt mehr Zeit für die Erstellung der Eingabedarstellung als json
• json -Operationen benötigen erheblich mehr Zeit als jsonb (& Parsing muss auch jedes Mal durchgeführt werden, wenn Sie eine Operation ausführen bei einem json eingegebenen Wert)

Wenn jsonb mit einer stabilen Version verfügbar sein wird, gibt es zwei Hauptanwendungsfälle, in denen Sie leicht zwischen diesen auswählen können:

1. Wenn Sie in Ihrer Anwendung nur mit der JSON-Darstellung arbeiten, wird PostgreSQL nur zum Speichern und Abrufen dieser Darstellung verwendet. Verwenden Sie json.
2. Wenn Sie in PostgreSQL viele Operationen mit dem JSON-Wert ausführen oder die Indizierung für ein JSON-Feld verwenden, sollten Sie jsonb verwenden.

Peeyush:

Die kurze Antwort lautet:

• Wenn Sie eine Menge JSON-Manipulationen durchführen innerhalb von PostgreSQL, z. B. Sortieren, Schneiden, Spleißen usw., sollten Sie aus Gründen der Geschwindigkeit JSONB verwenden.
• Wenn Sie indizierte Suchen für die Suche nach beliebigen Schlüsseln in JSON benötigen, sollten Sie JSONB verwenden.
• Wenn Sie keines der oben genannten Verfahren ausführen, sollten Sie wahrscheinlich JSON verwenden.
• Wenn Sie die Schlüsselreihenfolge, Leerzeichen und doppelte Schlüssel beibehalten müssen, sollten Sie JSON verwenden.

Um eine längere Antwort zu erhalten, müssen Sie warten, bis ich ein vollständiges "HowTo" -Report näher an der Version 9.4 geschrieben habe.

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 sie ist"
• jsonb: keine whitespaces
• jsonb: keine doppelten Schlüssel, letzter Schlüsselgewinn
• jsonb: Schlüssel werden sortiert

Mehr in Rede Video und Diashow Präsentation von jsonb-Entwicklern. Außerdem wurde JsQuery eingeführt . Pg.extension bietet eine leistungsstarke jsonb-Abfragesprache

• hstore ist eher ein Speichertyp mit "breiten Spalten", ein flaches (nicht verschachteltes) Wörterbuch mit Schlüssel-Wert-Paaren, das immer in einem einigermaßen effizienten Binärformat gespeichert ist (eine Hash-Tabelle, daher der Name). .
• json speichert JSON-Dokumente als Text, führt eine Validierung durch, wenn die Dokumente gespeichert sind, und analysiert sie bei Bedarf bei der Ausgabe (d. h. Zugriff auf einzelne Felder); Es sollte die gesamte JSON-Spezifikation unterstützen. Da der gesamte JSON-Text gespeichert wird, bleibt seine Formatierung erhalten.
• jsonb verwendet aus Leistungsgründen Verknüpfungen: JSON-Daten werden bei der Eingabe analysiert und im Binärformat gespeichert, die Schlüsselreihenfolge in Wörterbüchern wird nicht beibehalten und es werden auch keine doppelten Schlüssel verwendet. Der Zugriff auf einzelne Elemente im JSONB-Feld ist schnell, da der JSON-Text nicht ständig analysiert werden muss. Bei der Ausgabe werden JSON-Daten rekonstruiert und die anfängliche Formatierung geht verloren.

IMO, es gibt keinen wichtigen Grund, warum nichtjsonb verwendet wird, sobald es verfügbar ist, wenn Sie mit maschinenlesbaren Daten arbeiten.

Ich war heute auf der pgopen. Benchmarks sind viel schneller als Mongodb. Ich glaube, sie waren bei Selects etwa 500% schneller. Im Gegensatz zu Mongodb war fast alles um mindestens 200% schneller. Eine Ausnahme ist derzeit ein Update, bei dem die gesamte JSON-Spalte komplett neu geschrieben werden muss, was für Mongodb besser ist.

Die Gin-Indizierung auf Jsonb klingt erstaunlich.

Auch postgres werden Jsonb-Typen intern beibehalten und stimmen im Grunde mit Typen wie numerisch, text, boolesch usw. überein.

Joins sind auch mit jsonb möglich

Wenn Sie PLv8 für gespeicherte Prozeduren hinzufügen, wird dies für die Entwickler von node.j im Grunde genommen ein Traum.

Da es als binäres jsonb gespeichert wird, werden auch alle Leerzeichen entfernt, die Reihenfolge der Eigenschaften geändert und doppelte Eigenschaften unter Verwendung des letzten Vorkommens der Eigenschaft entfernt.

Außerdem muss postgres beim Abfragen einer Jsonb-Spalte im Gegensatz zu einer Json-Spalte nicht unbedingt die Funktionalität ausführen, um den Text in jeder Zeile in Json zu konvertieren, was allein sehr viel Zeit spart.

JSONB ist eine "bessere" Version von JSON.

Schauen wir uns ein Beispiel an:

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. Aus diesem Grund können Leerzeichen angezeigt werden, wenn der Schlüssel "a" gespeichert ist, während dies bei JSONB nicht der Fall ist.
2. JSON speichert alle Schlüsselwerte. Dies ist der Grund, warum Sie mehrere Werte (2 und 1) für den Schlüssel "a" sehen können, während JSONB nur den letzten Wert "speichert".
3. JSON behält die Reihenfolge bei, in der Elemente eingefügt werden, während JSONB die "sortierte" Reihenfolge beibehält.
4. JSONB-Objekte werden im Gegensatz zu "Rohdaten" in JSON als dekomprimierte Binärdateien gespeichert, bei denen beim Abrufen kein erneutes Parsen der Daten erforderlich ist.
5. JSONB unterstützt auch die Indizierung, was ein erheblicher Vorteil sein kann.

Im Allgemeinen sollte man JSONB vorziehen, es sei denn, es gibt spezielle Anforderungen, z. B. alte Annahmen zur Bestellung von Objektschlüsseln.

Soweit ich sagen kann,

• der derzeitige hstore (in Postgresql 9.3) erlaubt es nicht, andere Objekte und Arrays als Werte seiner Schlüssel/Wert-Paare zu verschachteln. Ein zukünftiger Hstore-Patch ermöglicht jedoch das Verschachteln. Dieser Patch ist nicht in der Version 9.4 enthalten und wird möglicherweise in Kürze nicht mehr verfügbar sein.

• json, wie es derzeit existiert erlaubt das Verschachteln , ist aber textbasiert und erlaubt keine Indizierung, daher ist es "langsam"

• jsonb, das mit 9.4 veröffentlicht wird, verfügt über die aktuellen Verschachtelungsfunktionen von json sowie die GIN/Gist-Indizierung von hstore, sodass es schnell gehen wird

Die Leute, die an postgresql 9.4 arbeiten, scheinen zu sagen, dass der neue, schnelle jsonb-Typ diejenigen ansprechen wird, die sich für einen noSQL-Datenspeicher wie MongoDB entschieden hätten, jetzt aber eine relationale Datenbank mit abfragbaren unstrukturierten Daten unter einem Dach kombinieren können

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

Benchmarks von postgresql 9.4 jsonb scheinen mit MongoDB mit oder in einigen Fällen schneller zu sein

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

Ein weiterer wichtiger Unterschied, der in keiner der obigen Antworten erwähnt wurde, ist, dass es keinen Gleichheitsoperator für den Typ json gibt, aber einen für den Typ jsonb.

Dies bedeutet, dass Sie das Schlüsselwort DISTINCT nicht verwenden können, wenn Sie diesen json- Typ und/oder andere Felder aus einer Tabelle auswählen (Sie können DISTINCT ON stattdessen, aber aufgrund von Fällen wie this ) ist dies nicht immer möglich.