Gérer les connexions concurrentes de neo4j avec des goroutines

Question

Nous avons été chargés de migrer un grand nombre de données xml (1,27 million de fichiers xml, un nœud avec des propriétés par fichier) dans un graphe Neo, et nous avons utilisé des routines go pour traiter les fichiers, analyser le xml, préparer des requêtes cypher pour les insertions, etc. En raison de l'architecture du traitement du xml, nous utilisons des routines go simultanément avec des canaux pour traiter chaque fichier dans des threads, en limitant le nombre de travailleurs simultanés.

Le problème que je rencontre est que je rencontre des erreurs telles que "tcp connection reset by peer" et aussi "panic : Impossible de lire les octets attendus pour la longueur du message. Read : 0 Expected : 2" et je ne peux qu'imaginer que cela est dû à l'exécution simultanée de connexions et d'instructions dans nos travailleurs. Notre système d'étranglement nous limite à 100 travailleurs simultanés, et je ne pense pas que ce soit un problème majeur pour Neo, mais je n'arrive pas à comprendre pourquoi il nous étouffe.

Existe-t-il des recommandations en matière d'architecture pour traiter un cas d'utilisation comme celui-ci, où nous devons exécuter des instructions de chiffrement uniques dans un grand nombre de routines de travail (dans notre cas, 100 à la fois) ?

Actuellement, nous parcourons une arborescence de fichiers pour construire une file d'attente de fichiers à traiter, puis, une fois la marche terminée, nous itérons cette file d'attente et lançons des routines pour traiter chaque fichier, en utilisant un canal throttle tamponné pour bloquer le lancement de nouvelles routines jusqu'à ce que les routines précédentes soient terminées. Dans chaque routine, je lance une nouvelle connexion, une instruction de préparation, une exécution, une fermeture, etc.

Je vois que ce paquet offre des Pipelines, mais je ne sais pas comment l'utiliser dans l'architecture de traitement/queue/canal que nous avons actuellement :

https://github.com/johnnadratowski/golang-neo4j-bolt-driver

J'ai également essayé d'utiliser :

https://github.com/go-cq/cq

Mais continuez à obtenir tcp connection reset by peer lorsque l'on essaie de se connecter simultanément à Neo.

Answer 1

Il est possible que vous utilisiez une fonctionnalité non sécurisée dans le pilote neo4j-bolt.

Il existe 2 versions de pilotes fournis par Neo4j-bolt-driver :

1. Driver Conducteur ordinaire
2. DriverPool Pilote qui gère le pool de connexion

Les objets du pilote eux-mêmes sont à l'abri des threads, mais les objets Conn qui représentent la connexion sous-jacente ne le sont pas. Vous utilisez peut-être l'objet Conn d'une manière qui n'est pas censée l'être.

Avec les goroutines, il est préférable de créer Conn objets en utilisant DriverPool des méthodes. Lorsque Close est appelé sur la connexion, il ne ferme pas nécessairement la connexion sous-jacente et récupère la connexion pour la réutiliser.