Kann Graphen-Datenbanken Daten effizient über Knoten verteilen?

Question

Wenn jemand eine Datenbank auf einer anderen Datenbank aufbaut, wie Twitter es getan hat, erbt diese Datenbank die Einschränkungen und Ineffizienzen der zugrunde liegenden Datenbank?

Ich bin speziell an Titan db interessiert (http://thinkaurelius.com) wegen ihrer Behauptung, die Aufteilung des Dataset effizient über Knoten zu unterstützen.

Sie behaupten, die Verteilung von Daten zwischen Knoten zu unterstützen, wegen der Effizienz von Cassandra. Neo4j behauptet jedoch, dass der Grund dafür, dass sie keine Daten zwischen Knoten verteilen, sondern das gesamte Dataset auf jedem Knoten duplizieren, weil jede Traversierung eines Graphen, die einen Knoten verlässt und sich daher über ein Ethernet-Netzwerk bewegt, viel zu langsam ist praktisch sein.

Da Cassandra keine Kenntnis vom Graphen hat, kann es nicht optimieren, Graph-Traversierungen auf einem Knoten zu halten. Daher liegen die meisten Graph-Traversalen über Knotengrenzen hinweg.

Ist der Anspruch der Titanen, effizient über Knoten zu skalieren, wahr?

Answer 1

Titan bestimmt die Schlüsselsortierreihenfolge des zugrundeliegenden Speicher-Backends (BOP für Cassandra, Standardwert für HBase) und weist den Scheitelpunkten so IDs zu, dass Scheitelpunkte, die demselben Partitionsblock zugewiesen sind, IDs aufweisen, die demselben physischen Objekt zugewiesen sind Maschine. Mit anderen Worten, Titan "versteht", wie das zugrundeliegende Speicher-Backend die Daten verteilt, und verwendet Graphpartitionierungstechniken, die dieses Bewusstsein ausnutzen. Titan verwendet eine halbautomatische Partitionierung, die Domänenwissen beinhaltet.

Im Pearson-Benchmark (http://arli.us/edu-planet-scale) wurde das Diagramm nach Universitäten partitioniert, was ein nahezu optimales Partitionierungskriterium für diesen bestimmten Datensatz darstellt. Ohne Partitionierung wäre eine Skalierung auf 120 Milliarden Kanten nahezu unmöglich.

Titan baut auf bewährten Technologien auf (für Skalierung, Persistenz, Hot-Backup, Verfügbarkeit, Disaster Recovery usw.) und innoviert gleichzeitig auf der Grafikebene. Dies ist die gleiche Route, die sowohl Twitter's Flock als auch Facebook's Tao genommen haben. Dies bedeutet zwar, dass Titan bei sehr tiefen Traversalen langsamer ist, es erlaubt Titan jedoch, auf sehr große Graphen oder sehr viele gleichzeitige Transaktionen (Lesen und Schreiben) zu skalieren.

Answer 2

Gute Frage. Ich denke, das ist alles über das Kalibrieren. Twitter (das Cassandra verwendet) verwendet eine Graphdatenbank sehr spezifisch (sie haben nur zwei Ebenen von "Tiefe"), so dass Abfragen nicht lange Graphen durchlaufen müssen (und sie nicht gezwungen sind, den gesamten Datensatz zu replizieren). Ich denke, sowohl Titan als auch Neo4j haben recht, Neo4j versucht, eine Graphdatenbank für allgemeine Zwecke bereitzustellen, so dass Sie mehrere Lösungen haben, je nachdem, wie Sie es verwenden und sie nicht wissen, wie die Leute es verwenden werden, so dass sie die gebräuchlichere Lösung anwenden : Replizieren des gesamten Datasets.

In der Tat, wenn Sie nicht das gesamte Dataset replizieren und Sie einen langen Pfad in Ihrem Diagramm durchlaufen möchten, wird es langsam.

Also, was wird Ihre Verwendung sein? Ich habe Titan nie benutzt, aber ein guter Test wäre, seine Leistung mit Neo4j zu vergleichen, abhängig von der "Tiefe" der Abfragen.