Frage

Ich werde eine Anwendung mit vielen ähnlichen Produkten (in Millionen), und ich möchte sie in einer MySQL-Datenbank speichern, weil ich eine Menge Statistiken tun möchte und auf bestimmte Werte für bestimmte Spalten suchen.

Aber zur gleichen Zeit, ich die Beziehungen zwischen allen Einzelteilen gespeichert werden, die in vielen angeschlossenen binär baumartigen Strukturen (transitive Hülle) verbunden sind, und die Beziehung Datenbanken ist bei dieser Art von Strukturen nicht gut, so würde ich wie alle Beziehungen in Neo4j zu speichern, die für diese Art von Daten eine gute Leistung haben.

Mein Plan ist es, alle Daten mit Ausnahme der Beziehungen in der MySQL-Datenbank zu haben und alle Beziehungen zu item_id in der Datenbank Neo4j gespeichert. Wenn ich einen Baum nachschlagen möchte, suche ich zuerst die Neo4j für alle item_id: s in den Baum, dann suche ich die MySQL-Datenbank für alle die angegebenen Elemente in einer Abfrage, die aussehen würde:

SELECT * FROM items WHERE item_id = 45 OR item_id = 345435 OR item_id = 343 OR item_id = 78 OR item_id = 4522 OR item_id = 676 OR item_id = 443 OR item_id = 4255 OR item_id = 4345

Ist das eine gute Idee, oder bin ich sehr falsch? Ich habe nicht verwendet Graph-Datenbanken vor. Gibt es bessere Ansätze für mein Problem? Wie würde die MySQL-Abfrage in diesem Fall durchführen?

War es hilfreich?

Lösung

Ein paar Gedanken dazu:

würde ich versuchen, Ihre Neo4j Domänenmodell Modellierung der Eigenschaften von jedem Knoten in dem Graphen enthalten. Durch Ihre Daten in zwei verschiedene Datenspeicher zu trennen könnten Sie einige Operationen begrenzen, was Sie tun mögen.

Ich denke, es kommt darauf an, was Sie mit Ihrem Diagramm tun werden. Wenn zum Beispiel möchten Sie an einen bestimmten Knoten verbunden alle Knoten finden, deren Attribute (Name, Alter .. was auch immer) sind bestimmte Werte, würden Sie zuerst den richtigen Knoten-ID in Ihrer MySQL-Datenbank finden müssen, und dann gehen in Neo4j? Dies scheint nur langsam und zu kompliziert, wenn man all dies in Neo4j tun könnte. Die Frage ist also: müssen Sie die Attribute eines Knotens, wenn das Diagramm durchlaufen?

Ihre Daten ändern oder ist es statisch? Dadurch, dass zwei separate Datenspeicher wird es komplizierter wird.

Während Statistiken mit einer MySQL-Datenbank zu erzeugen könnte einfacher sein, als alles zu tun, in Neo4j, der Code eine Grafik zu durchqueren erforderlich, um alle Knoten zu finden, die eine definierte Kriterien erfüllen, ist nicht allzu schwierig. Was diese Statistiken sind, sollten Sie Ihre Lösung fahren.

Ich kann nicht auf der Leistung der MySQL-Abfrage Kommentar zu Knoten-IDs auszuwählen. Ich denke, das kommt darauf an, wie viele Knoten, die Sie benötigen, um zu wählen und Ihre Indexierungsstrategie. Ich stimme über die Performance-Seite der Dinge, wenn es darum geht, obwohl ein Diagramm zu durchqueren.

Dies ist ein guter Artikel über eben diese: MySQL vs. Neo4j auf einem Groß Graph Traversal und in diesem Fall, wenn sie sagen, groß, meinen sie nur eine Million Eckpunkten / Knoten und vier Millionen Kanten. So ist es nicht einmal ein besonders dichtes Graphen war.

Andere Tipps

kann Relationale Datenbanken Graphenstrukturen handhaben. Einige von ihnen können sogar handhaben mäßig elegant (so elegant wie eine relationale Datenbank wird!).

