Note de lecture : Neo4J : Des données et des graphes, 2. Déploiement, par Sylvain Roussy, Nicolas Rouyer & Nicolas Mervaillie

Note : 7 ; Au théâtre ce soir, avec Sylvain, Patricia, Philippe, Christophe et Brian !

Ce second volume ne s’inscrit pas directement dans la continuité du premier. Le prérequis en est un peu d’expérience solide de Neo4J, lorsque le précédent s’adressait aux grands débutants. En fait, le titre induit un peu en erreur : il ne s’agit pas seulement d’adresser le volet exploitation (qui comptera au nombre des sujets), mais en fait d’aborder son utilisation dans un véritable cas d’étude !

On compte 220 pages pour ce volume de format plutôt réduit, donc plutôt environ 170 pages dans un format plus classique. A cela il faudra rajouter les annexes dont nous reparlerons. Pour cette partie principale on comptera seulement 5 chapitres. Je préfère généralement des chapitres assez courts, ce n’est pas le cas ici, mais le style adopté efface ce que je considère habituellement comme un inconvénient. Parlons-en justement. Le story telling est une technique puissante, qui a la vertu de nous immerger dans le texte, mais peu d’auteurs l’emploient. Ceux de ce volume vont plus loin : l’ensemble du livre (hors annexes) est une pièce de théâtre où l’on découvre la mise en œuvre de Neo4J avec ses fonctionnalités dans les échanges entre les impétrants. On soupçonnera que Sylvain, le sénior de l’équipe ressemble beaucoup à l’auteur principal dont il partage le prénom. Sans doute Christophe et Philippe incarnent-ils donc les deux autres co-auteurs ? Patricia la chef de projet et Ilko le commercial ont des rôles plus marginaux qui servent à l’introduction et au débriefe de chaque chapitre (deux excellentes idées, au passage). N’oublions pas non plus Brian, le stagiaire, qui lui semble complètement idiot.

Lire la suite

Note de lecture : Neo4J : Des données et des graphes, 1. Prise en main, par Sylvain Roussy

Note : 5 ; Un tutorial (vraiment) amélioré.

On a besoin de tutoriaux. Mais en tant que livres, ils n’atteignent pas chez moi des notes très élevées. Mais il arrive qu’on en rencontre de très correctes. Ce volume est de ceux-ci. L’objet lui-même accuse un format plus petit que les éditions habituelles du même genre, tout en étant nettement plus grand que le format poche. Pratique pour lire dans les transports. Toutefois, si la finition extérieure est correcte, la qualité est un peu faible. C’est probablement le prix à payer d’un tout petit éditeur. C’est malheureusement aussi vrai de la mise en page et de l’impression qui sont assez moyennes. Mention spéciale aux polices grisées vraiment peu lisibles. Pour les diagrammes c’est pire : ils se décodent avec peine et le texte à l’intérieur est illisible.
Heureusement pour nous, le fond prédomine sur la forme et là c’est nettement mieux.

Comme je l’ai dit, l’ouvrage est de petit format. Il compte 220 pages, mais seulement 190 pour le texte principal, le reste constituant des annexes. De ces dernières, seul l’aide-mémoire Cypher m’a semblé de quelque utilité. Le texte s’adresse aux grands débutants, aussi si l’on a quelques connaissances de Neo4J, le livre s’avale assez vite. Tant mieux car question découpage, ce n’est pas ça : on compte seulement 4 chapitres pour tout le livre !

Le premier chapitre ne compte que 15 pages et nous permet de découvrir Neo4J. Il couvre bien les éléments de base : ce qu’est une base NoSQL en général et une base graphe en particulier, les différentes versions de Neo4J et les bases de son installation. Là où ça se gâte, c’est lorsque l’auteur nous propose des requêtes de base sur l’outil, mais sans expliquer celles-ci. Il s’agit d’un choix délibéré, mais qui me laisse dans l’expectative.

Lire la suite

Note de lecture : Neo4J in Action, par Aleksa Vukotic & Nicki Watt

Note : 4 ; Un niveau « pratique » qui n’est pas à la hauteur de la série « in action » de Manning…

