Ce premier Octobre, Zenika accueillait de nouveau le groupe Meetup dédié à Neo4J. L’occasion de faire connaissance avec Spring Data grâce à Florent Biville.

Echauffement

Débuter un Meetup par l’interlude commercial, ce n’est pas nécessairement le meilleurs départ. Mais Cédric Fauvet connait au moins le public auquel il a à faire et il fut lui-même développeur. En fait, il a même évoqué deux ou 3 choses qui ont piqué ma curiosité !

La première réelle application de la théorie des graphes semble être celle des 7 ponts de Königsberg. Le seigneur du coin voulait savoir s’il était possible de faire un trajet dans la ville en passant une fois et une seule par chaque pont. Ce n’est pas possible et l’on peut s’en rendre compte de manière empirique, mais c’est Leonhard Euler qui le démontra mathématiquement.

Il n’y avait pas Neo4J à l’époque, mais aujourd’hui on en dispose et on résoud avec d’autres problèmes ayant trait à la théorie des graphes:

• Bien sûr il y a déjà le cas classique des réseaux sociaux, comme les suggestions de contacts utilisés par Viadeo.
• Les analyses d’impact sur les réseaux, mis en oeuvre chez SFR.
• Les calculs de primes de commerciaux, chez Sisco (!) Il ne faut pas moins de 2 clusters pou gérer cela.
• Le routage des colis chez un grand opérateur en Allemagne.

Aujourd’hui la communauté Française semble se porter plutôt bien, elle compte 362 personnes inscrites sur le Meetup et un nouveau Meetup va démarrer sur Lyon.
Du point de vue de l’actualité, c’est la version 2.0 qui occupe le terrain et doit être le sujet principal de Graph Connect.

Après le pizza-break, place au sujet principale de la soirée.

Spring Data

Nous sommes face à un dilemme aujourd’hui : le monde devient de plus en plus dynamique, ce qui fait la part belle à des bases de données orientées graphe telle que Neo4J. Et pas seulement cette dernière d’ailleurs, mais aussi des solution empruntant le même paradigme:

• Flock DB, une solution construite par Twitter.
• Titan, une base de données orientée graphes distribuée.
• Blueprint, qui est plutôt une abstraction au-dessus des bases de données graphe, mais aussi une stock logicielle offrant des fonctionnalités de plus haut niveau.
• RDF, l’ancêtre de ces bases de données, qui est une normalisation par le W3C des représentations de données sous forme de triplets.
• Orient DB qui mixte des fonctionnalités d’une base orientée documents avec une base orientée graphes.
• InfiniteGraph

Un dilemme disais-je, car si ces solutions adaptées aux problèmes actuels se développent, l’entreprise reste, elle, conservatrice. Elle continue de s’appuyer majoritairement sur les bases de données relationnelles et donc sur les ORM pour assurer la jonction avec le code applicatif.

Ces solutions ORM, tel que le standard JPA ne semblent pas poser de problème dans la plupart des cas, pourtant on fait rapidement face à “l’abstraction leak”, à savoir que les paradigmes fondamentaux des SGBDR et des applications sont différents et les ORM tentent de le masquer.

Les bases de données graphe offrent un mapping plus simple et plus naturel. Elles permettent en outre de satisfaire d’autres besoins :

• L’hétérogénéité des propriétés associées aux noeuds.
• L’absence de schéma prédéfini. Sur le papier, c’est un problème car il permet une discordance des donnés par rapport à l’intention de structuration. Mais avec Neo4J 2.0 le schéma existe de manière optionnelle.

Il y a-t-il un intérêt à proposer un mapping objet des bases orientées graphe ? Oui, si il offre une réelle simplification et des fonctionnalités intéressantes.

Hibernate OGM, une première approche

Hibernate OGM offre une approche inspirée de l’ORM qui ne convainc pas Florent. D’une part, à l’instant de JPA elle offre le plus petit dénominateur commun des bases orientées graphes, et l’idée de faire entrer toutes les bases de données NoSQL (pas seulement les bases orientées graphes) dans un même moule semble pour le moins un gros challenge…

Tinkerpop Frames

Cette solution se focalise également sur la construction d’une abstraction des bases orientées graphes (et seulement celles-ci). Elle propose son propre langage de requête, Gremlin. Las aujourd’hui le langage de requête de Neo4J, Cypher est l’un des atouts important du produit et de gros efforts sont consentis pour en améliorer les fonctionnalités. On se retrouve donc dans une course à la fonctionnalité… que Gremlin peut difficilement gagner.

Spring Data

Suivant l’idée d’origine de Spring, il s’agit d’une brique très légère. En fait, à l’origine même de ce sous-projet, il y a la rencontre entre Emil Eifrem et Rod Johnson, à savoir respectivement les créateurs de Neo4J et de Spring !

Un atout important de Spring Data est aussi son concept de “multi-store”. Nous avons évoqué la frilosité des entreprises par rapport aux nouveau paradigmes de bases de données. Spring Data adresse cela en permettant des ponts entre différents paradigmes (par exemple relationnel vers graphe) permettant des transitions douces vers ces nouveaux mondes !
D’un point de vue pratique, pour un repository standard, tout ce que l’on a à faire, c’est d’hériter de l’interface GraphRepository<> … et Spring Data s’occupe du reste ! Derrière le rideau, cette interface hérite de quelques autres (je ne vais pas les lister, elles sont sur le slide 31). Derrière le second rideau, au niveau de l’implémentation générée, cela va bien entendu être la “foire aux proxys” ! Bon, comme on dit : on ne peut pas tout avoir !
Spring Data offre d’importantes facilités pour écrire, ou plutôt ne pas écrire, des méthodes de recherches :

• Des “find”, où la simple convention de hommage va permettre de connaitre les critères de recherche en les mappant sur les paramètres.
• Des recherches plus complexes s’appuyant sur des clauses Cypher figurant en annotation @Query de la méthode.

En annotant des classes @NodeEntity, on peut spécifier ce qui est persisté et ce qui ne l’est pas, ce qui constitue des arcs, et bien d’autres choses encore !
Les templates Neo4J, à la façon de ce qui existe pour d’autres modules Spring, permettent d’opérer des requêtes de projection en éliminant la plomberie inhérente à l’utilisation brute de la base.

Spring Data offre de nombreuses fonctionnalités supplémentaires, comprenant bien entendu les famaux “cross store storage” que nous avons évoqué au début.

Pour conclure
Une soirée instructive sur les possibilités de Spring Data, bien que j’ai regretté que cela aille un peu vite sur les NodeEntity et que l’on ne s’arrête guère sur les stores multiples, car cela me parait un point clé pour Neo4J en entreprise, bien plus que l’économie de code que permet le framework !
Par ailleurs Florent a initié une série d’articles très bien écrits pour s’initier à Neo4J : le premier de la série est ici.