Je suis à court d’idées et j’espère obtenir des retours utiles. J’utilise cette question pour compresser mes expériences et les partager, en espérant inspirer certains distributeurs à franchir la prochaine étape avec la modélisation des bases de données graphes comme question/approche de premier plan.
J’ai validé certaines solutions de bases de données graphes utilisables par Node.js pendant quelques semaines. Mon cas d’utilisation est de sauvegarder les interactions de différents comptes de réseaux sociaux. Le besoin est d’utiliser le CPU et la mémoire de la manière la plus efficace possible.
Mes exigences les plus importantes sont :
-
en mémoire (au moins pour l’indexation)
-
open source (et libre d’utilisation)
-
même performance JavaScript/Node.js en tant que citoyen de premier plan
-
langage de requête et de modélisation confortable
Neo4J
J’aime vraiment cypher donc mon meilleur choix serait Neo4j.
Mais le problème majeur de Neo4j est que l’accès JavaScript n’est pas natif. Il utilise l’API REST qui est environ dix fois (10x) plus lente que l’accès Java direct. J’ai donc regardé node-neo4j-embedded, mais il est inactif depuis plus de deux ans. Il semble que son auteur ne soit plus du tout actif (mauvais signe).
ArangoDB
Les développeurs principaux vraiment sympathiques d’ArangoDB ont répondu à ma question sur les composants internes. Finalement, cela signifie que JavaScript est un citoyen de premier plan car les requêtes natives peuvent être exécutées depuis JS. En regardant les benchmarks open source, je pense que c’est équitable. Mais je crains qu’ils n’aient pas utilisé node-neo4j-embedded pour leur benchmark. Les benchmarks comparent les API REST (modifié suite au commentaire de @weinberger). J’aurais souhaité qu’ils comparent les API natives (peut-être que quelqu’un est assez curieux pour essayer ! - faites-nous savoir !). Mise à jour : Comme je l’ai remarqué maintenant, OrientDB a répondu au benchmark avec un nouveau pilote Node.js (utilisant le Command Cache en démarrant le serveur avec -Dcommand.cache.enabled=true -Dcommand.cache.minExecutionTime=3, ce qui n’est pas équitable, car ce n’était pas un benchmark de cache de requêtes !)
Comme j’aime utiliser ArangoDB comme base de données graphe, j’aurais 3 choix (source : FAQ) :
-
traverser des objets JS
-
utiliser les fonctions graphes d’AQL
-
utiliser l’API REST
En général, ce n’est pas aussi confortable que Cypher. Et je ne suis pas sûr de comment comparer et quelle est la bonne façon de modéliser les données (comme Neo4J l’explique très bien). J’adorerais avoir quelque chose comme ça pour les graphes ArangoDB. On a l’impression qu’ArangoDB est focalisé sur les opérations graphes et que Neo4J correspond davantage aux besoins d’utilisation des graphes quand vous avez plus de relations que de lignes (la raison d’utiliser les graphes au lieu de relations avec des jointures).
MongoDB
Le MongoDB basé sur les documents n’est pas optimisé pour les opérations graphes mais a récemment obtenu un moteur de stockage en mémoire expérimental. Il existe aussi des projets soit en mémoire soit liés aux graphes, mais rien n’est vraiment convaincant. Et dans cette discussion, il semble que MongoDB ne soit pas ce que je souhaite utiliser.
OrientDB
Comme il existe une comparaison entre OrientDB et MongoDB (de la part d’OrientDB), j’ai pensé à utiliser celui-ci. “OrientDB a un moteur hybride Document-Graphe” utilisant SQL. Je suis un ancien expert PHP/MySQL. Mais où est la partie modélisation ? Leur chapitre travailler avec les graphes n’est pas comparable à Cypher. C’est comme utiliser SQL pour les graphes. Il n’y a rien de mal à cela, mais après avoir utilisé Cypher, le sentiment de modélisation me manque.
Si quelqu’un a effectué un processus de modélisation avec OrientDB et les graphes, peut-être pourriez-vous écrire un tutoriel comme Neo4J l’a fait.
Mise à jour : Concernant l’accès JavaScript en tant que citoyen de premier plan, il y a des nouveautés :
“Dans la prochaine version, la vitesse de ce pilote sera comparable à celle du pilote Java natif” Le pilote Node.js forké a été corrigé ces derniers jours.
Mise à jour : Avant de choisir OrientDB, on pourrait vouloir lire un article sur certains problèmes et les discussions qui y sont liées. L’article touche un sujet sensible et devrait être abordé avec un esprit critique. Note de l’auteur de cette mise à jour : je suis nouveau dans l’édition sur SO et n’ai pas assez de réputation pour mettre ceci en commentaire. Je crois que cette information est un point valide pour la discussion, je ne suis pas sûr de comment la placer ici selon les règles de SO.
LokiJS
Avant de regarder Neo4J, ArangoDB et MongoDB, j’ai joué avec cette base de données en mémoire basée sur JavaScript appelée LokiJS, qui semble suivre la stratégie d’ignorer tout ce qui ralentit les performances et l’efficacité. LokiJS essaie de compléter le style Mongo (feuille de route). Le problème majeur est la mauvaise capacité à monter en charge. Bien sûr ce n’est pas une base de données graphe mais c’était une solution intéressante au début de mon projet. Ce n’était pas non plus un sentiment parfait de trouver toute la documentation dispersée (peut-être devraient-ils redémarrer avec GitBook).
Finalement, LokiJS est un projet très intéressant et j’espère qu’ils continueront à avancer !
LevelDB
Précédemment, lorsque j’ai écrit mon mémoire de diplôme, j’ai regardé LevelDB. En me souvenant de cela en écrivant cet article, j’ai cherché LevelDB en mémoire et j’ai obtenu un résultat prometteur appelé MemDown (voir aussi). Je n’ai pas testé cette trouvaille, mais peut-être que quelqu’un a de l’expérience avec cette solution. Peut-être que ce serait le moyen le plus efficace si tous les autres ne conviennent pas, car j’écrirais simplement un clone léger de Cypher avec l’objectif de rester aussi léger que possible.
Modification : Suite à un commentaire, voici un lien vers LevelGraph. Comme idée pour implémenter un analyseur CYPHER pour LevelGraph/LevelDB, votre point de départ serait de comparer
Cypher :
CREATE (SUBJECT:"a") - [b:PREDICATE] -> (OBJECT:"c")
RETURN, subject, predicate, object
var RETURN = { SUBJECT: "a", PREDICATE: "b", OBJECT: "c" };
db.put(RETURN, function(err) {
// ..
});
Conclusion
Comme vous l’avez probablement remarqué, je ne suis pas le super héros des graphes. Mais c’est ma première plongée dans le sujet et j’essaie d’avoir une vue d’ensemble. Je suppose qu’il y a beaucoup de gens là-bas qui veulent poser les mêmes questions que moi mais n’ont pas le temps. J’espère que cet article aidera beaucoup de personnes et évoluera grâce aux commentaires et réponses pour devenir un bon aperçu de comment modéliser les données pour les graphes.
@éditeurs : Vous êtes les bienvenus.
@commentateurs : Ceci est le résultat de ma recherche personnelle - si vous avez aussi fait un parcours comme le mien, veuillez répondre avec un court résumé comme je l’ai fait pour chaque base de données que j’ai évaluée (n’oubliez pas de cibler mes 4 objectifs).