J’aime beaucoup Neo4J. C’est la base NoSQL la plus ludique que je connaisse. Il lui fallait réellement un livre dédié à sa mise en œuvre, qui donne les clés pour l’intégrer dans des solutions applicatives en répondant aux nombreuses petites questions que l’on se pose chemin faisant. C’est très naturellement que j’ai pensé que ce volume serait celui-ci. Ce fut une déception, hélas.

Neo4J in Action, ce sont 250 pages sur 11 chapitres regroupés en 3 parties. La première d’entre-elles est qualifiée d’introduction et compte 80 pages, comprenant 5 des chapitres. Au premier d’entre-eux, a case for Neo4J database, les auteurs nous y expliquent l’utilité d’une base orientée graphe. On ne parle même pas de Neo4J. L’idée est bonne, mais l’execution plutôt imparfaite, le texte se noie parfois dans des détails et pimente les explications de caractéristiques de Neo4J. Il aurait été préférable de se focaliser uniquement sur le paradigme sous-jacent de Neo4J.

Au second chapitre, on attaque sur une douzaine de de pages la question de la modélisation des données : là aussi un peu de mélange des genres, avec du Cypher (heureusement, je le connaissais un peu avant) mélangé à cela. J’aurais volontiers regroupé les chapitres 1 et 2 en les débarrassant des hors sujets et des détails techniques !

Lire la suite

Neo4J contre SAP Hana

Il y avait un petit moment que l’on n’avait pas eu de meetup Neo4J sur Paris ! C’est donc avec une façon un peu provocante d’aborder un sujet à connotation BI que nous avons été invités !

Nous étions environ 30 à nous rendre ainsi dans le showroom Zenika.

image

Introduction

Cédric Fauvet, toujours égal à lui-même nous fait son habituelle introduction sur les graphes. Presque habituelle, devrais-je dire, car il fait un peu évoluer son propos de meetup en meetup, tout comme son support.

image

Aujourd’hui, le spectre des problèmes couverts par les bases orientées graphes couvre :

  • La collaboration
  • Le SCM
  • L’analyse géo-spatiale
  • L’étude des interactions moléculaires
  • L’analyse d’impact
  • Le MDM
  • La gestion de lignes-produit
  • Et bien entendu la recommandation et les liens sociaux !

En Juin, Neo4J France devrait nous gratifier d’une présentation d’un projet « Dropbox-like » réalisé par des étudiants !

Cédric attire également notre attention sur le talk de Volker Pacher expliquant pourquoi Neo4J augmentait la capacité de delivery de Shutl (acquis depuis par eBay).

Il est l’heure de la pause pizza, nous allons bientôt attaquer la pièce maîtresse de la soirée !

image

Analyse des tickets de caisse avec Neo4J

Nicolas Mervaillies et Charles Besselièvre nous présentent le projet qu’ils ont développé pour « un grand client retail ». Il s’agit d’un petit projet, c’est à dire moins de 100 j/h, qui devait être développé rapidement. Sur les projets analytiques orientés « real time », cette enseigne s’appuie généralement sur SAP Hana. Mais ce projet tactique présente des échéances de temps incompatibles avec ce type de projet, plus adapté à des solutions légères menées en agile.

image

La problématique est essentiellement simple : trouver des corrélations d’achats. Vous savez, celles qui ont permit de déterminer que les couches culottes sont souvent achetées en même temps que le bière le samedi ou qui ont permit à une enseigne d’apprendre via des bons d’achat à une jeune fille qu’elle était enceinte avant qu’elle même ne le sache ! Ici les corrélations doivent être croisées entre magasins et entre régions. Pour chaque magasin, il faut compter une volumétrie de 300 millions de lignes de ticket par an.

Phase 0 : Prototypage

Pour cela on utilise simplement la console Neo4J ! En fait, on ne représente pas chaque ligne d’achat en liaison avec le ticket de caisse : on agrège ces lignes par sous-familles. Bien sûr, les tickets sont associés à une date, un client et un magasin.

Grâce à cela, on voit avec Cypher si l’on parvient à produire les analyses que l’on souhaite.

Phase 1 : Construction initiale

Premier fonctionnement en production : les données de ticket de caisse sont récupérés tous les mois et injectés avec Spring Batch. Le client peut agréger les données en live via des requêtes Cypher : dans le temps, par famille de produits, par magasin.

Les couplages repérés avec de forts pourcentages sont donc mis en exergue dans certains magasins, on compare les éléments différenciants des magasins ayant de moins bons taux de corrélation !

