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

Bezüglich der Unterschiede zwischen den Datentypen json und jsonb ist es erwähnenswert, dass es eine offizielle Erklärung dazu gibt:

PostgreSQL bietet zwei Typen zur Speicherung von JSON-Daten: json und jsonb. Um effiziente Abfragemechanismen für diese Datentypen zu implementieren, bietet PostgreSQL auch den Jsonpath-Datentypen, der in Abschnitt 8.14.6 beschrieben wird.

Die Datentypen json und jsonb akzeptieren fast identische Wertesätze als Eingabe. Der wichtigste praktische Unterschied liegt in der Effizienz. Der Datentyp json speichert eine exakte Kopie des Eingabetexts, die Verarbeitungsfunktionen bei jeder Ausführung neu parsen müssen; während Daten vom Typ jsonb in einem dekomponierten Binärformat gespeichert werden, was aufgrund der zusätzlichen Konvertierung mehr Eingabeaufwand bedeutet, aber deutlich schneller zu verarbeiten ist, da kein Neuparsen notwendig ist. jsonb unterstützt auch Indizierung, was ein bedeutender Vorteil sein kann.

Weil der Typ json eine exakte Kopie des Eingabetexts speichert, werden semantisch unbedeutende Leerzeichen zwischen Tokens sowie die Reihenfolge der Schlüssel innerhalb von JSON-Objekten erhalten. Wenn ein JSON-Objekt im Wert mehrmals denselben Schlüssel enthält, werden alle Schlüssel/Wert-Paare beibehalten. (Die Verarbeitungsfunktionen betrachten den letzten Wert als maßgeblich.) Im Gegensatz dazu behält jsonb keine Leerzeichen bei, bewahrt nicht die Reihenfolge der Objektschlüssel und bewahrt keine duplizierten Objektschlüssel. Wenn im Eingabeformular duplizierte Schlüssel angegeben sind, wird nur der letzte Wert beibehalten.

Im Allgemeinen sollten die meisten Anwendungen JSON-Daten als jsonb speichern, es sei denn, es gibt spezialisierte Anforderungen, wie z.B. veraltete Annahmen zur Reihenfolge von Objektschlüsseln.

PostgreSQL erlaubt nur eine Zeichensatzeinstellungscodierung pro Datenbank. Daher ist es für die JSON-Typen nicht möglich, streng der JSON-Spezifikation zu entsprechen, es sei denn, die Datenbankcodierung ist UTF8. Der Versuch, direkt Zeichen einzuschließen, die in der Datenbankcodierung nicht dargestellt werden können, wird fehlschlagen; andererseits werden Zeichen, die in der Datenbankcodierung dargestellt werden können, aber nicht in UTF8, zugelassen.

Quelle: https://www.postgresql.org/docs/current/datatype-json.html

Answer 2

Ich war heute auf der PostgresOpen und Benchmarks sind viel schneller als MongoDB. Ich glaube, es war rund 500% schneller für SELECT-Anfragen. So ziemlich alles war schneller, zumindest um etwa 200% im Vergleich zu MongoDB. Eine Ausnahme im Moment ist ein Update, das erfordert, die gesamte JSON-Spalte komplett neu zu schreiben - etwas, das MongoDB besser handhabt.

Die Gin-Indizierung auf JSONB klingt erstaunlich.

Außerdem wird PostgreSQL die Typen von JSONB intern beibehalten und diese im Wesentlichen mit Typen wie numerisch, Text, boolesch usw. abstimmen.

Auch Joins werden mit JSONB möglich sein.

Fügen Sie PLv8 für gespeicherte Prozeduren hinzu und das wird im Grunde ein Traum für Node.js Entwickler sein.

Da es binär gespeichert wird, entfernt JSONB auch alle Leerzeichen, ändert die Reihenfolge der Eigenschaften und entfernt doppelte Eigenschaften, wobei die letzte Instanz der Eigenschaft verwendet wird.

Neben dem Index muss PostgreSQL beim Abfragen gegen eine JSONB-Spalte im Vergleich zu einer JSON-Spalte tatsächlich nicht die Funktionalität ausführen, um den Text in JSON umzuwandeln, was allein wahrscheinlich eine enorme Menge an Zeit spart.

Answer 3

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

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

Answer 4

Meines Wissens nach,

• hstore, wie es derzeit existiert (in PostgreSQL 9.3), erlaubt es nicht, andere Objekte und Arrays als Werte seiner Schlüssel/Wert-Paare zu verschachteln. Eine zukünftige hstore-Patch wird dies jedoch ermöglichen. Dieser Patch wird nicht im 9.4-Release enthalten sein und es könnte eine Weile dauern, bis er inkludiert wird.

• json erlaubt derzeit tatsächlich das Verschachteln, aber es basiert auf Text und ermöglicht kein Indizieren, daher ist es "langsam"

• jsonb, das mit 9.4 veröffentlicht wird, wird die aktuellen Verschachtelungsmöglichkeiten von json haben sowie die GIN/GIST-Indizierung von hstore, so dass es schnell sein wird

Diejenigen, die an PostgreSQL 9.4 arbeiten, scheinen zu sagen, dass der neue, schnelle jsonb-Typ für diejenigen ansprechend sein wird, die sich für eine NoSQL-Datenbank wie MongoDB entschieden hätten, aber jetzt eine relationale Datenbank mit abfragbaren strukturierten Daten unter einem Dach kombinieren können

Warum HStore2/jsonb der wichtigste Patch von 9.4 ist

Benchmarks von PostgreSQL 9.4 jsonb scheinen auf Augenhöhe oder in einigen Fällen schneller als MongoDB zu sein.

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