Kann jemand erklären, wie eine Dokumentendatenbank auch als Graphdatenbank funktioniert?ArangoDB Dokumentendatenbank und auch eine Graphdatenbank? Wie ist es möglich?
Was ist der Unterschied zwischen ArangoDB und Neo4j?
Haftungsausschluss: Ich bin Max von ArangoDB, einem der Kernentwickler.
Zunächst eine längere Diskussion über diese und andere verwandte Fragen finden Sie in meinem Artikel Graphs in data modeling - is the emperor naked?, aber ich werde versuchen, beide Fragen hier kurz zu beantworten.
(1) Speichern eines Graphen in einem Dokumentenspeicher ist relativ einfach (wie in einer relationalen Datenbank), kann man einfach ein Dokument für jeden Eckpunkt in einer "Vertex-Sammlung" und ein Dokument für jeden speichern Kante in einer "Kantensammlung". Man muss nur sicherstellen, dass jede Kante speichert, von welchem Scheitelpunkt es kommt und zu welchem Scheitelpunkt es geht. In ArangoDB verwenden wir dazu die Attribute _from und _to im Edge-Dokument.
Die entscheidende Fähigkeit für eine Graphdatenbank ist jedoch, dass sie Abfragen zu Diagrammen effizient beantworten muss. Typische Abfragen für Graphen sind (a) "Was sind die Nachbarn eines Eckpunkts in der Grafik?" oder (b) "Was ist der kürzeste Weg von Scheitelpunkt A zum Scheitelpunkt B im Diagramm?" oder (c) "gebe mir alle Eckpunkte, die ich vom Eckpunkt A aus erreichen kann, indem ich Kanten folge". Während (a) einfach einen guten Index für die Kantensammlung benötigt, beinhalten (b) und (c) eine a priori unbekannte Anzahl von Schritten im Graphen. Daher können (b) und (c) nicht effizient mit herkömmlichen Datenbankabfragesprachen wie SQL ausgeführt werden, einfach weil sie eine große Menge an Kommunikation zwischen Client und Server erfordern oder zumindest einen sehr komplizierten Ausdruck mit einer variablen Anzahl von verbindet. Ich nenne Abfragen wie (b) und (c) daher "graphy", ohne das genau zu definieren.
Daher meine kurze Antwort auf "wie kann ein Dokument speichern eine Grafik-Datenbank sein?" is: Speichere den Graphen wie oben und implementiere Graphy-Abfragen auf dem Datenbankserver, auf die über die Abfragesprache des Datenspeichers zugegriffen werden kann. Im Prinzip könnte das Gleiche mit einer relationalen Datenbank und einigen beträchtlichen Erweiterungen von SQL gemacht werden.
Mit ArangoDB haben wir es geschafft, das Dokument, die Grafik und die Schlüssel/Wert-Funktionen in einer einzigen, kohärenten Abfragesprache zu kombinieren. Wir nennen ArangoDB daher eine "Multi-Model-Datenbank", weil sie diese drei Datenmodelle nahtlos miteinander verbindet. Sie können sogar die Datenmodelle in einer einzigen Abfrage mischen!
Dies führt zu meiner Antwort auf Frage über (2), das ist natürlich ein bisschen voreingenommen:
Im Vergleich zu ArangoDB, die eine verteiltes Multi-Modell-Datenbank im obigen Sinne ist, ist Neo4j ein klassisches Graph Datenbank. Es speichert Graphen, erlaubt Abfragen mit "graphy queries" und verfügt über eine Speicher- und Abfrage-Engine, die dafür optimiert ist. Neo4j eignet sich besonders gut für die Suche nach Pfaden unter Verwendung seines eingebauten Abfragesprachcodes. Es erlaubt zwar, Eigenschaften an Scheitelpunkte und Kanten anzuhängen, aber es ist kein voll ausgestatteter Dokumentenspeicher. Es ist nicht für die Verarbeitung von Dokumentabfragen mit mehreren Sekundärindizes optimiert, noch für Joins. Außerdem wird Neo4j nicht vertrieben.
Neo4j ist in Java geschrieben, ArangoDB ist in C++ geschrieben und bettet Googles V8 ein, JavaScript-Erweiterungen auszuführen.
Für einen Leistungsvergleich siehe this post.
Arango DB ist afaik eine Doc-orientierte DB, mit der man Graphen irgendwie manipulieren kann. Aber gut, Sie können Graphen in RDBMS "manipulieren", also würde ich sagen, das ist nur Marketing. – Rolf