On a toutefois un problème : trop de lenteurs, dû aux fortes volumétries, mais aussi au déploiement de Neo4J sur des serveurs virtualisés. La virtualisation et les bases de données, ce n’est pas le grand amour, même si certains ingénieurs système essaient de se convaincre du contraire !

Phase 2 : Focus sur le « top 15 »

En analysant les données des différents magasins, on perçoit dans le temps des réccurrences d’association, notamment dans le « top 15 ». Nos artistes choisissent donc de précalculer les associations significatives, celles correspondant au « top 50 » de chaque magasin, mais sans Marc Toesca !

Phase 3 : Optimisation de production

En dernière phase, il faut finalement réaliser des optimisations purement de production : gestion de l’infrastructure, mise en place de cache, etc…

En conclusion…

L’utilisation de Neo4J est parfaitement adaptée à ce type de projet tactique : on a la rapidité de de mise en place et la vitesse d’exécution de ce projet typique d’un projet agile ! Par rapport à SAP Hana, on gagne réellement en time to market !

L’équipe a aussi développé un front-end pour faciliter l’utilisation du système. Mais à la limite, cela aurait pu être omis !

Concernant l’infra : elle a été gérée complètement en interne pour des raisons de non exposition de données sensibles. Toutefois, on a une machine puissante qui ne sert que quelques heures, une fois par mois ! Ce type de configuration se marrie donc bien avec le Cloud.

Enfin, l’aspect communautaire de Neo4J permettant de trouver de l’aide sur les forum a été un plus important !

Faute de disposer du support de présentation, je vous propose ici l’enregistrement de la même session qui s’est déroulée au meetup Neo4J Lillois !

Ce que j’en ai pensé

C’est probablement le meetup Neo4J le plus interactif et le plus convivial auquel j’ai pu assister. Les interventions fort pertinentes d’un connaisseur SAP Hana ont été un gros plus dans la discussion, surtout quand, comme lui, on connait et sait reconnaitre les qualités de ce système. Il est là, juste derrière moi.

Pour clore ce compte-rendu et donner un avis éclairé sur cette confrontation, je le citerai :

« Remplaçons notre argent par notre intelligence ».

Cela me rappelle un peu un slogan des années 70 où il était question de pétrole…

… Et Neo4J devint CMS !

Lors de ce Meetup Neo4J de Janvier, toujours dans le zLocalHost de Zenika, nous avons pu découvrir Structr, et comment il adresse la problématique du CMS. Ou du moins, nous allons le faire.

Cédric Fauvet au pas de charge !

Cédric commence par sa très classique introduction à Neo4J. Introduction un peu écourtée d’ailleurs : c’était la soirée des problèmes techniques et il a fallu rattraper le temps perdu.

Le temps tout de même de donner quelques nouvelles de la communauté et de l’actualité. On s’attardera quelques instants sur la dernière référence Française : Meetic ! Bien entendu, comme pour Viadeo, le but est la recherche d’adéquation de profiles. Ce n’est d’ailleurs pas une première expérience pour Neo4J qui a équipé d’autres sites de rencontre avant de s’occuper du n°1 européen.

Autre nouvelle intéressante : la mise à disposition de cours en ligne ! J’ai hâte d’aller voir ça…

Structr

Axel Morgner est fondateur de Structr, il est venu spécialement de Frankfort pour évoquer son usage de Neo4J. Après avoir longtemps travaillé dans le domaine du CMS, il a décidé de changer d’horizon, de faire autre chose. Il a découvert Neo4J, et a décidé de construire avec … un CMS !

image

Structr c’est une société mais aussi un logiciel open-source. La motivation ? Construire des sites web dynamiques avec du contenu. La première release de la bête est apparue en 2011.

La première itération : c’est une classique webapp standalone, dont la partie front utilise freemarker.

Les choses changent radicalement en seconde itération ! C’est d’abord un changement de scope : Structr devient un pur back-end, le front-end est abandonné ! Le produit assure un mapping bidirectionnel entre JSON et le graphe. Et le produit intègre une notion de schéma et de contraintes (avec même une gestion des suppressions en cascade), des choses qui vont bien plus loin que les évolutions apportées par Neo4J 2.0 !

