GraphDB dans ATLAS

Julius a fait une présentation sur l’utilisation d’une base de données pour graphes dans ATLAS. Il a réutilisé des planches existantes, mais en passant plus rapidement sur les parties qui ne sont intéressantes que pour ATLAS.

Le terme « GraphDB » peut être compris de plusieurs manières :

• Le concept général d’une base de données pensée pour stocker des graphes (noeuds reliés par des relations non connues à l’avance)
• Une implémentation commerciale de ce concept par l’entreprise Ontotext
• Une autre implémentation de ce concept, dans le contexte de l’ATLAS Event Index, sur laquelle Julius travaille

Ici, nous parlerons principalement de l’implémentation ATLAS. Mais Julius souhaiterait changer le nom du projet ultérieurement, afin d’éviter toute confusion.

L’ATLAS Event Index est un catalogue interactif de métadonnées d’événements de physique des particules. Il permet aux physiciens d’ATLAS de chercher des événements vérifiant certaines propriétés pour leurs analyses, via une interface web.

Certaines métadonnées expriment des relations entre événements, ou bien d’un événement à d’autres entités. Ces relations constituent un graphe au sens de la théorie des graphes. Mais elles sont difficiles à exprimer dans le vocabulaire des bases de données relationnelles classiques, notamment quand on veut pouvoir facilement ajouter ou supprimer des relations au sein de la table.

Les bases de données pour graphes visent à résoudre ce problème. Elles s’appuient généralement sur une base de donnée relationnelle, qu’elles utilisent d’une certaine manière pour introduire le concept de relation entre noeuds au sens de la théorie des graphes. L’API qu’elles proposent est plus simple à utiliser dans ce cadre, au prix toutefois d’une performance plus chaotique qu’avec l’utilisation directe du SQL. On pourrait ici faire un parallèle avec la différence entre le Fortran et les langages orientés objets : l’un est plus facilement optimisable par le compilateur, l’autre plus flexible.

Il n’y a pas de moteur de base de données dédié aux graphes, sans doute parce que les modèles de données sont finalement assez simples (une poignée de tables) et la pertinence d’un système dédié est donc contestable. En revanche, il est assez facile de changer de moteur de base de données, par exemple Julius a déjà fait une migration HBase => Cassandra sans problème majeur.

Le concept de base de données pour graphe est ancien, mais a connu un regain d’intérêt récemment, car il facilite le stockage d’un réseau de neurones au sein d’une base de données avec possibilité de modifier la topologie dudit réseau ultérieurement.

Au fil de son histoire, l’ATLAS Event Index a utilisé de nombreux back-ends pour stocker ses métadonnées :

• Au début, il y avait une base de données Oracle, mais cela s’est révélé trop inflexible.
• Ensuite, le projet est passé à un stockage Hadoop, plus flexible mais dont la latence s’est révélée trop mauvaise pour une utilisation interactive depuis l’interface web.
• Puis il y a eu une migration partielle à HBase, où le projet s’est retrouvé à essayer d’implémenter lui-même une base de données de graphes par dessus un système relationnel. Le système résultant s’est avéré complexe et difficile à maintenir.
• C’est la raison pour laquelle l’Event Index se dirige maintenant vers une base de données directement pensée pour le stockage de graphes.

Julius a fait un petit tour d’horizon des possibilités actuelles de l’interface graphique de l’ATLAS Event Index en terme d’affichage et d’interaction avec des graphes stockés dans HBase. Bien que l’interface soit implémentée en Javascript, elle est capable de supporter des volumes de données très importants.

Dans le cadre du projet GraphDB, un des objectifs poursuivis est de rendre la couche d’interface graphique moins spécifique à l’Event Index, d’utiliser un système plus générique pour l’affichage de graphes qui tire parti de l’information « graphe » de haut niveau exposée par la nouvelle base de données.

Cette information est exposée sous la forme d’une API fonctionnelle appelée Gremlin, standard de fait qui a été interfacé dans toutes sortes de langages de programmation. Julius a utilisé l’implémentation JanusGraph de cette API, qui introduit la notion de graphe par dessus un stockage existant (ici HBase) et permet de manipuler les données soit comme un graphe, soit via une interface relationnelle à la SQL. Il existe d’autres implémentations de Gremlin, par exemple neo4j est aussi actuellement étudiée au sein d’ATLAS.

Des outils génériques de visualisation de graphes basés sur Gremlin existent. Malheureusement, les outils généralistes et open-source disponibles n’étaient pas très convaincants. Julius a donc décidé d’écrire le sien, en gardant à l’esprit que l’idée est d’être applicable à tout type de graphe (pas seulement ceux de l’Event Index).

La pile technologique actuelle utilise Groovy pour parler à l’API Gremlin du côté du serveur, et Javascript du côté de l’interface web du client. Les transparents contiennent quelques exemples de requêtes Gremlin qui donnent une idée de ce qui est faisable et du mode de fonctionnement de l’API. Il est possible d’interagir avec Gremlin soit via une API web, soit via un client en ligne de commande.

Le passage à l’échelle de GraphDB est assuré par l’utilisation de Hadoop et HBase, donc Julius s’attend à avoir des performances comparables à la solution existantes.

Guy a demandé si une extension aux données d’événements (au-delà des seules métadonnées, donc incluant des informations comme des points de mesure ou des traces de particules) serait envisageable. Julius pense que le système actuel n’a pas été conçu pour gérer ce volume de données beaucoup plus important (~Po, contre ~10s de To actuellement) et aurait des difficultés à le faire. De plus, même en supposant que la chose soit faisable sur le plan technique, l’idée serait très probablement rejetée sur le plan politique.

Guy se demande aussi s’il serait possible d’extraire des données de fichiers de graphes locaux, par exemple utilisant le format DOT de GraphViz. Julius explique que le cas d’utilisation principal d’une base de données pour graphes reste d’aller chercher dans un serveur de bases de données, mais qu’il existe un backend permettant d’accéder à des données en RAM qui pourrait peut-être servir dans ce genre de cas.

Julien s’est interrogé sur le nombre d’utilisateurs simultanés que pourrait gérer l’Event Index, invoquant le compromis entre efficacité maximale (système de batch centralisé) et passage à l’échelle maximal (base de données distribuée). Pour l’instant, le système utilise HBase, une base de données distribuée.

Formation Git

Hadrien termine l’évolution du support de sa formation Git qui se déroule la semaine prochaine.
Le support est disponible ici

Il a essayé Git LFS pour l’occasion, qui est peut-être un peu désagréable à installer, mais très transparent ensuite.
Grigory souligne qu’il faut prévenir  dans la doc d’un dépôt quand on l’utilise.
François se demande s’il y a réellement besoin d’une formation pour utiliser git, puisqu’il suffit de 5 commandes. Il est possible qu’un Antoine soit nécessaire pour compléter les 5 commandes…
S’ensuivent des discussions sur les intérêts respectifs des didacticiels (« tutorials » en anglais) par rapport à la doc de référence de git.

Christian indique que les outils graphiques comme SourceTree aident à l’apprentissage en illustrant et montrant les commandes
GitHub et GitLab montrent aussi de plus en plus des commandes à exécuter

Le passage à l’échelle nationale de cette formation git est envisagé, via une mise à disposition pour DevLog.