Capacités et avenir de Janusgraph
Le projet sur lequel je travaille utilise actuellement la communauté Neo4j. Actuellement, nous traitons 1 à 5 M de sommets avec 5 à 20 M d'arêtes, mais nous visons à gérer un volume de 10 à 20 M de sommets avec 50 à 100 M d'arêtes. Nous discutons de l'idée de passer à un projet open source de base de données de graphes qui nous permettrait d'évoluer dans ces proportions. Actuellement, notre esprit est tourné vers Janusgraph avec Cassandra.
Nous avons quelques questions concernant les capacités et le développement de Janusgraph, nous serions heureux si quelqu'un pouvait répondre! (Peut-être Misha Brukman ou Aaron Ploetz?)
Sur les capacités de Janusgraph:
Nous avons fait quelques expériences en utilisant l'image docker prête à l'emploi de Janusgraph, les requêtes étant émises via un programme java. Le programme java et l'image docker sont exécutés sur la même machine. À la magnitude de 10k-20k sommets avec 50k-100k arêtes insérées, une requête avec tous les sommets possédant une propriété give prend 8 à 10 secondes (temps moyen sur 10 requêtes identiques, temps écoulé avant et après la commande dans le programme java ). La commande elle-même est vraiment simple:
g.V().has("secText", "some text").inE().outV();De plus, l'image du docker semble se décomposer lorsque j'essaie d'insérer plus d'enregistrement (s'étendant vers 100k sommets).
On se demande si cela est dû à la nature limitée de l'image du docker ou s'il y a un problème ou si cela pourrait être normal? Quoi qu'il en soit, cela semble vraiment très lent.
Nous avons mis en place un cluster Cassandra à 2 nœuds (sur 2 VM différentes) avec Janusgraph en ville, encore une fois, les résultats ont été assez lents.
D'après ce que j'ai lu sur Internet, les gens semblent utiliser le déploiement de Janusgraph avec des millions de sommets en production, donc je suppose qu'ils peuvent exécuter des requêtes simples en quelques millisecondes. Quel est le secret là-bas? Avez-vous besoin de 128 Go de RAM pour que tout fonctionne correctement? Ou peut-être existe-t-il un guide de bonnes pratiques à suivre que je ne connais pas? J'ai fait de mon mieux en utilisant la documentation officielle de Janusgraph et les commentaires des utilisateurs sur des forums comme ici, mais ce n'est pas grand-chose, j'ai peur: /
Sur l'avenir de Janusgraph:
- Janusgraph a semblé évoluer assez rapidement au cours des premières années (comme 2016-2018) mais ces derniers mois, je n'ai pas vu beaucoup d'activité de la communauté Janusgraph, à l'exception de la sortie de la version 0.5 il y a quelques mois. Par exemple, aucune réunion depuis l'année dernière. Je me demande donc: Janusgraph est-il sur la bonne voie pour durer et être maintenu pendant de nombreuses années à venir. Les choses ont-elles ralenti un peu à cause du COVID ou y a-t-il quelque chose?
- La rétrocompatibilité est-elle prise en compte dans Janusgraph? D'après ce que je peux lire dans la documentation, beaucoup de choses ont changé de la version 0.2 / 0.3 à 0.4 et 0.5. Beaucoup sont à venir comme, par exemple, Cassandra Thrift et embarqué étant obsolète. Ainsi, dans un environnement de production où nous ne pouvons pas toujours nous permettre de mettre à jour la version chaque année, laissez de côté la modification du code dans le cas où un composant est obsolète, Janusgraph dev pense-t-il bientôt atteindre une compatibilité descendante, ou peut-être devrions-nous encore attendre pour la version 1.0 pour ça?
Merci d'avoir lu tout cela et j'attends avec impatience toutes les réponses que vous pourrez me donner :) bonne journée!
Mael
Réponses
JanusGraph avec Cassandra a des limitations de conception au niveau de la couche de stockage, ce qui ralentit les performances. En pratique, il s'agit d'une base de données de graphes volumineuse, évolutive mais lente qui offre les avantages de réplication et de redondance de Cassandra.
Cassandra fragmente les données et est très efficace pour distribuer des données de manière aléatoire dans le cluster, mais cela détruit la localité des données qui est nécessaire pour rendre les traversées rapides et efficaces. JanusGraph prend également en charge plusieurs options de stockage back-end en plus de Cassandra, ce qui signifie qu'il n'est pas étroitement adapté à une architecture de stockage particulière.
La mémoire peut faire une différence, alors vérifiez la quantité de mémoire que vous avez allouée à la JVM sur chaque nœud, utilisez G1GC et désactivez le swap. VisualVM est utile pour profiler votre marge de mémoire.