Technologies

Meeting Neo4j, NoSQL

Publié le : Auteur: Kevin BIGER Laisser un commentaire
technologies

Contexte du meeting

Le 5 janvier 2013, Zenika organisait une journée de tutoriel sur la technologie Neo4j dans ses locaux parisiens. Ce fut l’occasion pour Sodifrance de s’y présenter, rencontrer des intervenants de NeoTechnology et d’échanger autour de cette base de données NoSQL.

Les intervenants étaient :

  • Stefan Armbruster, consultant de NeoTechnology à Munich. C’est lui qui a parlé la majorité du temps.
  • Cedric Fauvet, commercial de NeoTechnology en France. C’est lui qui s’est occupé du discours commercial sur le reste du temps.

Nous étions une quinzaine d’auditeurs. Les personnes présentes étaient pour une grande majorité des consultants freelance.

NoSQL

Les bases de données NoSQL sont en pleine croissance, tant au niveau académique qu’industriel. Les plus connues restent les DocumentDB tels MongoDB ou les bases « clé-valeur » tels que Cassandra ou Redis.  Les bases NoSQL orientées graphes permettent une approche différente des données.
En effet les bases relationnelles ont une approche des données de manière « alignées », c’est à nous de créer des graphes implicites à l’aide de clés étrangères pour lier nos données.
Il en va de même pour les bases NoSQL orientées documents ou orientées clé-valeurs.
Les bases NoSQL orientées graphes permettent d’utiliser explicitement les relations entre données. Cette approche peut être parfaitement adaptée à certains besoins. Martin Fowler abordait le sujet en début d’année.

Cas d’utilisation

Le cas d’utilisation classique est celui des réseau sociaux avec les utilisateurs représentés comme les nœuds du graphes et les relations comme étant les arêtes du graphe. Mais de nombreux autre cas d’utilisation sont possibles.

Par exemple SFR utilise maintenant Neo4j pour détecter des pannes sur son réseau. Chaque switch, dslam, nra, fibre, fil cuivré ou client est modélisé dans un graphe dont chacun pourra imaginer la taille. A l’aide de ce graphe ils peuvent estimer les points faibles de leur réseau, les endroits critiques pouvant amener à des pannes massives. Mais ils peuvent également répercuter les remontées d’incident très rapidement et automatiser leurs tests de qualité de service de manière précise.

Cisco utilise Neo4j pour sa gestion des questions-réponses d’utilisateurs sur son site internet.

Chip (très connu en Allemagne) est un vendeur de logiciels et hardware. Ils l’utilisent pour gérer leur graphe de technologies dans leur catalogue et les avis des clients.

Glassdoor est sur le même marché que viadeo ou linkedIn. Ils ont migré toutes leurs données (personnes, relations entre personnes, entreprise, personne a travaillé dans telle entreprise…) sur Neo4j.

Côté technique

Neo4j est une base de donnée ACID (atomique, cohérente, isolée et durable), utilisable via une API Rest ou une API native Java, Spring Data, ruby, ruby on rails, PHP… Les utilisateurs ont pas mal de choix (il manque cependant C++).

Les objets que l’on manipule sont donc des nœuds et des relations. Ces deux objets portent des propriétés qui sont des couples String/Objet. Les relations ne sont pas orientées au sens strict du terme. Vous pouvez leur appliquer un sens mais elles sont navigables dans les deux sens. Vous pouvez remonter les relations à contre sens sans pour autant perdre en performance.

Requêtes

Une base NoSQL orientée graphe ne s’interroge pas en SQL, quel est alors le langage utilisé ?
Neo4j propose deux langages de requêtage sur les graphes : Gremlin et Cypher.

  • Gremlin est un langage permettant de requêter un graphe à la manière d’un langage impératif classique. Gremlin est une norme open-source faisant partie de l’ensemble Blueprint.
    Lorsque Gremlin est passé en version 2 il est devenu compliqué de rester compatible avec ce dernier.
    Neo4j a donc décidé de continuer à supporter Gremlin mais ne plus y contribuer. C’est maintenant aux utilisateurs de Neo4j d’installer manuellement un plug-in pour ce langage.
  • Cypher a été créé pour remplacer Gremlin dans Neo4j. C’est un langage assez similaire au SQL dans sa structure. Il est plus rapide et plus adapté à Neo4j.

A quoi ressemble du Cypher?

Si l’on considère des nœuds Entreprise et Employés et si l’on veut récupérer les employés de Sodifrance , la requête ressemblerait à ceci :

START root=NODE({Sodifrance})
MATCH root-[:emploie]->employe
RETURN employe;

On a donc un nœud d’entrée dans le graphe (ici {Sodifrance} qui est une variable) qui nous permet de faire une requête locale. On ne lance pas la requête sur l’ensemble du graphe mais de manière ciblée. Ensuite on liste les noeuds (nommés « employe ») qui sont reliés à Sodifrance par la relation « :emploie ».
On retourne directement une liste de personnes qui sont des nœuds, tout comme on aurait pu retourner leurs noms ou matricules.

Les mots clés WHERE, ORDER BY…sont également disponibles.

Vous pouvez également créer des entités, les supprimer, les modifier, avec des requêtes Cypher.

Et les index?

Neo4j utilise Lucene pour créer des index dans le graphe. Ces index peuvent être utilisés pour les nœuds ou les relations.

Vous pouvez créer autant d’index que vous le souhaitez, en conservant l’idée qu’abuser de ces index n’aura finalement que l’effet inverse de ce que l’on souhaite et se traduira par une baisse des performances.
Il faut également conserver en tête que Lucene n’est pas très performant dans les tris. Il sera donc préférable de faire sa requête en Cypher puis trier les données dans son langage préféré à l’aide d’un algorithme adapté.

On peut créer des index automatiques basés sur une (ou plusieurs) propriété de nœud (ou de relation). Cet index automatique est un hook sur les transactions. Il n’est donc pas rétro-actif. Il doit être pensé à la création de la base sous peine de devoir faire un travail de consolidation long et fastidieux.
Les index qui ne sont pas automatiques doivent être appelés à chaque création de nœud ou relation. Le terme d’index devient donc détourné de son sens initial, du moins tel qu’on le connait classiquement.

Comment mapper les objets sur une telle base?

Des solutions telles que Spring-Data existent. Bien entendu cette dernière n’est pas la plus performante même si l’utilisation de pojo (plain old java object) annotés est d’un grand confort d’utilisation.

Nos tests en interne ne se basent que sur des pojo qui encapsulent un nœud Neo4j. Ces mêmes pojo portent également les relations du graphe qui les concernent. Les performances sont bien sur plus importantes avec cette solution, même si le confort de code est moindre.

Est ce que ça tient la charge?

Cette thématique est apparue à plusieurs reprises. Il nous a été annoncé une capacité de 34 milliards d’objets gérés par Neo4j. Ce chiffre semble être assez théorique, et lié à l’utilisation de moyens extrêmes mais pose au moins une limite maximale.
Même si ce chiffre peut être discuté, il n’en reste pas moins que l’on utilise plusieurs millions d’objets dans certains proof of concepts sans soucis.

Pour ce qui est de la répartition sur cluster, des nouveautés semblent à venir. Wait for it.

Conclusion

Neo4j est une technologie dont la communauté croît chaque semaine. Elle est facilement utilisable, à travers spring-data ou non, en embarqué ou en rest, avec plusieurs langages compatibles, seule ou en complément d’un SGBDR et ses performances sont bonnes.

Si vous voulez vous familiariser avec une base de données NoSQL orientée graphe, c’est un bon choix.