Réunion Dev@LAL 58

mercredi 3 mai 2017, 10:30 → 11:30 Europe/Paris

101 (LAL)

MongoDB, en général et dans LSST en particulier

Genèse de MongoDB dans LSST

A la base, le plan pour l'architecture de base de données de LSST était de construire un système distribué et adapté aux données d'astrophysiques autour de bases de données relationnelles centralisées comme MySQL et PostgreSQL. Dans ce cadre, l'équipe LSST a produit pas mal de développement dans le cadre du projet Qserv (Query SERVice), qui a récemment fait l'objet d'un webinaire.

Mais en étudiant MongoDB, Christian s'est rendu compte que ce système de gestion de bases de données semblait posséder "nativement" une bonne partie des fonctionnalités que Qserv implémente en surcouche des bases de données relationnelles. Cela l'a amené à se poser les deux questions suivantes :

• MongoDB peut-il remplacer Qserv, et si oui dans quelle mesure ?
• Offrira-t-il dans ce rôle des performances compatibles avec les besoins de LSST ?

Pour répondre à ces questions, Christian a entrepris une étude plus approfondie de MongoDB sur un cluster de VMs prêté par le LPC dans le cadre du projet PetaSky, avec 2 To de données de test pour avoir un scénario d'utilisation plus réaliste que le microbenchmark moyen.

Cette étude se place dans un cadre où aux Etats-Unis, le DoE et la NSF se posent le même genre de questions et demandent des études comparatives, donc les travaux de Christian sont bien accueillis par la communauté LSST.

L'écosystème Hadoop avait aussi été exploré, mais la latence des requêtes s'est révélée trop longue pour les scénarios d'utilisation interactive de LSST. Oleg confirme que ce n'est absolument pas optimisé pour ça.

Actuellement, Christian oeuvre à traduire les benchmarks de Qserv pour MongoDB, ce qui n'est pas toujours simple, notamment en présence de requêtes SQL imbriquées (voir plus bas).

Structure et fonctionnalité

MongoDB est une base de données orientée documents : on stocke un ensemble de documents, dont chacun possède un identifiant et contient des données binaires au format BSON, sans schéma fixe. Cette structure est très flexible, ce qui est un atout important pour LSST, mais complique son implémentation.

Ainsi, le support de certaines opérations SQL classiques comme les jointures est très récent dans MongoDB, et encore peu optimisé.

De même, MongoDB ne possède pas de fonctionnalité équivalente aux transactions des bases de données SQL. A l'exception de quelques opérations atomiques simples, lorsqu'on effectue une écriture, on doit acquérir un verrou au début et le relâcher à la fin. De plus, il n'y a ni vérification d'intégrité de la requête au début, ni rollback à la fin, et une mauvaise requête peut facilement endommager gravement le contenu de la base.

Pour cette raison, on peut s'attendre à ce qu'une base MongoDB ne soit pas particulièrement performante en écriture, ni très robuste face à des écritures incorrectes. En contrepartie, on y gagne du côté de la performance de lecture, puisque le moteur de la base de donnée ne doit pas s'encombrer de la bureaucratie associée à de tels mécanismes. Ce système semble donc bien adapté à des données dont le format change fréquemment, mais où les écritures sont relativement rares, ce qui est le scénario prévu pour LSST (une seule injection de données par an).

Une autre spécificité de MongoDB, c'est que ce système a été pensé à la base pour bien passer à l'échelle sur de gros volumes de données. Il a déjà été appliqué à des jeux de plusieurs milliards de documents.

Oleg a étudié MongoDB précédemment, et était arrivé à des conclusions similaires: un bon système pour des données qui changent peu, mais sont lues assez fréquemment pour nécessiter l'utilisation d'une architecture de stockage distribuée.

Localité spatiale

Une fonctionnalité de MongoDB qui est intéressante pour LSST, c'est la possibilité de gérer des données organisées spatialement, ainsi que des requêtes exploitant cette organisation. Par exemple, on peut facilement exprimer la tâche, courante en astro, de chercher des données autour d'un certain point du ciel.

Puisque MongoDB est open-source, l'algorithm est public. Christian a été le voir, et ce qu'il fait est intéressant. Il divise récursivement la surface où se trouvent les données en quadrant, et construit un hash des données à partir de leur position dans le quadtree.

A la base, la fonctionnalité a été pensée pour des systèmes d'information géographique comme Google Maps.

Requêtes

La syntaxe des requêtes de MongoDB s'écarte un peu de la tradition SQL pour se rapprocher de celle des frameworks "à la MapReduce".

Là où en SQL on utiliserait des requêtes imbriquées, MongoDB utilise plutôt un formalisme basé sur des pipelines d'opérations, où on part d'itérateurs sur des collections de données et on les transforme de différentes manières (map, filter, reduce...).