L’interface utilisateur revient en 3ème itération, mais elle s’est faite HTML5 ! Elle permet l’édition sur place, la visualisation des liens entre pages, etc…

Démo time !

Axel nous fait bien sûr une petite visite guidée de la bête. On commence fièrement par un import de page que l’outil digère pour le transformer en graphe. On peut utiliser alors l’édition sur place pour importer ou saisir du contenue … ou faire référence à du contenu dans le graphe, via des requêtes Cypher, par exemple !

image

La sécurité n’est pas en reste et elle se configure sur les noeuds. Elle est bien sûr transitive, suivant les liens “contains”. L’IHM est aussi synchronisée entre les clients, permettant l’édition de contenu collaboratif.
Mais tout cela, c’est du statique. Du “boring stuff” comme le dit Axel. Structr gère la dynamicité du contenu, en partie du fait qu’il ne gère pas de cache et se repose sur la performance de neo4J. L’une des clés est la référence qui peut être faite depuis les pages vers du contenu structuré lui-même dans le graphe.

Pour cela il faut créer un projet “data type”. C’est lui qui permet la structuration des données et les contraintes dont nous avons parlé plus haut. On y crée aussi des bindings qui peuvent être référencés par des noms symboliques.

L’une des question que je me posais pendant que la démo se déroulait concernait les contenu volumineux, de type “blob”. On sait que Neo4J n’est pas fait pour cela. Qu’a cela ne tienne, les data types peuvent référencer des fichiers ou même des répertoires ! Au-delà de cela, il y a aussi des concepts de “web components” et de “shared components area”, mais ne m’en demandez pas plus, car j’ai un peu perdu le fil à ce moment là !

Malgré quelques petits accrocs lors de la démo, il faut avouer que cette gestion de contenu est pour le moins étonnante et résolument différente de ce qui se fait !

Teasing

Cédric souhaitait innover en donnant une minute de parole au débotté à des participants du Meetup ayant un projet avec Neo4J.

Un étudiant de Supinfo Lille (désolé, je n’ai pas noté son nom) nous a donc parlé de son projet d’étude : un “Dropbox like” intégrant une dimension sociale de partage. L’utilisation de Neo4J permet ici de représenter les structures de fichiers, répertoires, partages et droits, tandis que les contenus eux-même peuvent être répartis sur différents serveurs de stockages, ces contenus étant simplement référencés dans le graphe.

Quand Sébastien Just est venu nous parler de Seij, j’ai cru que Structr venait de trouver son frère jumeau ! J’ai pu discuter un peu avec Sébastien et suis maintenant convaincu que ce n’est pas le cas. Certes les deux applications partagent nombre de concepts : le CMS basé sur des graphes Neo4J et la possibilité de constituer son contenu en assemblant les éléments issus des noeuds. Mais là où Structr s’appuie sur une structuration et un typage fort, Seij s’enorgueillis de son approche “free form”, un peu comme si l’on avait un Excel pour la gestion de contenu. Des concepts très proches mais un ciblage client très différents en font deux produits qui ne se comparent finalement pas. J’espère que Sébastien aura l’occasion de revenir nous le présenter et nous en parler !

Meetup Neo4J de décembre 2013 : Des recommandations en temps réel avec Recolytic

Ce sont deux sujets qui seront abordés lors de ce meetup. En effet, en introduction à la présentation de Rochdi Chakroun, Cédric Fauvet a évoqué le concours GraphGist, concours où il y a peu à gagner. Mais ce n’est pas l’objectif. Ici, il s’agit plutôt de monter de petits cas d’utilisation originaux. Neo4J souhaite visiblement pouvoir montrer beaucoup de cas d’utilisation créatifs et variés de sa base de données.

Cédric Fauvet débute généralement ces rencontres par une présentation de la société, des cas d’usage de Neo4… Celle-ci ne fit pas exception.

image

Bien sûr il nous présente les mêmes concepts, les même cas d’utilisation ou presque, mais le propos évolue quand même un peu à chaque fois. Et de plus, il y avait aujourd’hui Neo4J 2.0 à évoquer ! Il n’y a rien non plus de rébarbatif dans sa façon de présenter les choses. Après tout, avant d’être responsable de Neo4J France, Cédric était un développeur comme nous !

Mais avant de passer à la suite : Pizza time !

image

