Retour sur le meetup Graph Database Paris : Les nouveautés de Neo4j 3.0

Ce 10 mai, se tenait dans nos locaux le meetup Graph Database Paris avec Benoît Simard (@logisima) qui est venu nous parler des nouveautés de Neo4j 3.0. En guise d’introdution, Benoît nous présentait l’évolution de Neo4j à travers les âges. Retour sur cette intervention

La base de donnée Neo4 a 16 ans
L’air de rien, Neo4j n’est pas tout jeune, puisque la base donnée souffle cette année sa 16ème bougie : et que de chemins parcourus, depuis ses débuts !
A l’origine, la base de données se présentait sous la forme d’un *jar* à intégrer dans ses applications Java pour des traitements en mémoire. Neo4j s’est vu enrichi de nombreuses fonctionnalités, les numéros de versions s’incrémentant. C’est ainsi qu’on a vu apparaître une API REST, le (super) langage de requête Cypher, une console développeur, la notions de “label”, l’introduction d’un cache off-heap, et plein d’autres choses …
Mais ce n’est pas exactement vers le passé que l’on regardait ce soir, mais plutôt vers le futur. En vérité, il faudrait dire le présent puisque Neo4j 3.0 a été annoncé et est sorti ce 26 avril 2016 lors de la conférence Graph Connect à Londres.
Avant d’entrer dans le vif du sujet, on nous annonce la couleur :

• une base supportant un volume de données plus important ;
• des traitements plus rapides ;
• une expérience développeur améliorée ;
• des améliorations pour les environnements cloud et virtualisés.

Sacré programme, qui nous est déroulé en 3 axes, ou 3 points de vue : l’architecte, l’administrateur et le développeur.

L’architecte

Nouveau moteur de stockage

Dans cette nouvelle mouture, Neo4j embarque un nouveau moteur de stockage qui repousse les limites de la version précédente. Là on nous étions “limité” à quelques milliards (34 milliards pour être précis) d’entités auparavant, il faut maintenant compter en quadrillon, vers l’infini, ou presque ! La limite en volume ne sera pas Neo4j, mais bien les machines elle-mêmes. Ce nouveau moteur de stockage est en revange exclusif à l’édition *Enterprise* de Neo4j.

Amélioration des indexes Lucene

Le deuxième point abordé par besoin est la migration des indexes Lucence 3 vers Lucene 5. Ce saut important de version apporte des améliorations radicales au niveau des performances ainsi que de nouvelles possibilités pour exploiter les indexes.
Le processus d’indexation s’effectue maintenant en parallèle, ce qui supprime le goulet d’étranglement lié à l’écriture des indexes.
Enfin les indexes sont partitionnés. Cela permet de s’affranchir de la limite de la taille des indexes Lucene (2 millards d’entrées par index).

L’administrateur

Environnements cloud et virtualisés

Du côté de l’administrateur système on va pouvoir profiter de l’amélioration des performances sur les environnements virtualisés via une optimisation du page cache pour prendre en compte les spécificités de ces environnements.

Une image Docker officielle

Le second point est l’existence d’une image Docker Neo4j officielle disponible sur le Hub Docker et supportée par Neo Technology.
Si vous avez Docker, vous pouvez essayez Neo4j 3.0 de la manière suivante :

docker run -p 7474:7474 -p 7687:7687 neo4j

L’utilisation de Docker offre également une nouvelle façon de procéder à des tests d’intégration sur la couche d’accès aux données.

Une arborescence revue

Enfin, l’arborescence de Neo4j sur le système de fichier a été modifiée pour apporter plus de clarté et une meilleures séparation entre types de fichiers. On ne retrouvera plus par exemple les logs dans le répertoire `/data` qui sert de support au contenu de la base de données.
Enfin, il n’y a plus qu’un seul fichier de configuration : `conf/neo4j.conf`. Attention les noms des propriétés ont changé ! Pas de panique, un outils de migration est proposé.
Il existe un autre fichier de configuration, qui sert lui à paramétrer la JVM dans laquelle est lancée Neo4j.

Le développeur

Bolt

