Ist dieser Neo4j-Vergleich mit der RDBMS-Ausführungszeit korrekt?

Hintergrund: Das Folgende stammt aus dem Buch Graph Databases , das einen Leistungstest behandelt, der im Buch Neo4j in Aktion erwähnt wird :

Beziehungen in einem Diagramm bilden natürlich Pfade. Beim Abfragen oder Durchlaufen des Diagramms werden folgende Pfade verwendet. Aufgrund der grundsätzlich pfadorientierten Natur des Datenmodells sind die meisten pfadbasierten Diagrammdatenbankoperationen stark an der Art und Weise ausgerichtet, in der die Daten angeordnet sind, was sie äußerst effizient macht. In ihrem Buch Neo4j in Action führen Partner und Vukotic ein Experiment mit einem relationalen Speicher und Neo4j durch.

Der Vergleich zeigt, dass die Diagrammdatenbank für verbundene Daten wesentlich schneller ist als ein relationaler Speicher. Das Experiment von Partner und Vukotic versucht, Freunde von Freunden in einem sozialen Netzwerk bis zu einer maximalen Tiefe von fünf zu finden. Gibt es bei zwei zufällig ausgewählten Personen einen Pfad, der sie verbindet und höchstens fünf Beziehungen lang ist? Für ein soziales Netzwerk mit 1.000.000 Personen mit jeweils ungefähr 50 Freunden deuten die Ergebnisse nachdrücklich darauf hin, dass Diagrammdatenbanken die beste Wahl für verbundene Daten sind, wie in Tabelle 2-1 dargestellt.

Tabelle 2-1. Das Finden erweiterter Freunde in einer relationalen Datenbank im Vergleich zum effizienten Finden in Neo4j

Depth   RDBMS Execution time (s)    Neo4j Execution time (s)     Records returned
2       0.016                       0.01                         ~2500    
3       30.267                      0.168                        ~110,000 
4       1543.505                    1.359                        ~600,000 
5       Unfinished                  2.132                        ~800,000

In Tiefe zwei (Freunde von Freunden) funktionieren sowohl die relationale Datenbank als auch die Diagrammdatenbank so gut, dass wir in Betracht ziehen können, sie in einem Online-System zu verwenden. Während die Neo4j-Abfrage in zwei Dritteln der Zeit der relationalen Abfrage ausgeführt wird, würde ein Endbenutzer den Unterschied in Millisekunden zwischen den beiden kaum bemerken. Bis wir Tiefe drei erreichen (Freund-Freund-Freund-Freund), ist jedoch klar, dass die relationale Datenbank die Abfrage nicht mehr in einem angemessenen Zeitrahmen bearbeiten kann: Die 30 Sekunden, die für die Fertigstellung benötigt werden, wären völlig inakzeptabel für ein Online-System. Im Gegensatz dazu bleibt die Antwortzeit von Neo4j relativ gering: Nur ein Bruchteil einer Sekunde, um die Abfrage durchzuführen - definitiv schnell genug für ein Online-System.

In der vierten Tiefe weist die relationale Datenbank eine lähmende Latenz auf, was sie für ein Online-System praktisch unbrauchbar macht. Die Timings von Neo4j haben sich ebenfalls etwas verschlechtert, aber die Latenz liegt hier an der Peripherie, um für ein reaktionsfähiges Online-System akzeptabel zu sein. In der fünften Tiefe dauert die relationale Datenbank einfach zu lange, um die Abfrage abzuschließen. Im Gegensatz dazu gibt Neo4j in etwa zwei Sekunden ein Ergebnis zurück. In der fünften Tiefe stellt sich heraus, dass fast das gesamte Netzwerk unser Freund ist: Für viele reale Anwendungsfälle würden wir wahrscheinlich die Ergebnisse und das Timing kürzen.

Fragen sind:

• Ist dies ein vernünftiger Test, um zu emulieren, was man außer in einem sozialen Netzwerk finden könnte? (Dies bedeutet, dass echte soziale Netzwerke normalerweise Knoten mit ungefähr 50 Freunden haben. Es scheint, dass das Modell " Rich Get Richer " für soziale Netzwerke natürlicher wäre, obwohl es möglicherweise falsch ist.)
• Gibt es einen Grund zu der Annahme, dass die Ergebnisse ungeachtet der Natürlichkeit der Emulation falsch oder nicht reproduzierbar sind?

