it-swarm.com.de

JSONB mit Indizierung vs. hstore

Ich versuche, mich für das Datenbankdesign zu entscheiden, wobei derzeit so wenig Annahmen (hinsichtlich der tatsächlichen Entwicklung der Web-App) möglich sind.

Als ersten Schritt, um zu verstehen, dass JOINS teuer sind, betrachte ich eine kleine Anzahl monolithischer Tabellen im Gegensatz zu einer großen Anzahl normalisierter kleinerer Tabellen. Als zweiten Punkt bin ich verwirrt zwischen der Verwendung von hstore und regulären Tabellen im Vergleich zu JSONB (mit Gist-Indizierung).

AFAIK (bitte zögern Sie nicht zu korrigieren):

  1. Im Allgemeinen ist bekannt, dass hstore in Postgres eine bessere Leistung als andere Datentypen aufweist. Diese Präsentation von FOSDEM PGDAY enthält einige interessante Statistiken (in der zweiten Hälfte der Folien). https://wiki.postgresql.org/images/b/b4/Pg-as-nosql-pgday-fosdem-2013.pdf

  2. Ein Vorteil von hstore ist die schnelle Indizierung (GiN oder Gist). Mit JSONB können die Indizierung von GiN und Gist jedoch auch auf JSON-Daten angewendet werden.

  3. In diesem Blog eines Profis von 2nd Quadrant heißt es: "An dieser Stelle lohnt es sich wahrscheinlich, die Verwendung von hstore in allen neuen Anwendungen durch jsonb zu ersetzen" (bis zum Ende scrollen): http://blog.2ndquadrant.com/postgresql-anti -patterns-unnötig-jsonhstore-dynamische-Spalten /

Daher möchte ich mich für Folgendes entscheiden:

  1. Für den Hauptteil (strukturiert) der Daten: Sollte es in ein paar relationalen Tabellen (relativ groß mit vielen Spalten) sein, oder sollte es eine Reihe von Schlüsselwertspeichern sein, die hstore verwenden?
  2. Sollten sich die Ad-hoc-Daten (vom Benutzer bereitgestellte/unstrukturierte Daten) in JSON- oder Ad-hoc-Schlüsselwertspeichern in hstore befinden (wobei die Schlüssel in einer der wichtigsten relationalen Tabellen gespeichert sind)?
30
Yogesch

Relationale Datenbanken basieren auf Verknüpfungen und sind so optimiert, dass sie gut funktionieren.

Verwenden Sie ein normalisiertes Design, es sei denn, Sie haben einen guten Grund , kein normalisiertes Design zu verwenden .

jsonb und Dinge wie hstore sind gut, wenn Sie kein normalisiertes Datenmodell verwenden können , z. B. wenn Das Datenmodell ändert sich schnell und ist benutzerdefiniert.

Wenn Sie es relational modellieren können, modellieren Sie es relational. Wenn Sie dies nicht können, ziehen Sie json usw. in Betracht. Wenn Sie zwischen json/jsonb/hstore wählen, wählen Sie im Allgemeinen jsonb, es sei denn, Sie haben einen Grund, dies nicht zu tun .

Das habe ich in meinem Blog-Beitrag gesagt, der genau dieses Thema anspricht. Bitte lesen Sie den gesamten Beitrag . Der von Ihnen zitierte Absatz weist darauf hin, dass wenn Sie eine dynamische Struktur wählen , Sie jsonb anstelle von hstore wählen sollten, aber der Rest des Blog-Beitrags handelt davon, warum Normalerweise sollten Sie es vorziehen, relational zu modellieren, wenn Sie können.

Damit. Modellieren Sie den strukturierten Hauptteil relational. Wenn die Tabellen sehr breit sind und viele Spalten enthalten, kann dies ein Zeichen dafür sein, dass eine weitere Normalisierung erforderlich ist. Hab keine Angst vor Beitritten. Lerne Joins zu lieben. Das Verbinden vieler kleiner Tabellen ist oft schneller als das Abfragen und Verwalten großer denormalisierter Tabellen. Denormalisieren Sie nur, wenn Sie dies für bestimmte Fälle benötigen, und vorzugsweise über materialisierte Ansichten. Tun Sie dies jedoch erst, wenn Sie wissen, dass Sie ein konkretes Problem lösen müssen.

Verwenden Sie jsonb für vom Benutzer bereitgestellte Daten, die frei formuliert und unstrukturiert sind. Es sollte genauso gut funktionieren wie hstore, ist aber flexibler und einfacher zu handhaben.

Eine relevante Sache zu verstehen: Gist- und GIN-Indizes wie die auf jsonb verwendeten sind im Allgemeinen viel weniger effizient als ein einfacher B-Tree-Index. Sie sind flexibler, aber ein B-Tree-Index für eine normale Spalte ist fast immer viel, viel schneller.

43
Craig Ringer