Quelques réflexions à ce sujet :
J'essaierais de modéliser votre modèle de domaine Neo4j pour inclure les attributs de chaque nœud dans le graphique. En séparant vos données dans deux magasins de données différents, vous pouvez limiter certaines opérations que vous pourriez souhaiter effectuer.
Je suppose que cela dépend de ce que vous allez faire avec votre graphique. Si, par exemple, vous voulez trouver tous les nœuds connectés à un nœud spécifique dont les attributs (c'est-à-dire le nom, l'âge, etc.) sont certaines valeurs, devriez-vous d'abord trouver le bon ID de nœud dans votre base de données MySQL, puis aller dans Néo4j ? Cela semble juste lent et trop compliqué alors que vous pourriez faire tout cela dans Neo4j. La question est donc :aurez-vous besoin des attributs d'un nœud lors de la traversée du graphe ?
Vos données vont-elles changer ou sont-elles statiques ? En ayant deux magasins de données distincts, cela compliquera les choses.
Bien que générer des statistiques à l'aide d'une base de données MySQL puisse être plus facile que de tout faire dans Neo4j, le code nécessaire pour parcourir un graphe pour trouver tous les nœuds qui répondent à un critère défini n'est pas trop difficile. Ces statistiques devraient guider votre solution.
Je ne peux pas commenter les performances de la requête MySQL pour sélectionner les identifiants de nœud. Je suppose que cela dépend du nombre de nœuds que vous devrez sélectionner et de votre stratégie d'indexation. Je suis cependant d'accord sur le côté performance des choses lorsqu'il s'agit de parcourir un graphique.
Voici un bon article à ce sujet :MySQL contre Neo4j sur un Traversée de graphes à grande échelle et dans ce cas, quand ils disent grand, ils ne signifient qu'un million de sommets/nœuds et quatre millions d'arêtes. Ce n'était donc même pas un graphique particulièrement dense.