Recolytic

Rochdi Chakroun est architecte logiciel chez Vente Privée. Mais ce n’est pas à ce titre qu’il venait aujourd’hui, mais plutôt pour présenter le fruit d’un projet personnel : Recolytic.

image

Le constat de Rochdi est que les systèmes de recommandation sont aujourd’hui obscures : "nous allons faire progresser votre chiffre d’affaire, vous n’avez pas à savoir comment". Une position qu’il juge insupportable au regard de l’aspect stratégique de ce traitement.

Autre aspect que l’orateur a voulu adresser : la recommandation en temps réel. Les moteurs de recommandation s’appuient sur la plupart sur des algorithmes et des traitements de machine learning qui demandent de longs temps de traitement en différé pour fournir de nouveaux modèles mis à jour.

Recolytic se veut performant, facile à intégrer et transparent sur la stratégie. Il s’appuie bien sûr sur Neo4J, ici le modèle c’est le graphe. Et ce graphe est composé de triplets utilisateur – action -ressource. Il est à noter que Rocolytic est complètement agnostique sur la nature des ressources. Des poids peuvent être accorder aux actions ou aux ressources, par exemple pour donner plus d’importance à un achat par rapport à une consultation.

Pour ce qui est des APIs, Rocolytic en propose 3 catégories :

  1. Les API de collecte : pour récupérer les actions des utilisateurs.
  2. Les APi de recommandation. Elles permettent plusieurs stratégies.
  3. Les API de mesure. Afin de mesurer après coup la pertinence de recommandations et ajuster le paramétrage en conséquence.

A l’initialisation de Recolytic, on débute sans informations de l’utilisateur. Il est donc pertinent de commencer avec la stratégie par défaut : les plus populaires.

Il sera ensuite possible de basculer vers une autre stratégie, par exemple la similarité de panier.

Pour démontrer le produit, Rochdi nous propose de nous promener dans un site d’e-commerce de démonstration.
Rochdi ne s’est pas encore fixé d’objectif pour les prochaines étapes : en faire un open-source, ou une startup… Il avoue surtout avoir besoin de récupérer de ses efforts. On le comprend : il a quand même réalisé tout cela en gardant son activité chez Vente Privée !

En Janvier, nous rencontrerons un autre cas d’utilisation avec Structr.

Neo4J et Spring Data, avec Florent Biville

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é !

Meetup Neo4J Octobre 2013

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.

Les 7 ponts de Königsberg

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.

Meetup Neo4J Octobre 2013

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.

Purely awesome – Chess Games and Neo4j

nosql:

I wasn’t able to follow the post. I got myself lost into the superb presentation built for it. Chess game replays. Dynamic graphs. Pure awesomeness.

This is by far the most entertaining blog entry presentation I’ve seen since I’ve start reading and writing about NoSQL.

standingovation

Original title and link: Purely awesome – Chess Games and Neo4j (NoSQL database©myNoSQL)

Cedric Fauvet évoquait justement ce cas d’usage de Neo4J lors du meetup de mardi. Voici a chose mise en musique, hélas seuls les vrais amateurs d’échec sauront vraiment apprécier la chose, ce qui n’est pas non plus mon cas. Comme l’auteur du post, je me suis simplement laissé hypnotiser par ce très beau replay…

Purely awesome – Chess Games and Neo4j

Note de lecture : NoSQL Distilled, par Pramod J. Sadalage & Martin Fowler

Note : 4 ; Plus qu’une distillation, une introduction légèrement frustrante.

Dans la même veine que le « UML distilled », Martin Fowler accompagné d’un de ses collègues de Thoughtwork nous produit un ouvrage très court (moins de 160 pages !) destiné à nous faire découvrir et à nous donner les clés du monde NoSQL ou plutôt de cet écosystème. Pour donner un bon rythme au texte, cet opuscule est découpé en 15 chapitres, ce qui fait une moyenne de 10 pages par chapitre.

On commence par un petit historique sur l’avènement du mouvement NoSQL. Pas indispensable, mais sympathique et bien écrit. Les chapitres 2 et 3 abordent la problématique du modèle de données, de l’intérêt de considérer des agrégats de données, mais aussi la souplesse qu’apporte des bases de données sans schéma … avec le corollaire d’avoir une base de données propriétaire de l’application sachant l’interpréter.

