Dies ist eine Frage zur Best Practice, ich verstehe, dass es viele verschiedene Möglichkeiten dafür gibt, aber ich würde gerne Ihre Meinung dazu hören, wie Sie dieses Problem lösen würden. Bitte nehmen Sie es als ob Leistung in diesem System kritisch ist, mit anderen Worten skalierbar.
Ich habe kürzlich die Wunder der graph Datenbank gefunden, also habe ich eine theoretische Situation gefunden, in der ein Unternehmen seine Kundenbeziehungen verwalten will, und um dies zu tun, werden sie neo4j verwenden, was großartig ist und es ermöglicht wirklich tolles Management der Kunden, verschiedener Mitarbeiter und ihrer Beziehungen, das ist alles großartig, jedoch möchte das Unternehmen nun eine webbasierte Schnittstelle erstellen, die eine Authentifizierung benötigt, und jeder in der neo4j-Datenbank sollte sich in das System einloggen können Um zu sehen, wie sie mit anderen Personen in der Unternehmensdatenbank zusammenhängen, muss jeder Benutzer ein Passwort / eine E-Mail / ID mit seinem Namen verknüpft haben.
Also ist meine Frage, in diesem Fall, ist es am besten, die password_hash / password_salt / id / email in einer mysql Datenbank zu speichern und dann basierend auf dem Knoten in der mysql Datenbank nachzuschlagen. Oder ist es besser, die Datei password_hash / password_salt / id / email in den Hash-Tabellen innerhalb der Knoten zu speichern.
Auch jedes Geschäft hat 1000 Produkte, und sie können in der Graph-Datenbank gespeichert werden oder ich kann die Produkte in der MySQL-Datenbank speichern und dann das Produkt dort nachschlagen und die Änderungen dort vornehmen, weil die Produkte nicht verwandt sind Da es keinen Sinn macht, sie in der Graphdatenbank zu speichern, sollten sie nicht dort gespeichert werden, um die Leistung zu verbessern?
Also meine Frage läuft darauf hinaus: ist es am besten für große Projekte, eine Graphdatenbank zusammen mit der gebräuchlicheren rdms-Datenbank wie mysql zu verwenden? Wenn nicht, an welchem Punkt fangen Sie an, diese beiden Datenbanksysteme zu verwenden?
entschuldigt mich im Voraus für meinen Mangel an Wissen in Bezug auf die Terminologie der Datenbank.
Graph DB wird hauptsächlich für die Pflege von Beziehungen verwendet. Wenn App eine Grafik-DB hat, bedeutet das nicht, dass die App alles in Graph DB speichern muss.
Jede Knotenanforderung in Graph befindet sich im Speicher, und wenn Sie also unnötige Eigenschaften in Ihrem Knoten haben, wird er aufgebläht und kann die Dinge verlangsamen und mehr Speicher verbrauchen. Normalerweise entscheide ich, was in graph gehen soll und was hinein muss DB durch sehr einfache Regel.
High-Level-Eigenschaft (die die Relation und andere wichtige Eigenschaften definiert, die den Knoten definieren) wird im Diagramm angezeigt, während zusätzliche Informationen in RDMS eingehen.
Zum Beispiel kann im FB FBID sein, Name geht in Graph, da er die Beziehung eines Knotens mit einem anderen definiert. Aber wenn der Benutzer auf jemandes Facebook ID klickt, sieht er / sie andere Benutzer DOB, Alter, College. Alle diese können in RDBMS gehen.
PS: RDMS hat einen weiteren Vorteil, es kann für schnelle Analysen verwendet werden. Ich weiß mit Graphen auch, dass Sie das tun können, aber ich bin mir nicht sicher, ob es so skalierbar und einfach wie RDBMS ist.
Nachteil dieses Ansatzes ist: Sie müssen zwei DBS pflegen.
Wenn Sie nicht einen bewährten Fall für eine Zwei-DB-Lösung haben, würde ich sagen, dass Sie durch weniger bewegliche Teile agiler und schneller in der Lage wären, Dinge zu ändern. Wenn Sie später einen schwierigen Anwendungsfall finden, wägen Sie den Kosten- Nutzen-Effekt eines zweiten Speichers ab. Eine Zwei-DB-Architektur ist nicht unbekannt, kommt aber mit einem Overhead.
Für die Sicherheit gibt es keinen Grund, warum Neo4j oder eine andere vernünftige NOSQL-Lösung das nicht tun könnte: Ссылка
Sie sollten beide verwenden, wenn es Daten gibt, bei denen es nicht sinnvoll ist, sie in einer Graphen-DB wie neo4j / orientDB zu speichern (und einige Daten wären besser in einer Graph-DB als in einer relationalen DB) . Das Erzwingen von Daten auf einer Plattform kann Probleme mit der Leistung / Skalierbarkeit auf der ganzen Linie verursachen.
Tags und Links nosql neo4j graph-databases rdbms