Leistung von beliebigen Abfragen mit Neo4j

8

Ich habe eine Zeitung gelesen, die vor einer Weile von Neo4J veröffentlicht wurde: Ссылка

und auf der vorletzten Seite im Abschnitt Nachteile steht, dass Neo4J nicht für beliebige Abfragen geeignet ist.

Angenommen, ich hätte Knoten von Benutzern mit den folgenden Eigenschaften: NAME, ALTER, GESCHLECHT

Und die folgenden Beziehungen: LIKE (zeigt auf Sport, Technologie usw. NODE) ​​und FRIEND (zeigt auf einen anderen USER).

Ist Neo4J nicht sehr effizient in der Abfrage von etwas ähnlich wie:

Finde FREUNDE (von gegebenem Knoten), die Sport, Technik & amp; Lesen, dass OVER_THE_AGE 21 waren.

Daher müssen Sie zuerst die FREUND-Kanten von USER1 finden und dann die LIKE-Kanten von Freunden finden und bestimmen, ob dieser Knoten Sport genannt wurde, und Sie müssen feststellen, ob die Alter-Eigenschaft des angegebenen Freundes & gt; 21.

Ist das zunächst ein schlechtes Datenmodell? Und besonders für Graphendatenbanken? Der Grund für die LIKE-Beziehung ist für den Fall, dass Sie alle Leute finden möchten, die Sport mögen.

Was wäre die bessere Datenbank dafür? Redis, Kassandra, HBase, PostgreSQL? Und warum?

Hat jemand diesbezüglich irgendwelche empirischen Daten?

    
user2243357 02.04.2014, 19:34
quelle

1 Antwort

19

Dies ist eine allgemeine Frage zur Beschaffenheit von Graph-Datenbanken. Hoffentlich springt einer der neo4j Entwickler hier rein, aber hier ist mein Verständnis.

Sie können sich jede Datenbank als "natürlich indiziert" in einer bestimmten Weise vorstellen. Wenn Sie in einer relationalen Datenbank einen Datensatz im Speicher nachschlagen, wird im Allgemeinen der nächste Datensatz direkt neben dem Speicher gespeichert. Wir können dies einen "natürlichen Index" nennen, denn wenn Sie eine Reihe von Datensätzen durchsuchen möchten, ist die relationale Struktur einfach so eingerichtet, dass sie wirklich gut funktioniert.

Graph-Datenbanken werden dagegen normalerweise durch Beziehungen indiziert. (Neo4J Entwickler, springen Sie ein, wenn dies eine Verbesserung in Bezug auf die Art und Weise benötigt, wie neo4j Speicher auf der Festplatte speichert). Dies bedeutet, dass Graph-Datenbanken im Allgemeinen Beziehungen sehr schnell durchlaufen, aber bei Massen- / Massen-Abfragen weniger gut abschneiden.

Jetzt reden wir nur über die relative Leistung. Hier ist ein Beispiel für eine RDBMS-Stilabfrage. Ich würde erwarten, dass MySQL die Leistung von neo4j bei dieser Abfrage wegbläst:

%Vor%

Beachten Sie, dass dies keine Beziehungen ausnutzt und die Datenbank alle Knoten scannt. Sie könnten dies verbessern, indem Sie es auf eine bestimmte Bezeichnung eingrenzen oder indem Sie den Namen indexieren. Wenn Sie jedoch eine MySQL-Tabelle mit "people" mit einer "name" -Spalte haben, wird ein RDBMS bei Abfragen wie Dies und Grafik wird weniger gut tun.

OK, das ist der Nachteil. Was ist die Oberseite? Werfen wir einen Blick auf diese Abfrage:

%Vor%

Das ist ein ganz anderes Biest. Die tatsächliche Aktion der Abfrage besteht darin, einen Pfad variabler Länge zwischen n und m zu finden. Wie würden wir das relational machen? Wir könnten eine Tabelle "Knoten" und "Kanten" einrichten und dann eine PK / FK-Beziehung zwischen ihnen hinzufügen. Sie könnten dann eine SQL-Abfrage schreiben, die rekursiv die beiden Tabellen verbindet, um diesen "Pfad" zu durchlaufen. Glauben Sie mir, ich habe das in SQL versucht, und es erfordert Fähigkeiten auf Assistentenebene, um den Teil "zwischen 1 und 5 Sprüngen" dieser Abfrage auszudrücken. Außerdem wird RDMBS bei dieser Abfrage wie ein Hund funktionieren, weil es nicht besonders selektiv ist, und die rekursive Abfrage ist ziemlich teuer, wenn all diese sich wiederholenden Verknüpfungen ausgeführt werden.

Bei solchen Anfragen wird neo4j dem RDBMS-Ass Kick geben.

Also - zu Ihrer Frage über beliebige Abfragen - kein System in der Welt ist gut bei beliebigen Abfragen, dh alle Abfragen. Systeme haben Stärken und Schwächen. Neo4J kann beliebige Abfragen ausführen, aber es gibt keine Garantie dafür, dass es für einige Arten von Abfragen bessere Ergebnisse liefert als einige Alternativen. Aber diese Beobachtung ist allgemein - das gleiche gilt für MySQL, MongoDB und alles, was Sie sonst noch wählen.

OK, also Grundlinien und Beobachtungen:

  1. Graph-Datenbanken funktionieren gut in einer Klasse von Abfragen, bei denen RDMBS (und andere) schlecht arbeiten.
  2. Grafikdatenbanken sind nicht auf hohe Leistung bei Massen- / Massenanfragen abgestimmt, wie in dem von mir bereitgestellten Beispiel. Sie können sie tun, und Sie können ihre Leistung verbessern, um die Dinge dort zu verbessern, aber sie werden nie so gut sein wie ein RDBMS
  3. Das liegt daran, dass sie grundsätzlich so angelegt sind, wie sie über die Daten denken / speichern.
  4. Was sollen Sie tun? Wenn Ihr Problem aus vielen Problemen bei der Beziehung zwischen Beziehung und Pfad besteht, ist das Diagramm ein großer Gewinn! (Das heißt, Ihre Daten sind eine Grafik, und die Beziehungen sind wichtig für Sie). Wenn Ihr Problem darin besteht, große Objektmengen zu scannen, passt das relationale Modell wahrscheinlich besser.

Verwenden Sie Werkzeuge in ihrem Bereich der Stärke. Verwenden Sie neo4j nicht wie eine relationale Datenbank, oder es funktioniert ungefähr so ​​gut, als ob Sie versucht hätten, mit einem Schraubenzieher Nägel zu schlagen. :)

    
FrobberOfBits 02.04.2014, 19:48
quelle