Trois chapitres sont consacrés aux principes sous-jacents de ces bases de données. Le chapitre 4 passe rapidement sur le modèle de distribution. Le chapitre 5 passe moins rapidement sur la gestion de la consistance (vous savez, le fameux « eventually consistent »). En fait, il est même passablement ennuyeux. Enfin le chapitre 6 évoque en quelques pages la question de l’estampillage des versions dans un environnement clusterisé actif / actif.

Difficile, impossible même, d’évoquer les bases NoSQL sans parler du « map reduce ». C’est ce que fait le chapitre 7, bien mais pas aussi brillamment que je me serais attendu de la part de Martin Fowler.

Le cœur du livre est sans contestations possible occupé par les quatre chapitres suivants qui forment le début de la troisième partie. Chacun d’entre eux traite d’un type de base NoSQL.

Le chapitre 8 aborde les bases de données clé-valeur, en prenant comme exemple Riak. Les auteurs ont pensé que 6 pages suffisaient pour s’occuper de cela. Moi j’ai trouvé cela franchement léger.

Les bases de données « orienté document » ont à peine droit à un meilleur traitement au chapitre 9. C’est MongoDB qui fort logiquement a été choisi, le sujet étant traité en 9 pages. Malgré tout, cela me laisse un meilleur goût tout en étant un poil superficiel.

10 pages à peine pour évoquer les bases de données orientées colonnes, c’est un peu un challenge car le sujet n’est pas simple, ou plutôt le paradigme est tellement différent de ce que nous connaissons qu’il aurait mérité plus d’attention que ce que lui accorde ce chapitre 10. J’en sors un peu confus et convaincu que j’ai besoin d’un complément d’information sur la question.

Si différentes des autres types, les bases de données orientées graphe telles que Neo4J qui sert ici d’exemple m’apparaissent clairement abordées dans ce chapitre 11, même si c’est seulement sur 10 pages. En fait ce livre m’incite à me pencher plus avant sur cette base de données et ce que je fais en ce moment ! Ne serait-ce que pour cela : merci !

Le chapitre 12 sur la migration de schéma de données est une blague. Il n’était pas franchement utile, loin de là. On reconnaît l’insertion au chausse-pied du sujet favori de Pramod Sadalage. De ce sujet et de quelques autres, je me serais bien passé au profit d’un développement plus conséquent des 4 chapitres les plus importants du livre !

La persistance polyglotte est un sujet déjà abordé en début de livre. Sans être ennuyeux, les 7 pages de ce chapitre 13 semblent passer une seconde couche.

J’aime bien l’idée d’un chapitre « beyond NoSQL » mais les auteurs n’ont pas tant à dire dans ce chapitre 14. Dommage. Finir par un chapitre sur le choix du type de base NoSQL est une bonne idée. Mai ce n’est visiblement pas si facile à faire, car cela sonne un peu creux.

Qui aime bien châtie bien. Et Martin Fowler d’habitude très brillant dans l’exercice ne convainc pas dans celui-ci. Il prends un « 4 » là où j’aurais certainement noté 5 pour quelqu’un d’autre. Le livre reste fidèle à l’idée de brièveté, mais le contenu est fort mal réparti : trop de place est accordée à des sujets peu importants ou qui pourraient être mieux synthétisés, alors que la partie importante de l’ouvrage aurait dû bénéficier d’un meilleur traitement sur deux ou trois fois plus d’espace !

C’est un livre qui pourra être utile au manager, car il traite, ou plutôt balaye le sujet dans un volume qui peut être absorbé en un week-end et permet de savoir de quoi on parle. Pour ma part, je me sens quelque peu frustré, et je pense que je vais me tourner vers le « seven databases in seven weeks » paru chez Pargamatic Bookshelf !

nosql-distilled

Référence complète : NoSQL Distilled, a brief guide to the emerging world of polyglot persistence – Pramod J. Sadalage & Martin Fowler – Addison Wesley 2012 – ISBN : 978 0 321 82662 6

NoSQL Distilled: A Brief Guide to the Emerging World of Polyglot Persistence

http://www.goodreads.com/book/add_to_books_widget_frame/0321826620?atmb_widget%5Bbutton%5D=atmb_widget_1.png&atmb_widget%5Bhide_friends%5D=on