Le livre sur les bases de données graphes, écrit par Ian Robinson, Jim Webber et Emil Eifrém, couvre les bases de données NoSQL basées sur les graphes et les différentes possibilités disponibles pour stocker des “données connectées” dans le monde réel. Les auteurs traitent des sujets comme la modélisation des données d’un domaine avec les graphes et l’analyse prédictive en utilisant des techniques issues de la théorie des graphes.
InfoQ a rencontré les coauteurs Ian Robinson et Jim Webber pour parler du livre, du rôle des bases de données graphes dans l’écosystème des bases NoSQL et des nouveautés qui vont arriver dans les bases de données graphes.
InfoQ : Félicitations pour votre nouveau livre. Quel est le statut actuel du livre ?
Ian et Jim : Merci Srini ! Le livre a été écrit au cours de l’année dernière avec une version gratuite du manuscrit rendue disponible après environ 8 mois dans le processus. Nous en sommes maintenant à la dernière phase de l’édition avec O’Reilly et la version finale du livre sortira le 10 juin. Nous donnerons des copies du livre à tous les participants aux conférences GraphConnect de cette année ainsi qu’à ceux de nos nombreux évènements communautaires Neo4J.
InfoQ : Comment comparer une base de données graphe avec une base de données rélationnelle ou avec les autres bases de données NoSQL ?
Ian et Jim : Alistair Jones a inventé le terme “carrefours relationnels” pour décrire les différences. Selon Alistair nous sommes à la croisée des chemins. L’un des chemins mène à l’approche, adoptée par la plupart des bases de données NoSQL, dans laquelle les données sont fortement dénormalisées et nous comptons sur l’application pour les rassembler avec typiquement une latence élevée et mieux les comprendre. L’autre chemin mène à l’approche adoptée par les bases de données graphes dans laquelle nous utilisons la puissance expressive du graphe pour construire un modèle flexible et connecté du problème concerné que nous requêtons ensuite avec une faible latence pour mieux le comprendre.
Les bases de données relationnelles se trouvent au milieu. Tout comme les bases graphes, les bases de données relationnelles ont un modèle centré autour des requêtes. Mais ce modèle n’est pas aussi puissant que celui des bases graphes. En particulier, il ne permet pas de créer à la volée des structures arbitrairement larges, sémantiquement riches et connectées. Pour créer une structure large quelconque avec une base de données relationnelle nous devons planifier nos jointures à l’avance. Pour s’autoriser des modifications, on finit par créer beaucoup de colonnes pouvant être nulles. Résultat : des tables “parsemées”, des jointures fantaisistes (chères), des problèmes d’impédance objet-relationnel même avec des applications simples.
InfoQ : Quels sont les cas d’utilisation les plus adaptés aux bases de données graphes ?
Ian et Jim : Comme les bases de données relationnelles, la majorité des bases de données graphes sont des bases OLTP (Online transaction processing ou traitement transactionnel en ligne en français) à usage générique et peuvent s’utiliser pour aboutir à un large éventail de solutions. Cela dit, elles brillent particulièrement bien lorsque la solution au problème dépend, en premier lieu, de notre compréhension de la façon dont les choses sont connectées. Cela est plus courant que vous ne le pensez. Et dans beaucoup de cas il ne s’agit pas seulement de savoir comment les choses sont connectées mais souvent nous voulons savoir des choses sur les différentes relations dans notre domaine -- leurs noms, qualités, poids et ainsi de suite.
En résumé la connectivité est la clé. Les graphes constituent la meilleure abstraction que nous avons pour modéliser et requêter la connectivité ; les bases de données graphes à leur tour, donnent aux développeurs et aux spécialistes de la donnée, la capacité d’appliquer cette abstraction à leurs problèmes particuliers. À cette fin, nous les avons vues utilisées pour des réseaux sociaux, des moteurs de recommandations, l’autorisation et le contrôle d’accès, du routage et de la logistique, des catalogues de produits, de la gestion de centres de données, de la détection de fraude, du contrôle, des applications géospatiales et même des demandes d’émigration. Le thème clé qui lie toutes ces solutions est qu’elles doivent être capables de modéliser et d'interroger des données connectées. Avoir simplement des clés et des valeurs ne suffit pas ; pas plus qu’avoir des données partiellement connectées à travers des jointures sémantiquement pauvres. Nous avons besoin à la fois de la connectivité et de la richesse contextuelle afin de faire fonctionner ces solutions.
InfoQ : Pouvez-vous nous parler des considérations de design que les développeurs doivent garder en tête lorsqu’ils travaillent avec les bases de données graphes ?
Ian et Jim : Les décisions de design les plus importantes concernent le modèle de données et les requêtes pour une application particulière. La clé ici, comme décrit dans le livre, est de créer notre modèle à partir des questions auxquelles nous devons répondre avec nos données. En examinant les questions au coeur de l’objectif d’une application ou du besoin de l’utilisateur final, vous découvrez les choses qui vous intéressent ainsi que la façon dont elles sont connectées. Il est alors assez rapide de créer, à partir de ces questions, un modèle graphe expressif ainsi que des requêtes exécutées sur ce modèle.
Le modèle résultant et les requêtes associées sont simplement les projections des questions que vous souhaitez poser sur vos données. Avec Cypher, le langage de requêtes de Neo4J, la complémentarité de ces projections devient apparente : les chemins utilisés pour créer la structure du graphe sont les mêmes que ceux utilisés pour le requêter. Un bon premier test pour votre design est d’être capable de lire ce que vous avez écrit. Plus important encore, vos questions doivent apparaître en lisant ce que vous avez écrit, sans avoir à faire des hypothèses ou des déductions hors bande. Une structure telle que ‘(Emil)-[: a écrit]->(les bases de données graphes)<-[:a publié]-(O’Reilly)’ se lit très bien et nous aide clairement à répondre aux questions “Quels livres Emil a-t-il écrits ?”, “Qui a publié Les bases de données graphes ?” et “Pour quels éditeurs Emil a-t-il écrit ?”.
InfoQ : Quels sont les architectures ou designs patterns supportés par les bases de données graphes ?
Ian et Jim : Les bases de données graphes ne sont pas envahissantes à cet égard - ce sont juste des bases de données qui ont de très bonnes performances pour des données connectées. Ainsi les patterns applicatifs que vous souhaitez utiliser fonctionneront toujours. Vous aimez le MVC ? Bien sûr - Cela convient bien. Vous voulez travailler entièrement en Javascript avec des callbacks ? Bien sûr, il existe un très bon connecteur NodeJs pour Neo4J.
InfoQ : Les bases de données graphes ont-elles, de par leur nature, des limitations en terme de scalabilité ?
Nous parlons de trois choses différentes quand nous parlons de scalabilité : la scalabilité pour de gros volumes de données, la scalibilité pour la performance en lecture et la scalabilité pour la performance en écriture.
Il n’y a vraiment pas de limite de scalabilité en ce qui concerne les gros volumes de données. Actuellement Neo4J a une limite supérieure arbitraire sur la taille du graphe (de l’ordre de 10^10, ce qui est assez élevé pour supporter les graphes que nous voyons dans le monde réel, y compris le déploiement de Neo4J qui contient plus de la moitié du graphe social de Facebook dans un cluster Neo4J), mais cette limite sera enlevée cette année. Cela mettra fin à la plupart des préoccupations des gens concernant la scalabilité des graphes pour de gros volumes de données.
De la même manière la scalabilité des lectures ne pose pas de problème. Aujourd’hui avec Neo4J cela est géré en utilisant la réplication maître-esclave. Les lectures sont distribuées au sein du cluster et s’exécutent sur des données locales dont la structure est optimisée pour des requêtes connectées. En dehors de l’intégrité transactionnelle, historiquement Neo4J a mis l’accent sur les performance en lecture. Afin d’avoir des traversées rapides, nous avons une pile native sur le disque. Certaines bases de données graphes offrent une interface de type graphe au dessus de systèmes de stockage qui ne sont pas nativement des graphes comme des systèmes de stockage orientés colonnes. Même si cela peut aider pour certains aspects ayant trait à la scalabilité, ça a tendance à augmenter la latence car les jointures se font dans le code de la librairie plutôt qu’au niveau du modèle de données.
La scalabilité en lecture peut se faire verticalement mais à un certain point, pour des charges élevées en écriture, cela exige de pouvoir distribuer la donnée sur plusieurs machines. C’est cela le vrai challenge. Si la distribution peut améliorer les performances en écriture, il peut nuire aux performances en lecture. Jusque là, personne n’a implémenté une base de données graphe qui optimise et combine les traversées locales rapides (sur le réseau) avec des traversées distribuées.
Scaler des données de type graphe en les distribuant sur plusieurs machines est beaucoup plus difficile que scaler certains modèles de données plus simples mais cela reste possible. Scaler les stockages de type clé-valeur, famille de colonnes ou document est relativement facile puisque dans chacun de ces cas vous avez affaire à des agrégats discrets qui peuvent être placés dans leur intégralité dans un emplacement donné. Scaler un graphe est plus difficile car, de par sa nature même, ses données sont connectées. Quand nous distribuons un graphe nous évitons autant que possible d’avoir les relations qui couvrent plusieurs machines ; cela s’appelle le problème du point de cassure minimum. En plus du problème d’équilibrage du graphe de sorte qu’il y ait peu de relations qui couvrent plusieurs machines les choses sont rendues encore plus difficiles par le fait que le graphe évolue constamment. Ce qui semble être un bon choix de distribution à un moment donné pourrait ne plus être optimal quelques secondes plus tard. Cela est connu comme étant un problème NP difficile dans le cas général.
Même si nous ne pouvons pas prétendre avoir résolu le problème NP difficile du partitionnement d’un graphe dans le cas général nous avons trouvé des façons très intéressantes de nous en rapprocher. En fait nous avons une équipe R&D qui expérimente activement ces idées en ce moment même et elles pourraient être intégrées dans les futures versions du produit. En outre nous avons quelques astuces dans notre manche pour augmenter les limites de scalabilité en écriture avec la technologie actuelle.
Donc pour répondre à la question, nous dirons que la nature connectée des données du graphe impose des défis théoriques pour scaler les écritures lorsqu’on distribue le graphe. Mais il existe des solutions pratiques au problème de la distribution d’un graphe et nous sommes en train de les explorer.
InfoQ : Les bases de données graphes traitent du stockage et de la gestion des données connectées. Est-ce que cette caractéristique limite ces bases dans le support des fonctionnalités telles que le sharding et les transactions ?
Ian et Jim : Comme nous l’avons mentionné dans la précédente réponse, le sharding (le partitionnement du graphe) est la clé de la scalabilité des graphes notamment pour les écritures. Mais c’est difficile - au moins dans le cas général. Ajoutez à cela le fait d’utiliser des transactions afin de protéger l’intégrité des données et vous verrez que nous avons sous la main, un intéressant défi de design de scalabilité.
Cela dit, lorsqu’on traite beaucoup de transactions concurrentes, la nature des structures de données du graphe aide à répartir le coût transactionnel à travers le graphe. Généralement à mesure que le graphe croît, le conflit transactionnel disparaît. En d’autres termes, plus le graphe est large, plus le débit est important, ce qui est un résultat intéressant !
InfoQ : Comment les bases de données graphes supportent des fonctionnalités comme la réplication des données et le basculement (failover) ?
Ian et Jim : Aujourd’hui Neo4J supporte la réplication et le failover avec un schéma maître/esclave. Dans un cluster Neo4J, une machine est désignée comme maître et les autres des esclaves. Les écritures adressées à n’importe quelle machine finissent par passer par le maître qui envoie les mises à jour aux esclaves quand il est sollicité.
Si le maître échoue, le cluster choisit automatiquement un nouveau maître via notre implémentation de Paxos. Encore une fois, notre équipe de R&D a fait un travail intéressant pour qu’un cluster Neo4J puisse fonctionner sans maître, ce qui devrait être intégré dans les prochaines versions.
InfoQ : Pouvez-vous parler de certaines limitations des bases de données graphes ?
Ian et Jim : Comparées à quelque chose comme Apache Cassandra, les bases de données graphes d’aujourd’hui n’ont pas le même débit d’écriture - une conséquence du clustering maître/esclave et des transactions ACID propres. Utiliser une base de données de type graphe pour un panier d’achats ou du vote n’a pas beaucoup de sens sachant qu’il existe des alternatives plus appropriées à utiliser. Même si vous pourriez utiliser une base orientée colonne ou clé-valeur pour votre panier d’achats, l’analyse de l’historique des achats des clients se fait beaucoup mieux avec un graphe. C’est un pattern que nous avons déjà vu quelque fois : utiliser une simple base pour absorber la charge puis alimenter la base graphe avec les données pour les affiner et les analyser.
InfoQ : Quelles tendances se dessinent dans l’écosystème des bases de données graphes ? Que voyez-vous comme l’avenir des bases de données graphes ?
Ian et Jim : A un niveau élevé, nous pensons que les bases de données graphes se démocratisent. Il y a cinq ans, les graphes étaient une préoccupation académique et constituaient une niche, mais ils sont partout maintenant. Bientôt, les bases de données graphes seront considérées comme juste un autre outil à notre disposition. En nous basant sur la façon dont nous les voyons utilisées de nos jours, nous pensons qu’elles vont continuer à déplacer les bases de données relationnelles. Les données étant plus étroitement connectées et le domaine arrivant à maturité, leur popularité va grimper.
Ils disent également que c’est un moment excitant pour les graphes et les bases de données graphes. Ils voient beaucoup plus d’outils à la fois spécialisés et généralistes pour les graphes arriver sur le marché. Neo4J apporte des améliorations à son modèle de données, ses langages de requête, son support pour de gros volumes de données et sa performance globale. La littérature se développe et il y a maintenant des tutoriels et des cas d’utilisation en ligne. Il y a une communauté d’utilisateurs saine et active avec des meetups dans les villes à travers le monde. Et il y a des conférences GraphConnect cette année à San Fransisco, Chicago, Boston, New York et Londres et chacune comporte un mélange de sessions techniques, théoriques et pratiques avec des experts venant de l’industrie et de la communauté.
À propos des interviewés
Ian Robinson est ingénieur à Neo Technology, il travaille actuellement dans la recherche et développement sur les versions futures de la base de données graphe Neo4J. Il est co-auteur de “REST in practice” (O’Reilly) et contributeur à “REST : From Research to Practice” (Springer) et à “Service Design Patterns” (Addison-Wesley).
Dr. Jim Webber est Chef Scientifique à Neo Technology, la société derrière la base de données graphe et open source Neo4J, où il fait de la recherche et développement sur des bases de données graphes distribuées et écrit des logiciels open source. Il est co-auteur du livre “REST in Practice”. Le blog de Jim se trouve à http://jimwebber.org et il tweete depuis @jimwebber.