Est-ce une bonne idée d'utiliser MySQL et Neo4j ensemble?

Question

Je vais faire une demande avec beaucoup d'articles similaires (en millions), et je voudrais les stocker dans une base de données MySQL, parce que je voudrais faire beaucoup de statistiques et de recherche sur des valeurs spécifiques pour les colonnes spécifiques.

Mais en même temps, je stockera les relations entre tous les éléments, qui sont liés dans de nombreux connectés structures arborescentes binaires (fermeture transitive) et les bases de données de relation ne sont pas bonnes à ce genre de structures, donc je comme stocker toutes les relations dans Neo4j qui ont de bonnes performances pour ce type de données.

Mon plan est d'avoir toutes les données sauf les relations dans la base de données MySQL et toutes les relations avec item_id stockées dans la base de données Neo4j. Quand je veux rechercher un arbre, je recherche d'abord le Neo4j pour tous les item_id: s dans l'arbre, je cherche la base de données MySQL pour tous les éléments spécifiés dans une requête qui ressemblerait à ceci:

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

Est-ce une bonne idée, ou suis-je très mal? Je ne l'ai pas utilisé les bases de données graphique-avant. Y a-t-il des meilleures approches à mon problème? Comment MySQL-requête effectuer dans ce cas?

Answer 1

Peu de pensées à ce sujet:

Je voudrais essayer la modélisation de votre modèle de domaine Neo4j pour inclure les attributs de chaque noeud dans le graphe. En séparant vos données dans deux magasins de données différentes, vous pouvez limiter certaines opérations que vous pouvez faire.

Je suppose que cela revient à ce que vous allez faire avec votre graphique. Si, par exemple, vous voulez trouver tous les noeuds connectés à un noeud spécifique dont les attributs (nom, âge .. peu importe) sont certaines valeurs, seriez-vous d'abord trouver l'ID de nœud correct dans votre base de données MySQL, puis allez dans Neo4j? Cela semble juste lent et trop compliqué quand on peut faire tout cela en Neo4j. La question est: vous avez besoin des attributs d'un noeud en traversant le graphique?

Est-ce que votre changement de données ou est-il statique? En ayant deux magasins de données séparées, il va compliquer les choses.

Alors que la production de statistiques en utilisant une base de données MySQL pourrait être plus facile que de faire tout Neo4j, le code nécessaire pour parcourir un graphique pour trouver tous les nœuds qui répondent à des critères définis n'est pas trop difficile. Ce que ces statistiques sont devrait conduire votre solution.

Je ne peux pas commenter les performances de la requête MySQL pour sélectionner ids de nœud. Je suppose que cela revient à combien de nœuds vous devez sélectionner et votre stratégie d'indexation. Je suis d'accord sur le côté de la performance des choses quand il s'agit de parcourir un graphique bien.

Ceci est un bon article sur ceci: MySQL vs Neo4j sur une grande échelle graphique Traversal et dans ce cas, quand ils disent grand, ils ne signifient un million de sommets / noeuds et quatre millions d'arêtes. Donc, il n'a même pas été un graphique particulièrement dense.

Answer 2

Bases de données relationnelles peuvent gérer des structures de graphes. Certains d'entre eux peuvent même les manipuler modérément avec élégance (comme avec élégance comme une base de données relationnelle est!).

La clé graphique générale dans le traitement des bases de données relationnelles est le table commune récursive expression (CRTE), qui essentiellement vous permet itérativement (non récursive, malgré le nom) développer une requête sur un ensemble de lignes, en combinant une requête qui sélectionne un ensemble racine de lignes et une requête qui définit les voisins de lignes sélectionnées jusqu'à présent. La syntaxe est un peu maladroit, mais il est général et puissant.

RCTEs sont pris en charge dans PostgreSQL, Firebird, SQL Server, et apparemment dans DB2. Oracle a une construction différente, mais équivalente; J'ai lu que les versions récentes prennent en charge RCTEs appropriées. MySQL ne supporte pas RCTEs. Si vous n'êtes pas marié à MySQL, je vous encourage vivement à envisager d'utiliser PostgreSQL, qui est essentiellement une base de données beaucoup mieux tout au long.

Cependant, il semble que vous n'avez pas besoin de soutenir les graphiques, mais uniquement les arbres. Dans ce cas, il existe des options plus spécifiques ouverts à vous.

L'un est le classique mais mindbending ensembles imbriqués .

A plus simple est de stocker un chemin à chaque rangée: ceci est une chaîne qui représente la position de la ligne dans l'arbre, et a la propriété que le chemin pour un noeud est un préfixe de la route pour chaque sous-noeud, ce qui permet de vous très efficacement faire diverses questions sur l'ascendance ( « est le nœud a un enfant du noeud B? », « quel est le nœud a et ancêtre commun le plus bas du noeud B? », etc.). Par exemple, vous pouvez construire un chemin pour une ligne en marchant l'arbre de la racine, et joindre les ID des lignes rencontrées sur le chemin avec des barres obliques. Ceci est simple à construire, mais ne prend soin de maintenir si vous réorganisez l'arbre. Avec une colonne de chemin, vous pouvez restreindre une requête à un arbre donné en ajoutant simplement and path like '23/%', où 23 est l'ID de la racine.

Ainsi, bien qu'une base de données graphique est probablement la meilleure façon de stocker et le graphique de la requête, il est pas la seule option, et je vous suggère de peser les avantages d'utiliser l'un contre les avantages d'avoir toutes vos données en un seul base de données.

Answer 3

Je suis la plupart du temps avec Nerd binaire sur ce point, mais je voudrais ajouter une variante. Vous pouvez stocker les données en temps réel dans Neo4j puis extraire les données dont vous avez besoin pour les statistiques / rapports et mis en MySQL. Pour les recherches je partirais avec l'intégration Neo4j-Lucene si cela correspond à vos besoins.

Answer 4

Vous pouvez améliorer la requête en utilisant IN:

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

Il est pas tout à fait vrai que les bases de données relationnelles sont mauvaises au stockage des structures d'arbres. Certes, MySQL manque certaines fonctionnalités qui rendrait plus facile, mais la plupart des autres bases de données soutiennent bien. Oracle a CONNECT BY. La plupart des SGBDR traditionnels ont une certaine forme de requêtes récursives - MySQL étant une exception notable. Peut-être que vous pourriez jeter un oeil à PostgreSQL et voir si cela répond à vos besoins?