Wenn ich mir dieses Dokument mit dem Namen Anatomy of Facebook ansehe, stelle ich fest, dass der Median 100 beträgt. Wenn ich mir das kumulative Funktionsdiagramm anschaue, kann ich wetten, dass der Durchschnitt höher ist, nahe 200. 50 scheint hier also nicht die beste Zahl zu sein. Ich denke jedoch, dass dies hier nicht das Hauptproblem ist.

Das Hauptproblem ist der Mangel an Informationen darüber, wie die Datenbank verwendet wurde.

Es erscheint vernünftig, dass ein Datenspeicher, der speziell für Diagrammstrukturen entwickelt wurde, effizienter ist als herkömmliche RDBMs. Selbst wenn die RDBMs als Datenspeicher der Wahl nicht den neuesten Trends entsprechen, haben sich diese Systeme im Wettlauf mit den Datensatzdimensionen kontinuierlich weiterentwickelt. Es gibt verschiedene Arten möglicher Designs, verschiedene Arten der Indizierung von Daten, Verbesserungen im Zusammenhang mit der Parallelität und so weiter.

Abschließend denke ich, dass der Studie in Bezug auf die Reproduzierbarkeit eine genaue Beschreibung des Entwurfs des Datenbankschemas fehlt. Ich erwarte nicht, dass eine Datenbank bei einem solchen König der Verhöre dominiert, aber ich würde erwarten, dass bei einem gut abgestimmten Design die Unterschiede nicht so massiv sind.

Es gibt gute / schnelle Möglichkeiten, Diagramme in RDBMS zu modellieren, und dumme / langsame Möglichkeiten.

• Einige verwenden clevere Indizierung und gespeicherte Prozesse, handeln mit CPU-Auslastung und optimierten temporären Tabellen auf RAM-Festplatten, um eine schnellere Geschwindigkeit beim Abrufen von Grafiken zu erzielen.

• Einige verwenden vorberechnete Diagrammpfade (dies ist im Szenario sozialer Netzwerke möglicherweise weniger machbar, aber in einem Baum, in dem die meisten Knoten Blattknoten sind, ist dies ein ziemlich guter Kompromiss zwischen Raum und Zeit

• Einige berechnen einfach in einer Schleife unter Verwendung einer nicht abgestimmten, indizierten temporären Tabelle. Nach den im Artikel geworfenen # riecht das nach dem, was sie getan haben (30-Sekunden-Leistung bei relativ kleinem Datensatz)

  Zum Beispiel habe ich meine eigene Baumberechnung.

  • Es ist in einem hoch abgestimmten gespeicherten Prozess eingekapselt

  • Während dieser Server in einem Sybase ASE15-Datenserver in Unternehmensgröße ausgeführt wird, wird er mit einigen Terabyte Daten aus allen anderen Unternehmensanwendungen gemeinsam genutzt, von denen einige viel datenhungriger sind als meine. und ist nicht nur der Ausführung meiner Abfragen gewidmet.

  • Ich hatte keinen Zugriff auf das Haupt-Speedup-Tool, eine temporäre Tabelle auf einer RAM-Disk.

  • Ein repräsentativer Datensatz, den ich abgerufen habe und der anscheinend etwas mit dem übereinstimmt, ergab einen Teilbaum mit 150.000 Knoten aus einem vollständigen Gesamtstrukturdatensatz von 2,5 Millionen Knoten (unbegrenzte Baumtiefe, die zwischen 5 und 15 variiert, aber eine geringere durchschnittliche Arität eines bestimmten Knotens als die 50 im Experiment aufgelisteten Freunde)

  • Ich habe es so eingestellt, dass diese Abfrage ~ 30-45 Sekunden dauert. Es zeigt mit Sicherheit NICHT die exponentielle Verlangsamung, die die Zahlen in der Frage auf ihre RDBMS-Leistung hinweisen, was besonders seltsam ist, da die Ergebnismenge nicht exponentiell wächst (was für mich nach einem nicht abgestimmten Index für a riecht) temporäre Tabelle aus persönlicher Erfahrung).

Daher ist dieser Vergleich höchstwahrscheinlich falsch und basiert auf einem schlechten RDBMS-Seitendesign, obwohl es, wie in der vorherigen Antwort erwähnt, unmöglich ist, 100% ihrer Code- und Tabellendefinitionen ohne Open Sourcing zu ermitteln.