<p><strong>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.</strong></p>
<p>J’ai validé certaines solutions de bases de données graphes utilisables par Node.js pendant quelques semaines. <strong>Mon cas d’utilisation est de sauvegarder les interactions de différents comptes de réseaux sociaux</strong>. Le besoin est d’<strong>utiliser le CPU et la mémoire de la manière la plus efficace possible</strong>.</p>
<p>Mes exigences les plus importantes sont :</p>
<ul>
<li>
<p>en mémoire (au moins pour l’indexation)</p>
</li>
<li>
<p>open source (et libre d’utilisation)</p>
</li>
<li>
<p>même performance <strong>JavaScript/Node.js</strong> en tant que citoyen de premier plan</p>
</li>
<li>
<p><strong>langage de requête et de modélisation confortable</strong></p>
</li>
</ul>
<p><strong>Neo4J</strong></p>
<p>J’aime vraiment <a href="http://neo4j.com/developer/cypher-query-language/" rel="noopener nofollow ugc">cypher</a> donc mon meilleur choix serait Neo4j.<br>
Mais le problème majeur de Neo4j est que l’accès JavaScript n’est pas natif. Il utilise l’API REST qui est <a href="https://groups.google.com/forum/#!topic/neo4j/uLV-EmlCsdc" rel="noopener nofollow ugc">environ dix fois (10x) plus lente</a> que l’accès Java direct. J’ai donc regardé <a href="https://github.com/joewhite86/node-neo4j-embedded" rel="noopener nofollow ugc">node-neo4j-embedded</a>, mais il est inactif depuis plus de deux ans. Il semble que son <a href="https://github.com/joewhite86" rel="noopener nofollow ugc">auteur</a> ne soit plus du tout actif (mauvais signe).</p>
<p><strong>ArangoDB</strong></p>
<p>Les développeurs principaux vraiment sympathiques d’ArangoDB ont répondu à <a href="https://stackoverflow.com/questions/31534200/what-parts-of-arangodb-are-done-with-node-gyp" rel="noopener nofollow ugc">ma question</a> sur les composants internes. Finalement, cela signifie que <a href="https://github.com/arangodb/arangojs" rel="noopener nofollow ugc">JavaScript</a> 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é <a href="https://github.com/joewhite86/node-neo4j-embedded" rel="noopener nofollow ugc">node-neo4j-embedded</a> pour leur benchmark. Les benchmarks comparent les API REST (modifié suite au commentaire de <span class="mention">@weinberger</span>). J’aurais souhaité qu’ils comparent les API natives (peut-être que quelqu’un est assez curieux pour essayer ! - faites-nous savoir !). <strong>Mise à jour</strong> : Comme je l’ai remarqué maintenant, OrientDB a <a href="http://orientdb.com/orientdb-performance-challenge/" rel="noopener nofollow ugc">répondu au benchmark</a> avec un nouveau pilote Node.js (utilisant le <a href="http://orientdb.com/docs/last/Command-Cache.html" rel="noopener nofollow ugc">Command Cache</a> en démarrant le serveur avec <em>-Dcommand.cache.enabled=true -Dcommand.cache.minExecutionTime=3</em>, <strong>ce qui n’est pas équitable, car ce n’était pas un benchmark de cache de requêtes !</strong>)</p>
<p>Comme j’aime utiliser ArangoDB comme base de données graphe, j’aurais 3 choix (source : <a href="https://www.arangodb.com/faq/" rel="noopener nofollow ugc">FAQ</a>) :</p>
<ul>
<li>
<p>traverser des <a href="https://docs.arangodb.com/General-Graphs/FluentAQLInterface.html" rel="noopener nofollow ugc">objets JS</a></p>
</li>
<li>
<p>utiliser les <a href="https://docs.arangodb.com/Aql/GraphOperations.html" rel="noopener nofollow ugc">fonctions graphes d’AQL</a></p>
</li>
<li>
<p>utiliser l’<a href="https://docs.arangodb.com/HttpGharial/Management.html" rel="noopener nofollow ugc">API REST</a></p>
</li>
</ul>
<p>En général, ce <strong>n’est pas aussi confortable</strong> 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 <a href="http://neo4j.com/developer/data-modeling/" rel="noopener nofollow ugc">Neo4J l’explique très bien</a>). 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 (<a href="http://de.slideshare.net/lvca/why-relationships-are-cool-but-join-sucks-28997951" rel="noopener nofollow ugc">la raison d’utiliser les graphes au lieu de relations avec des jointures</a>).</p>
<p><strong>MongoDB</strong></p>
<p>Le MongoDB basé sur les documents n’est pas optimisé pour les opérations graphes mais <a href="https://www.mongodb.com/blog/post/whats-new-mongodb-30-part-3-performance-efficiency-gains-new-storage-architecture" rel="noopener nofollow ugc">a récemment obtenu un moteur de stockage en mémoire expérimental</a>. Il existe aussi des projets soit en mémoire soit liés aux graphes, mais rien n’est vraiment convaincant. Et dans <a href="https://stackoverflow.com/questions/26704134/mongodb-neo4j-vs-orientdb-vs-arangodb" rel="noopener nofollow ugc">cette discussion</a>, il semble que MongoDB ne soit pas ce que je souhaite utiliser.</p>
<p><strong>OrientDB</strong></p>
<p>Comme il existe une comparaison entre <a href="http://orientdb.com/orientdb-vs-mongodb/" rel="noopener nofollow ugc">OrientDB et MongoDB</a> (de la part d’OrientDB), j’ai pensé à utiliser celui-ci. “<em>OrientDB a un moteur hybride Document-Graphe</em>” utilisant SQL. Je suis un ancien expert PHP/MySQL. Mais où est la partie modélisation ? Leur chapitre <a href="http://orientdb.com/docs/last/Tutorial-Working-with-graphs.html" rel="noopener nofollow ugc">travailler avec les graphes</a> 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.<br>
Si quelqu’un a effectué un processus de modélisation avec OrientDB et les graphes, peut-être pourriez-vous écrire un tutoriel comme <a href="http://neo4j.com/developer/data-modeling/" rel="noopener nofollow ugc">Neo4J l’a fait</a>.</p>
<p><strong>Mise à jour</strong> : Concernant l’accès JavaScript en tant que citoyen de premier plan, <a href="http://orientdb.com/welcome-to-orientjs/" rel="noopener nofollow ugc">il y a des nouveautés</a> :<br>
“<em>Dans la prochaine version, la vitesse de ce pilote sera <strong>comparable à celle du pilote Java natif</strong></em>” Le pilote Node.js forké <a href="https://github.com/orientechnologies/orientdb/issues?q=is%3Aissue%20milestone%3A2.1-rc5%20is%3Aclosed" rel="noopener nofollow ugc">a été corrigé ces derniers jours</a>.</p>
<p><strong>Mise à jour</strong> : Avant de choisir OrientDB, on pourrait vouloir lire <a href="http://orientdbleaks.blogspot.com/2015/06/the-orientdb-issues-that-made-us-give-up.html" rel="noopener nofollow ugc">un article sur certains problèmes</a> et les discussions qui y sont liées. L’article touche un sujet sensible et devrait être abordé avec un esprit critique. <em>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.</em></p>
<p><strong>LokiJS</strong></p>
<p>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 <a href="http://lokijs.org" rel="noopener nofollow ugc">LokiJS</a>, 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 <a href="https://github.com/techfort/LokiJS/issues/185" rel="noopener nofollow ugc">mauvaise capacité à monter en charge</a>. 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 <em>dispersée</em> (peut-être devraient-ils redémarrer avec GitBook).<br>
Finalement, LokiJS est un projet très intéressant et j’espère qu’ils continueront à avancer !</p>
<p><strong>LevelDB</strong></p>
<p>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é <em>LevelDB en mémoire</em> et j’ai obtenu un résultat prometteur appelé <a href="https://github.com/Level/memdown" rel="noopener nofollow ugc">MemDown</a> (voir <a href="http://nodejsconfit.levelgraph.io/#13" rel="noopener nofollow ugc">aussi</a>). 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.</p>
<p><strong>Modification :</strong> Suite à un commentaire, voici un lien vers <a href="https://www.npmjs.com/package/levelgraph" rel="noopener nofollow ugc">LevelGraph</a>. Comme idée pour implémenter un analyseur CYPHER pour LevelGraph/LevelDB, votre point de départ serait de comparer</p>
<p><a href="http://neo4j.com/developer/cypher-query-language/" rel="noopener nofollow ugc">Cypher</a> :</p>
<pre><code class="lang-auto">CREATE (SUBJECT:"a") - [b😛REDICATE] -> (OBJECT:"c")
RETURN, subject, predicate, object
</code></pre>
<p><a href="https://www.npmjs.com/package/levelgraph" rel="noopener nofollow ugc">LevelGraph</a> :</p>
<pre><code class="lang-auto">var RETURN = { SUBJECT: "a", PREDICATE: "b", OBJECT: "c" };
db.put(RETURN, function(err) {
// ..
});
</code></pre>
<p><strong>Conclusion</strong></p>
<p>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 <strong>devenir un bon aperçu de comment modéliser les données pour les graphes.</strong></p>
<p>@éditeurs : <em>Vous êtes les bienvenus.</em></p>
<p><span class="mention">@commentateurs</span> : <em>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).</em></p>
