Vergleich von relationalen Datenbanken und Graphendatenbanken

Kann mir jemand die Vor- und Nachteile einer Beziehungsdatenbank wie MySQL im Vergleich zu einer Graphendatenbank wie Neo4j erklären?

In SQL haben Sie mehrere Tabellen mit verschiedenen IDs, die sie verknüpfen. Dann müssen Sie beitreten, um die Tabellen zu verbinden. Aus der Sicht eines Neulings, warum sollten Sie die Datenbank so gestalten, dass ein Join erforderlich ist, anstatt die Verbindungen von Anfang an wie bei einer Diagrammdatenbank als Kanten explizit zu haben? Konzeptionell würde es für einen Neuling keinen Sinn ergeben. Vermutlich gibt es dafür einen sehr technischen, aber nicht konzeptionellen Grund?

Hinter beiden Stilen steckt tatsächlich konzeptionelles Denken. Wikipedia über die relationalen Modell- und Graphendatenbanken gibt hierzu einen guten Überblick.

Der Hauptunterschied besteht darin, dass in einer Diagrammdatenbank die Beziehungen auf der Ebene der einzelnen Datensätze gespeichert werden, während in einer relationalen Datenbank die Struktur auf einer höheren Ebene definiert wird (die Tabellendefinitionen).

Dies hat wichtige Konsequenzen:

• Eine relationale Datenbank ist viel schneller, wenn eine große Anzahl von Datensätzen verarbeitet wird. In einer Diagrammdatenbank muss jeder Datensatz während einer Abfrage einzeln untersucht werden, um die Struktur der Daten zu bestimmen, während dies in einer relationalen Datenbank im Voraus bekannt ist.
• Relationale Datenbanken benötigen weniger Speicherplatz, da nicht alle diese Beziehungen gespeichert werden müssen.

Das Speichern aller Beziehungen auf der Ebene der einzelnen Datensätze ist nur dann sinnvoll, wenn die Beziehungen sehr unterschiedlich sein werden. Andernfalls duplizieren Sie immer wieder dieselben Dinge. Dies bedeutet, dass Graphendatenbanken für unregelmäßige, komplexe Strukturen gut geeignet sind. In der realen Welt erfordern die meisten Datenbanken jedoch regelmäßige, relativ einfache Strukturen. Aus diesem Grund überwiegen relationale Datenbanken.

Der Hauptunterschied zwischen einem Diagramm und einer relationalen Datenbank besteht darin, dass relationale Datenbanken mit Mengen arbeiten, während Diagrammdatenbanken mit Pfaden arbeiten.

Dies äußert sich auf unerwartete und nicht hilfreiche Weise für einen RDBMS-Benutzer. Wenn Sie beispielsweise versuchen, Pfadoperationen (z. B. Freunde von Freunden) durch rekursives Beitreten zu einer relationalen Datenbank zu emulieren, steigt die Abfragelatenz unvorhersehbar und massiv an, ebenso wie die Speichernutzung, ganz zu schweigen davon, dass SQL quält, um diese Art von Operationen auszudrücken. Mehr Daten bedeuten langsamer in einer satzbasierten Datenbank, selbst wenn Sie den Schmerz durch eine vernünftige Indizierung verzögern können.