C'est un changement de paradigme intéressant, que on retrouve dans beaucoup d'autres environnements modernes: les collections Scala et les "streams" de Java 8, la bibliothèque standard de Rust, le framework multi-langages ReactiveX...

Expérience et instances de test

Dans le cadre du développement d'Atrium, Christian a essayé différentes bases de données pour le moteur Nuxeo sous jacent. Dans ses tests, MongoDB offrait de meilleures performances en lecture et des performances comparables en écriture par rapport aux alternatives étudiées.

Pour tester MongoDB sur de nouveaux projets, plusieurs solutions existent. A Orsay, le cluster Spark est équipé d'une base de données MongoDB avec quelques To de stockage.

L'entreprise MongoDB fournit aussi des instances clés en main qui peuvent être pratiques pour tester et prendre en main l'outil, sous la marque "Atlas". On peut notamment accéder gratuitement à des clusters de 3 VMs avec 512 Mo de stockage, ce qui peut être suffisant pour des petits tests.

Et en HEP?

Oleg se demandait comment le CERN gère ses énormes volumes de données aujourd'hui. A la connaissance d'Hadrien, l'infrastructure de stockage distribuée du CERN combine beaucoup de technos différentes ciblant divers besoins (CVMFS, EOS, AFS, XrootD...).

Le système qu'Hadrien connaît le mieux est CVMFS, qui est utilisé pour la distribution des logiciels, ainsi que pour les conditions expérimentales dans certaines expériences. L'abstraction utilisateur est celle d'un système de fichiers distribué en lecture seule, où une mise à jour des données est poussée par le CERN de temps en temps. Après installation d'un pilote sur la machine, l'utilisation est assez transparente.

Oleg mentionne que CVMFS n'est pas exactement un système de stockage, mais plutôt un protocole d'accès aux données basé sur HTTPS et WebDAV, qui peut interroger toutes sortes de backends. Ainsi, ce papier mentionne deux backends pour le stockage des données de CVMFS, un qui est basé sur des fichiers SQLite et du stockage de donnée centralisé classique, et un autre basé sur une infrastructure pair-à-pair à base de distribution par table de hachage distribuée et de stockage memcached.

Sujets en vrac

Le cloud

On observe de plus en plus de services comme MongoDB Atlas ou Amazon EC2, où des propriétaires de grands datacenter louent une partie de leurs ressources informatiques sous forme de machines virtuelles.

Pour des petits besoins, les tarifs sont de l'ordre de quelques centimes par heure, ce qui peut être alléchant par rapport à une infrastructure qu'on gère soi-même. Et le loueur réalise quand même un solide bénéfice grâce aux économies d'échelle. C'est pourquoi ce genre de service rencontre un grand succès auprès des PMEs par exemple. Mais même à des échelles plus importantes, quand le Centre des Données Spatiales de Strasbourg avait fait son étude sur Spark en comparant les prix d'une gestion "maison", d'Amazon EC2, et d'OVH, les tarifs d'Amazon apparaissaient compétitifs.

Cependant, il est important de se rappeler qu'il y a aussi quelques inconvénients:

• Quand on veut davantage de ressources, le prix monte vite.
• Il n'est pas toujours raisonnable d'aller confier ses données confidentielles à n'importe qui (particulièrement dans des secteurs "sensibles" comme les banques ou la santé).
• A force de centraliser la quasi-totalité des ressources informatiques mondiales dans un nombre de mains très réduites, le risque d'abus de pouvoir va croissant, et on peut s'attendre que l'avantage financier diminue à partir du moment où les acteurs du cloud seront bien assurés de leur monopole.

Comparaison de fichiers ROOT

Dans le cadre du projet ACTS, Hadrien s'est retrouvé à devoir comparer les résultats d'un traitement de données HEP en simple thread et en multi-thread, sous la forme de deux tables ROOT ("TTree") de données d'événements contenant des colonnes de type hétérogènes, et des lignes supposées être les mêmes, mais dans un ordre différent.

La difficulté du problème réside dans la gestion de données d'un type qui n'est connu qu'à l'exécution, ce qui limite beaucoup les capacités d'optimisation du compilateur C++.

Comme première approche, Hadrien a essayé de trier les lignes de la table dans un ordre canonique (par première colonne, puis par seconde colonne, etc), puis de comparer les colonnes triées. Le résultat est satisfaisant pour l'intégration continue, mais un peu lent pour un usage interactif pendant le développement.

Au détour d'un café LoOPS, on lui a proposé quelques idées pour améliorer les performances en traitant les colonnes une par une via un système de tri partiel. Les bénéfices attendus sont:

• Une sortie plus rapide du programme quand les fichiers sont différents
• De meilleures performances cache (moins de colonnes différentes à traiter)
• De meilleures optimisations du compilateur (au sein d'une colonne, il a beaucoup plus d'information).

A voir si ces derniers se concrétiseront en pratique !