Neo4j 5 : Neo4j veut simplifier les déploiements à large échelle
La semaine dernière, l’éditeur éponyme a annoncé la disponibilité générale de Neo4j 5. Outre des améliorations de performance, la nouvelle version majeure doit simplifier l’administration des clusters à large échelle.
Sur le fond, la base de données orientée graphes ne change pas véritablement, elle est désormais plus simple à déployer à large échelle, selon l’éditeur.
« Nous avons quelques nouveautés, mais les choses les plus compliquées et sophistiquées, celles qui nous ont demandé l’intervention de 200 ingénieurs, sont sous le capot », assure Jim Webber (en photo ci-dessus), Chief Scientist de Neo4j, auprès du MagIT.
De manière générale, l’administration de Neo4j est souvent pointée du doigt comme son plus gros défaut.
Pour répondre à ce problème, Neo4j a apporté deux nouvelles capacités de clustering pour les éditions Enterprise.
Rationaliser les déploiements de Neo4j
L’autonomous clustering doit permettre d’exécuter des clusters contenant davantage de bases de données « sans surcharge administrative ».
« Nous avons revu l’architecture de mise en clusters afin de pouvoir séparer les serveurs physiques du SGBD et du moteur de clustering », affirme Jim Webber.
En l’occurrence, les clients grands comptes doivent habituellement gérer des clusters indépendants les uns des autres pour différents cas d’usage critiques (détection de la fraude, customer 360, gestion RH, etc.).
Selon Jim Webber, à partir du même nombre de serveurs, il est possible de réduire le nombre de clusters pour n’en avoir qu’un seul à partir duquel les clients administrent des dizaines, voire des centaines de bases de données.
En ce sens, la gestion des réplications a été assouplie. « Les administrateurs peuvent spécifier le nombre de copies de bases de données à répliquer au sein d’un cluster pour les rendre disponibles sur un sous-ensemble de serveurs », indique la documentation.
Pourquoi autonome ? Parce que c’est le cluster qui décide automatiquement de l’allocation des bases de données aux serveurs. De plus, cette répartition est dynamique : elle peut changer si des serveurs sont ajoutés ou supprimés.
« Il s’agit d’aider les administrateurs à proposer Neo4j comme un service IT au sein de leur entreprise », résume Jim Webber.
« Il s’agit d’aider les administrateurs à proposer Neo4j comme un service IT au sein de leur entreprise ».
Jim WebberChief Scientist, Neo4j
Dans la même veine, Neo4j avait introduit une capacité de sharding avec la version 4.0, nommée Fabric. Dans la version 5.1, la commande COMPOSITE DATABASE doit non seulement permettre de gérer le sharding sur plusieurs clusters à la fois, mais aussi de créer, mettre à jour et supprimer des configurations Fabric sans avoir à redémarrer la base de données.
Ops Manager : les DBA à l’honneur
Dans la version Enterprise, les DBA ont également accès à un nouvel outil : Neo4j Ops Manager (NOM).
Présenté en juin, Ops Manager est à la fois une API et une interface utilisateur pour effectuer les principales tâches de gestion et de supervision des déploiements Neo4j.
Pour accompagner la mise en avant d’Ops Manager, Neo4j a rassemblé l’ensemble des fonctionnalités d’administration dans un seul « outil », un fichier de configuration éditable à l’aide du CLI fournit avec le SGBD.
Ops Manager est notamment pensé pour gérer la configuration des espaces de nom et les mises à jour.
« Ops Manager est dérivé de notre expérience d’exécution de Neo4j dans le cloud », affirme Jim Webber. « Les utilisateurs peuvent presque obtenir la même vue opérationnelle de leurs instances que nos équipes qui gèrent le back-end de nos offres cloud ».
Neo4j revendique plus de 1300 clients. Beaucoup d’entre eux exécutent la distribution Enterprise sur site ou depuis leur propre compte dans le cloud. Et si l’éditeur estime qu’à l’avenir les nouveaux clients se tourneront majoritairement vers son offre DBaaS, ses clients les plus importants lui réclament ce type d’outils et les fonctionnalités de mise en clusters autonome.
« Si vous avez une application qui fonctionne très bien sur site et qui fait partie de votre stratégie pour les trois, cinq ou dix prochaines années, nous voulons vous soutenir dans cette démarche », explique le Chief Scientist en direction des clients. « Nous pouvons apporter une partie de la technologie que nous développons dans le cloud dans votre centre de données pour vous aider à la gérer plus aisément ».
Un autre facteur pourrait accélérer l’adoption d’Ops Manager. L’éditeur a décidé de changer la cadence de ces mises à jour. Au lieu de proposer des nouvelles fonctionnalités tous les six mois, il réalisera des ajouts incrémentaux mensuellement.
Neo4j a anticipé les craintes de ses utilisateurs en assurant proposer un processus de mise à jour simplifié, aux mains des DBA. À partir de la version 5.0, il sera possible « de migrer de n’importe quelle version 5.x vers n’importe quelle version ultérieure 5.y, par exemple de 5.2 à 5.6 », présente la documentation.
Améliorer les performances pour faire face à la compétition
Tenter d’améliorer l’administration du SGBD ne suffit pas. D’autres ajustements ont été effectués pour améliorer les performances.
Neo4j a présenté un nouvel opérateur d’exécution Cypher permettant d’exécuter les requêtes multisaut 1000 fois plus rapidement que Neo4j 4. Celui-ci s’appuie entre autres sur « la parallélisation des requêtes qui peuvent utiliser plusieurs pools dans le système ».
En outre, le planificateur de requêtes a été optimisé pour exécuter les requêtes plus rapidement, même si celles-ci ont été développées à l’origine pour les versions 3 ou 4 du SGBD. « Ces requêtes sont généralement plus rapides d’un ordre de grandeur, mais dans certains cas, nous observons qu’elles s’exécutent trois fois plus vite », indique Jim Webber.
Enfin, le Chief Scientist indique que Neo4j a amélioré l’implémentation des index et les abstractions de la couche de stockage sur disque. Tout cela permettrait d’accéder aux données « beaucoup plus rapidement ».
C’est ce qui distinguerait Neo4j des bases de données multimodèle capable de prendre en charge des modèles graphes, selon Jim Webber.
« Si vous avez un modèle graphe et que vous le sauvegardez dans une base de données relationnelle, vous êtes limité parce que la base de données relationnelle n’est pas conçue pour faire des opérations Path (problème du plus court chemin, en français) », affirme Jim Webb. « Et pour ce faire, elle doit en quelque sorte le simuler en faisant des jointures récursives », poursuit-il. « Ce qui se passe alors, c’est que les ensembles deviennent plus grands parce que vous faites des ensembles de produits cartésiens. Finalement, si vous faites exploser votre mémoire principale, vous débordez sur la mémoire virtuelle et maintenant, vous travaillez à la vitesse du disque ».
Il s’agit également de rester pertinent face à TigerGraph, Amazon Neptune, Nebula ou MemGraph. Selon Doug Henschen, analyste chez Constellation Research, interrogé par SearchDataManagement [propriété de TechTarget, également propriétaire du MagIT], Neo4j est plus particulièrement une réponse à TigerGraph et à son architecture distribuée.
