Kurze Beschreibung inwiefern sich PostereSQL hinsichtlich NoSOL gegenüber denklassischen RDRMS abhebt

BenBach

Neuer Benutzer
Beiträge
2
Hallo Leute,

ich benötige eure Hilfe weil ich leider nichts im Internet finde. Könnt Ihr mir helfen ich muss eine kurze Beschreibung formulieren inwiefern sich PostgreSQL hinsichtlich NoSQL gegenüber den klassischen RDBMS abhebt. Über jede Hilfe würde ich mich sehr freuen auch über Links und Webseiten wo ich etwas zum Thema finde.

Vielen Dank im Voraus,

Mit freundlichen Grüßen,

Ben Bach
 
Werbung:

ich weiß aber nicht, ob es das ist, was Du suchst. PostgreSQL hat einen starken Fokus auf Datenintegrität und Datenkonsistenz und Crashsicherheit. Es ist extrem erweiterbar, so kann es perfekt mit geometrischen Daten umgehen, durch entsprechende Erweiterungen (PostGIS).
es kann AUCH mit NoSQL-Features umgehen (siehe MongoDB) - und ist dabei teilweise deutlich schneller.
 
Ich finde wichtig, wie hoch die Integration ist (insbesondere in SQL und damit in vorhandene Abfrage und Analyse Techniken) und wieviele der NOSQL Features durch die Integration (um nicht zu sagen Verschmelzung) von Konzepten klassischer RDBMS profitieren.
Spricht man nun von Tradition und meinetwegen Moderne, ist Postgres mit NOSQL Funktionen nicht allein auf der Welt. Aber es ist ein ziemlicher Vorreiter und ziemlich weit, also schon sehr lange sehr weit, was ja nicht unerheblich ist. Unter kostenlosen Opensource Systemen schätze ich mal führend und bei den Bezahlsystemen würde ich fast das Gleiche annehmen. Ich kenne allerdings Kauf DB nicht mehr in aktuellen Versionen, da bin ich mir nicht so sicher.

Ein wichtiger Aspekt, der nicht mal unbedingt nur ein Vergleich mit "traditionellen" RDBMS, sondern auch gleich mit den NOSQL "Vorbildern" betrifft, wären m.E. alle Arten von Limits. Meine wenigen praktischen Erfahrungen mit MongoDB haben mich doch ganz gut enttäuscht. Maximale "Dokument" Größe und andere Sachen, sind Dinge, die einen mehr oder weniger zwingen, weniger eine Anwendung zu implementieren, als eine Adaption an das genutzte Speichersystem. Vielleicht ist das nicht gleich bei der ersten Hello Word Anwendung der Fall, aber ich finde es problematisch.
 
Ich finde die Frage verwirrend.

Meistens wird unter "NoSQL" ja letztendlich entweder eine Key/Value Datenbank (z.B. wie Redis) oder eine Dokumenten orientierte Datenbank (wie MongoDB). Und dann gibt es noch einige andere (Graph Datenbanken z.B.)

Häufig wird es aber mit "kann JSON speichern" gleichgesetzt (was dem sehr weit gefassten Begriff "NoSQL" aber nicht ganz gerecht wird - schließlich umfasst das einfach alle nicht-relationalen Datenbanken).

Ich denke wenn man "NoSQL-Features" mit "JSON Features" gleichsetzt, dann dürfte Postgres (in der Summe aller Features) ziemlich weit vorne mitspielen. Oracle 19 und SQL Server 2019 sind allerdings ziemlich dicht dran - aber man findet sicherlich immer ein Feature welches ausgerechnet in System X nicht vorhanden ist.

Soweit ich das beurteilen kann, hat Postgres aber die Nase deutlich vor, wenn es um das Indizieren von JSON Werten geht. Bei MySQL und SQL Server muss man z.B. für jede Bedingung die man indizieren möchte, eine berechnete Spalte anlegen und diese dann indizieren. Damit hat man aber nur die bekannten Bedingungen abgedeckt. Wenn man die Struktur des JSON nicht genau kennt, dann wird es fast unmöglich das zu indizieren. Such' mal nach einer Präsentation die "How to Use JSON in MySQL Wrong" heißt - praktisch alles da drin ist für Postgres nicht relevant.

