2017-09-14 1 views
1

Je suis nouveau sur neo4j et tente actuellement de migrer des données existantes vers une base de données neo4j. J'ai écrit un petit programme pour convertir les données actuelles (au format sur mesure) en une grande requête de chiffrement CREATE pour la population initiale de la base de données. Ma première itération consistait à conserver quelque peu la structure du modèle objet existant, par exemple les objets deviennent des nœuds, le type de nœud est le même que le nom d'objet dans le modèle objet courant et les membres deviennent propriétés (nom de membre est nom de propriété). Ceci est fait pour tous les types fondamentaux (et les chaînes) et tous les objets membres sont ainsi décomposés de la même manière que dans le modèle d'objet original.Le client Web Neo4j échoue avec une requête Cypher CREATE volumineuse. 144000 lignes

Cela a été très bien en termes de performances et plus de 13 000 requêtes de chiffrement de ligne CREATE ont été générées et peuvent être exécutées via l'interface web/client. Cependant, le modèle n'est pas idéal pour une base de données de graphes, je crois, puisqu'il peut y avoir beaucoup de propriétés, et je voudrais plutôt décomposer ces nœuds «fondamentaux» (avec des membres qui sont des types fondamentaux) dans leur propre nœud. nœud "abstrait" qui représente l'objet/classe de niveau supérieur. Cela signifie que chaque membre est un nœud avec une seule propriété (dans un premier temps, il peut s'agrandir), par exemple {value: "42"}, ou que je peux définir le type de nœud sur le type de données (i.e integer). Si ma compréhension est correcte, cela me permettrait également de créer des relations entre les «membres» (car ce sont des nœuds et non des propties) permettant une plus grande liberté d'expression entre les membres originaux des différents objets plutôt que de se relier les uns aux autres . Le problème est que ceci génère maintenant des requêtes Cypher 144000+ lignes (et ce n'est pas un grand ensemble de données en comparaison avec d'autres) que le client neo4j semble en vrac. Le surlignage de code semble fonctionner dans la zone de saisie de la requête du client (c'est-à-dire qu'il met en surbrillance correctement, ce qui suppose qu'il l'a analysé correctement et est une requête chiffrée valide), mais lorsque je lance la requête, répondre, puis une erreur de débordement de pile (pas punn intentionnelle). Quoi de plus le client neo4j ne quitte pas élégamment et exige toujours de moi pour forcer la fin de la tâche et la db est dans l'utilisation de 2,5-3 Go de, ce qui est effectivement et une petite quantité de données (144000 lignes, environ 2/3 sont des relations ainsi la plupart ~ 48000 noeuds). Pourtant, j'ai lu que je devrais être capable de gérer des millions de nœuds et de relations en millisecondes?

L'ai essayé avec firefox et chrome. J'utilise l'édition de la communauté neo4j sur windows10. Le sdk serait initialement utilisé avec C# et C++. Cette recherche est dans sa phase initiale, donc je n'ai pas encore utilisé le sdk.

Est-ce une approche valide, c'est-à-dire de remplir initialement la base de données via une requête CREATE? Mon approche de la décomposition des données en types fondamentaux est-elle également bonne? ou y a-t-il des problèmes susceptibles de découler de cette approche?

Merci à l'avance.

Répondre

2

C'est une très grande requête Cypher !!!

Vous feriez beaucoup mieux de remplir votre base de données en utilisant LOAD CSV FROM... et en fournissant un fichier CSV contenant les données que vous souhaitez charger.

Pour une explication détaillée, un coup d'oeil à: (. Cette page traite également le chargeur de lots pour les ensembles de données très grandes)

https://neo4j.com/developer/guide-import-csv/

Puisque vous génération de code pour la requête Cypher Je n'imaginerais pas que vous auriez trop de mal à générer un fichier CSV.

(A titre indicatif de la performance, je suis en train de charger un 1 million enregistrement CSV aujourd'hui en cours d'exécution Neo4j sur mon ordinateur portable en moins de deux minutes.)

+0

Merci, je soupçonner ce début. – lfgtm