Wie Dan1111 angedeutet hat, leiden die meisten Grafikdatenbanken nicht unter solchen Verbindungsschmerzen, da sie Beziehungen auf einer fundamentalen Ebene ausdrücken. Das heißt, Beziehungen existieren physisch auf der Festplatte und sie werden benannt, gerichtet und können selbst mit Eigenschaften dekoriert werden (dies wird als Eigenschaftsdiagrammmodell bezeichnet, siehe: https://github.com/tinkerpop/blueprints/wiki/Property-Graph) -Modell ). Wenn Sie dies wünschen, können Sie sich die Beziehungen auf der Festplatte ansehen und sehen, wie sie Entitäten "verbinden". Beziehungen sind daher erstklassige Entitäten in einer Diagrammdatenbank und semantisch weitaus stärker als die implizierten Beziehungen, die zur Laufzeit in einem relationalen Speicher bestätigt werden.

Warum sollte es dich interessieren? Aus zwei Gründen:

1. Diagrammdatenbanken sind für verbundene Daten viel schneller als relationale Datenbanken - eine Stärke des zugrunde liegenden Modells. Dies hat zur Folge, dass die Abfragelatenz in einer Diagrammdatenbank proportional zu der Menge des Diagramms ist, die Sie in einer Abfrage untersuchen möchten, und nicht proportional zur gespeicherten Datenmenge, wodurch die Verknüpfungsbombe entschärft wird .
2. Grafikdatenbanken machen das Modellieren und Abfragen viel angenehmer, was eine schnellere Entwicklung und weniger WTF-Momente bedeutet. Zum Beispiel ist es gerecht, einen Freund eines Freundes für ein typisches soziales Netzwerk in der Cypher-Abfragesprache von Neo4j auszudrücken MATCH (me)-[:FRIEND]->()-[:FRIEND]->(foaf) RETURN foaf.

Dan1111 hat bereits eine als korrekt gekennzeichnete Antwort gegeben. Ein paar zusätzliche Punkte sind im Vorbeigehen erwähnenswert.

Erstens werden in fast jeder Implementierung von Diagrammdatenbanken die Datensätze "angeheftet", da eine unbekannte Anzahl von Zeigern auf den Datensatz an seiner aktuellen Position zeigt. Dies bedeutet, dass ein Datensatz nicht an einen neuen Speicherort gemischt werden kann, ohne entweder eine Weiterleitungsadresse am alten Speicherort zu belassen oder eine unbekannte Anzahl von Zeigern zu beschädigen.

Theoretisch könnte man alle Datensätze auf einmal mischen und einen Weg finden, alle Zeiger zu lokalisieren und zu reparieren. In der Praxis ist dies ein Vorgang, der in einer großen Grafikdatenbank Wochen dauern kann. Während dieser Zeit müsste die Datenbank nicht in Betrieb sein. Es ist einfach nicht machbar.

Im Gegensatz dazu können in einer relationalen Datenbank Datensätze in relativ großem Umfang neu gemischt werden. Das einzige, was getan werden muss, ist, alle betroffenen Indizes neu zu erstellen. Dies ist eine ziemlich große Operation, aber bei weitem nicht so groß wie das Äquivalent für eine Diagrammdatenbank.

Der zweite erwähnenswerte Punkt ist, dass das World Wide Web als gigantische Graphendatenbank angesehen werden kann. Webseiten enthalten Hyperlinks und Hyperlinks verweisen unter anderem auf andere Webseiten. Die Referenz erfolgt über URLs, die wie Zeiger funktionieren.

Wenn eine Webseite auf eine andere URL verschoben wird, ohne dass eine Weiterleitungsadresse an der alten URL verbleibt, wird eine unbekannte Anzahl von Hyperlinks unterbrochen. Diese defekten Links führen dann zu der gefürchteten Meldung "Fehler 404: Seite nicht gefunden", die das Vergnügen so vieler Surfer unterbricht.

Mit einer relationalen Datenbank können wir ein Diagramm mithilfe von Fremdschlüsseln und Selbstverknüpfungen modellieren und abfragen. Nur weil RDBMS das Wort relational enthalten, bedeutet dies nicht, dass sie gut mit Beziehungen umgehen können. Das Wort relational in RDBMS stammt aus der relationalen Algebra und nicht aus der Beziehung. In einem RDBMS existiert die Beziehung selbst nicht als eigenständiges Objekt. Es muss entweder explizit als Fremdschlüssel oder implizit als Wert in einer Verknüpfungstabelle dargestellt werden (bei Verwendung eines generischen / universellen Modellierungsansatzes). Verknüpfungen zwischen Datensätzen werden in den Daten selbst gespeichert.

Je mehr wir die Suchtiefe in einer relationalen Datenbank erhöhen, desto mehr Self-Joins müssen durchgeführt werden und desto mehr leidet unsere Abfrageleistung. Je tiefer wir in unserer Hierarchie sind, desto mehr Tabellen müssen verbunden werden und desto langsamer wird unsere Abfrage. Mathematisch gesehen steigen die Kosten in einer relationalen Datenbank exponentiell. Mit anderen Worten, je komplexer unsere Abfragen und Beziehungen werden, desto mehr profitieren wir von einem Diagramm im Vergleich zu einer relationalen Datenbank. Beim Navigieren im Diagramm treten in einer Diagrammdatenbank keine Leistungsprobleme auf. Dies liegt daran, dass eine Diagrammdatenbank die Beziehungen als separate Objekte speichert. Die überlegene Leseleistung geht jedoch zu Lasten langsamerer Schreibvorgänge.

In bestimmten Situationen ist es einfacher, das Datenmodell in einer Diagrammdatenbank zu ändern als in einem RDBMS, z. B. in einem RDBMS, wenn ich eine Tabellenbeziehung von 1: n in m: n ändere. Ich muss DDL mit potenziellen Ausfallzeiten anwenden.

RDBMS hat andererseits Vorteile in anderen Bereichen, z. B. beim Aggregieren von Daten oder bei der zeitgesteuerten Versionskontrolle von Daten.

Ich diskutiere einige der anderen Vor- und Nachteile in meinem Blogbeitrag über Graphendatenbanken für Data Warehousing

Während das relationale Modell die in einem Diagrammmodell enthaltenen Daten leicht darstellen kann, stehen wir in der Praxis vor zwei wesentlichen Problemen:

1. In SQL fehlt die Syntax, um das Durchlaufen von Graphen einfach durchzuführen, insbesondere beim Durchlaufen, wenn die Tiefe unbekannt oder unbegrenzt ist. Zum Beispiel ist die Verwendung von SQL zum Ermitteln von Freunden Ihrer Freunde einfach genug, aber es ist schwierig, das Problem der Trennungsgrade zu lösen.
2. Die Leistung nimmt beim Durchlaufen des Diagramms schnell ab. Jede Durchlaufebene verlängert die Antwortzeit der Abfrage erheblich.

Referenz: Datenbanken der nächsten Generation

Grafikdatenbanken sind es wert, auf die Anwendungsfälle untersucht zu werden, in denen sie sich auszeichnen, aber ich hatte Grund, einige Aussagen in den obigen Antworten in Frage zu stellen. Bestimmtes:

Eine relationale Datenbank ist viel schneller, wenn eine große Anzahl von Datensätzen verarbeitet wird (der erste Aufzählungspunkt von dan1111).

Diagrammdatenbanken sind für verbundene Daten viel schneller als relationale Datenbanken - eine Stärke des zugrunde liegenden Modells. Dies hat zur Folge, dass die Abfragelatenz in einer Diagrammdatenbank proportional zu der Menge des Diagramms ist, die Sie in einer Abfrage untersuchen möchten, und nicht proportional zur gespeicherten Datenmenge, wodurch die Verknüpfungsbombe entschärft wird. (Jim Webbers erster Punkt)

Mit anderen Worten, je komplexer unsere Abfragen und Beziehungen werden, desto mehr profitieren wir von einem Diagramm im Vergleich zu einer relationalen Datenbank. (Uli Bethkes 2. Absatz)

Obwohl diese Behauptungen durchaus berechtigt sein mögen, muss ich noch einen Weg finden, um meinen spezifischen Anwendungsfall an sie anzupassen. Referenz: Diagrammdatenbank oder relationale Datenbank Allgemeine Tabellenerweiterungen: Vergleichen der Leistung der azyklischen Diagrammabfrage