Oracle hat ein ähnliches Konzept wie Postgres: dort kann man "generalisierte" Indizes anlegen (nennt sich Context Index) um Abfragen auf JSON Werte zu beschleunigen deren Struktur man nicht kennt. Im Gegensatz zu Postgres kann dabei sogar eine Abfrage die eine Subquery verwendet von dem Index profitieren (where exists (select ... from json_table(...)). Context Indizes werden in Oracle auch für der Volltextsuche eingesetzt und meine Erfahrung damit war eher negativ, weil die Indizes sehr viel "Zuwendung" benötigt haben, um das System am Laufen zu halten. Das war aber noch mit Oracle 11 und 12 - keine Ahnung ob die bei Oracle 19 oder 21 immer noch so fragil sind.

json_table() analog zu xml_table() fehlt leider auch noch in Postgres, aber in den meisten Fällen kann man das Gleiche auch mit mit jsonb_each() erreichen.

Was die Unterstützung von SQL Features aus dem SQL Standard betrifft, dürfte Oracle wohl derzeit die Nase vorn haben: Oracle DB 19c Improves JSON Standard Conformance
Allerdings ist die Übersicht dort etwas irreführend: für die meisten Funktionen des SQL Standard hat Postgres eine entsprechende Funktion - die halt etwas anders heißt und etwas anders verwendet wird. Wobei die Trennung zwischen den Typen json und jsonb die Sache in Postgres nicht leichter macht. Ich hätte mir echt gewünscht, dass alle JSON Funktionen transparent json/jsonb als Argumente verwenden könnten (und es nicht immer eine json_xxx und jsonb_xxx Funktion gibt).

Man sollte aber nie vergessen: Postgres ist und bleibt eine relationale Datenbank. Auch wenn es eine starke JSON Unterstützung gibt, wird sich das nie wirklich "gut" anfühlen. Vor allem das Ändern von einzelnen Werten in einer großen JSON Struktur ist in einer relationalen DB immer recht umständlich.
 

ich weiß aber nicht, ob es das ist, was Du suchst. PostgreSQL hat einen starken Fokus auf Datenintegrität und Datenkonsistenz und Crashsicherheit. Es ist extrem erweiterbar, so kann es perfekt mit geometrischen Daten umgehen, durch entsprechende Erweiterungen (PostGIS).
es kann AUCH mit NoSQL-Features umgehen (siehe MongoDB) - und ist dabei teilweise deutlich schneller.

Vielen Dank für deine Antwort könntest Du bitte genau erläutern was du mit dem Punkt "kann auch mit NoSQLFeatures umgehen (siehe MongoDB) eingehen. Würde mich sehr freuen :) Vielen Dank im Voraus @akretschmer
 
MongoDB z.B. spricht JSON - kann PostgreSQL auch. Es kann auch Key-Value - Stores via HSTORE. Das sind so die Dinge, die einem u.a. bei NoSQL einfallen, also schema-lose Daten. Und das kann PostgreSQL eben auch, zusammen mit 'klassischen' SQL-Dingen, gemeinsam und zusammen in einer Tabelle.
 
Werbung:
erläutern was du mit dem Punkt "kann auch mit NoSQLFeatures umgehen (siehe MongoDB) eingehen
Ich war nicht gemeint, aber Du kannst Dir das mal anschauen:

Das ist ein JSON BSON Vergleich und naturgemäß lobt der Hersteller seine eigene Herangehensweise. Er nennt die Vorteile, die eine binäre JSON Speicherung hat. Indizierung wurde schon von @castorp als Kriterium genannt.

So, für Postgres kannst Du jetzt in dem oben verlinkten Artikel beim Lesen im Hinterkopf haben, dass es nicht nur JSON beherrschert, sondern auch JSONB, eine binäre Persistierung von JSON. Auf das Format bezogen könnte man grob sagen, MongoDB BSON = Postgres JSONB.

~"Kann auch mit NOSQL Features umgehen" finde ich dabei eine recht bescheidene Formulierung für die Möglichkeiten, die Postgres bietet. Das betrifft reines Speichern, Abfrage (in SQL) und Datenmanipulation.

Ein ganz anderer Aspekt wäre für mich persönlich, dass ich es in der kurzen Zeit mit MongoDB nicht geschafft habe, mich wirklich mit BSON Abfragen anzufreunden.

Den großen Vorteil von Systemen wie Postgres, mit einer sehr guten Integration dieser Techniken ist die Wahlfreiheit bzw. Integration relationaler Speicherung und dokument orientierter. PG macht das m.E. sehr gut. Oder etwas anders formuliert, PG wäre MongoDB+.

Und noch etwas:
(Verweis auf den Link oben)
Eine Dokument orientierte Datenhaltung, wie sie MongoDB ausschließlich anbietet, erleichert es natürlich ungemein, irgendwelche - was auch immer für- Daten zu persistieren. Das mag extrem komfortabel wirken (geht wie gesagt mit Postgres auch). Lustig wird es, wenn man diese irgendwelche Daten heterogen ansprechen möchte. Und selbst wenn man da bei einer einzigen App/Anwendung bleibt, könnten solche Probleme bereits zur Entwicklugnszeit auftreten, gerne aber z.B. bei einem Versionswechsel der Anwendung, also einem "simplen" Upgrade.
Flexibilität ist da also nicht nur unbedingt positiv. Vielleicht auch eine Frage der Gewohnheiten (des Teams) (und des Bedarfs), aber es bedeutet auf der anderen Seite eine große Disziplin bei der Entwicklung, Code Versionierung, Deployment usw.
 
Zurück
Oben