Der Schlüssel zum allgemeinen Graphen in relationalen Datenbanken ist die Handhabung der rekursive allgemeine Tabellen Ausdruck (RCTE), die Sie im Grunde iterativ lässt (nicht rekursiv, trotz des Namens) eine Abfrage über einen Satz von Zeilen erweitern, indem Sie eine Abfrage kombinieren, die eine Wurzel Satz von Zeilen und eine Abfrage auswählt, die die Nachbarn definiert von Zeilen so weit ausgewählt. Die Syntax ist ein wenig klobig, aber es ist allgemein und mächtig.

RCTEs sind in PostgreSQL, Firebird, SQL Server, unterstützt und offenbar in DB2. Oracle hat ein anderes, aber äquivalentes Konstrukt; Ich habe gelesen, dass die jüngsten Versionen richtiges RCTEs unterstützen. MySQL nicht RCTEs unterstützen. Wenn Sie nicht auf MySQL fest gebunden sind, würde ich Sie bitten, mit PostgreSQL zu betrachten, die alle rund um grundsätzlich eine viel bessere Datenbank ist.

Allerdings klingt es wie Sie allgemein nicht Diagramme unterstützen müssen, nur Bäume. In diesem Fall gibt es mehr spezifische Möglichkeiten offen.

Eine davon ist die klassische, sondern mindbending verschachtelte Sätze .

Ein einfacher ist einen Pfad mit jeder Zeile zu speichern: Dies ist eine Zeichenfolge, die die Position in dem Baum der Zeile repräsentiert, und hat die Eigenschaft, dass der Weg für einen Knoten ein Präfix des Pfades für jeden Unterknoten ist, der ermöglicht Sie sehr effizient verschiedene Fragen über herkunft zu tun ( „Knoten A ist ein Kind des Knotens B?“, „was Knoten A und dem niedrigsten gemeinsamen Vorfahren des Knotens B?“, etc.). Zum Beispiel könnten Sie einen Pfad für eine Reihe von Fuß des Baumes von der Wurzel, und Verbinden des IDs der Zeilen angetroffen auf dem Weg mit Schrägstrichen konstruieren. Das ist einfach zu konstruieren, aber tut kümmern zu halten, wenn Sie den Baum neu anordnen. Mit einer Pfad-Spalte können Sie eine Abfrage zu einem bestimmten Baum beschränken einfach durch and path like '23/%' Zugabe, wo 23 die ID des root.

Also, auch wenn eine Graph-Datenbank ist wahrscheinlich der beste Weg, um Speicher und Abfragediagrammdaten, es ist nicht die einzige Option, und ich würde vorschlagen, dass Sie die Vorteile der Verwendung eines gegen die Vorteile, alle Ihre Daten in einem einzelnen wiegen Datenbank.

Ich bin meistens mit Binary-Nerd auf diese, möchte aber eine Variation hinzuzufügen. Sie können die Live-Daten in Neo4j speichern und dann die Daten extrahieren, die Sie für die Statistik benötigen / Reporting und in MySQL. Für die Suche würde ich mit der Neo4j-Lucene Integration gehen, wenn das Ihre Bedürfnissen entspricht.

Sie können die Abfrage verbessern, indem Sie sich mit:

SELECT *
FROM items
WHERE item_id IN (45, 345435, 343, 78, 4522, 676, 443, 4255, 4345)

Es ist auch nicht ganz richtig, dass relationale Datenbanken schlecht sind am Baum speichern Strukturen. Sicherlich ist MySQL einige Funktionen fehlen, die machen, es wäre einfacher, aber die meisten anderen Datenbanken unterstützen es gut. Oracle hat CONNECT BY. Die meisten der Mainstream-RDBMS haben irgendeine Form von rekursiven Abfragen - MySQL eine bemerkenswerte Ausnahme. Vielleicht könnten Sie einen Blick auf PostgreSQL nehmen und sehen, ob das Ihren Bedürfnissen entspricht?

Lizenziert unter: CC-BY-SA mit Zuschreibung
Nicht verbunden mit StackOverflow
scroll top