Première grosse nouveauté : Bolt. Bolt est un nouveau protocole pour communiquer avec la base de données pour remplacer l’API REST. Ce nouveau protocol est un protocol binaire, sécurisé (TLS par défaut) et versionné.
Benoît a pu observer sur une application d’exemple des gains de performance significatifs, simplement en utilisant Bolt au lieu de l’API REST.

• Débit observé avec l’API REST : 9000 requêtes par seconde
• Débit observé avec Bolt : 12000 requêtes par seconde.

Neo Technology a mis les petits plats dans les grands en proposant des drivers Bolt officiels et supportés par l’entreprise (Javascript, Python, Java, .Net, PHP). A cela il faut ajouter les drivers portés par la communauté. La spécification du protocole étant ouverte, tout le monde peut en proposer son propre driver.

Procédures stockées

Une des grosses nouveauté est l’ajout des procédures stockées dans Neo4j. Ces dernières sont l’évolution des “unmanaged” extensions, au lieu d’être exposées via une API REST, elles peuvent être directement appelées au sein d’une requête Cypher.
Pour rappel, les extensions Neo4j sont des `.jar` que l’on peut développer, et brancher sur la base de données afin d’en étendre les fonctionnalités. Ces extensions sont développées en Java et ont accès à toute l’API Java de Neo4j, ce qui permet d’intervenir à de nombreux niveaux dans le fonctionnement de la base de données.
Il existe par défaut un ensemble de procédures intégrées à la base de données qui vont permettre de récupérer en Cypher des informations qui n’étaient disponibles auparavant qu’en utilisant l’API REST comme la récupération d’informations JMX.
Il existe déjà une collection de procédures développée par Michael Hunger et répondant au nom de “Awesome procedures for Neo4j 3.0 – codenamed “apoc”“. L’ensemble est disponible à l’adresse suivante : https://github.com/neo4j-contrib/neo4j-apoc-procedures. Parmi ces procédures, on trouve la génération d’un meta graphe ainsi que la connectivité JDBC (il devient possible de faire une requête SQL dans une requête Cypher ! )

Cypher

Cypher n’est pas oublié dans cette nouvelle mouture de Neo4j. Outre l’apparition des procédures stockées on pourra observer de manière générale des gains de performances dans plusieurs scénarios :
– Meilleure utilisation des indexes (sur les mots clés `ENDS WITH` et `CONTAINS`
par exemple) ;
– Améliorations des performances grâce aux statistiques collectées par la base de données ;
– “Cost based planner” à présent actif pour les écritures ;
– Optimisation de `shortestPath` lorsqu’il est utilisé avec une clause `WHERE`.

Console développeur

Enfin, du côté du navigateur Neo4j, il est maintenant possible de sauvegarder ses préférences du navigateur Neo4j sur le cloud et de pouvoir le réutiliser sur une autre instance Neo4j, afin de ne pas perdre ses préférences.

Conclusion

A l’issue de sa présentation Benoît nous expliquait comment upgrader sa base de de données Neo4j vers la version 3.0. Pour cela, il faudra avoir Java 8 d’installé, avoir activé la migration des données dans la configuration de la base, et enfin migrer les fichiers de configurations dans la nouvelle arborescence. Pour ce dernier point, Neo Technology propose un outil de migration.
Après la mise à jour, Neo4j devra reconstruire les indexes suite à la migration vers Lucene 5.
Pour conclure cette présentation, on nous présentait quelques améliorations potentielles, qui devraient sortir avec la prochain version qui sera la 3.1, prévue pour la fin d’année 2016. Attention, il n’y a rien d’officiel et ces informations sont à prendre avec des pincettes :

• multitenant (plusieurs bases chargées dans une instance Neo4j) ;
• évolution de la sécurité -> LDAP, rôles, etc ;
• refactoring du système de haute disponibilité pour mieux scaler en écriture.

Ce meetup était très riche en informations. La base de donnée Neo4j est une base qui a déjà pas mal de chemin derrière elle, mais qui continue de s’améliorer. Ce n’est pas prêt de s’arrêter ! Les slides de cette présentation sont disponibles sur le site de Benoît.
Prochain rendez-vous, prochain meetup : le 1er juin, toujours chez Zenika. 😉