Premier contact avec MongoDB et le NoSQL : MongoDB Days Paris

Cette impression de graver dans le marbre un schéma quasi définitif n'a rien de très sexy, et toutes les couches d'abstraction du monde ne peuvent rien contre cet amer constat : cette base de données a plus de 30 ans. J'ai entendu parler de mongoDB, j'ai lu quelques trucs, et je me suis rendu aux MongoDB Days à Paris.

MongoDB est une base de données dite NoSQL : elle ne repose pas sur l’historique architecture tables / colonnes, ni sur le langage SQL. Elle ne garantit pas non plus l’aspect relationnel des données (le R de SGBDR).

MongoDB propose une approche “document”, on ne stocke plus des lignes dans des tableaux, mais des documents, dont le schéma peut être aléatoire, dans des collections. Ainsi, il n’y a pas de notion de modèle, mais juste des données. C’est une approche dite schema-less.

MongoDB garantit nativement la scalabilité du système, dès le premier serveur, l’ajout de “noeuds” permet d’étendre immédiatement la capacité de stockage, et de répartir la charge de manière homogène (sous réserve d’une mise en place intelligente)

MongoDB propose nativement le support d’une architecture redondante, gage de sérénité dans des contextes de “haute disponibilité”.

MongoDB est sexy, c’est purement subjectif, mais c’est un argument à ne pas négliger. Tout comme travailler dans un environnement agréable, travailler avec des technos agréables est important, voire essentiel. MongoDB est une base de données imaginée et maintenue par des développeurs, pour des développeurs.

L’approche schema-less, la scalabilité horizontale et la tolérance aux pannes sont autant d’arguments qui succitent la curiosité, c’est pourquoi j’ai souhaité assister à cette journée.

Au cours de la journée, les aspects suivants ont été abordés :

• Le sharding et les index à travers la mise en oeuvre d’une application sociale.
• L’agilité et les performances, grâce à un retour d’expérience chez Bouygues Telecom.
• Le sharding encore, avec une approche plus technique cette fois.
• Le Big Data et MongoDB, avec Hadoop et les services de Teradata.
• Cache, backups et mises à jour autour d’une application de gestion de flux
• Gestion et supervision de mongoDB avec MMS

Sans revenir sur chacune des interventions, voici un extrait des concepts qui ont particulièrement retenu mon attention.

Schema-less mais pas concept-less

Le laxisme dont on peut faire preuve lors du stockage des données dans mongo est tout relatif. Alors qu’avec un SGBD(R) plus classique on apportera un soin particulier à modéliser les données de manière précise et fidèle à la réalité, avec mongo, on cherchera à les optimiser selon l’usage qu’on en fait. C’est l’application qui dictera le modèle : comment organiser les collections et les documents, comment partitionner, comment indexer. Une règle que j’ai trouvée sympa lorsqu’on réfléchit au modèle : les documents ne doivent pas grossir avec le temps.

Opter pour le sharding, mais pas trop tôt

Il est tentant, lors de la création d’une appli, de sur-dimensionner le hardware et les services. Un des intervenants témoigne d’un cas de figure courant : le cluster de sharding avec un seul shard. Non seulement c’est un non sens économique, mais surtout c’est une perte de temps. L’argument avancé par les développeurs est le suivant : Si l’appli grossit, on ne veut pas perdre en performances, ou se sentir à l’étroit sur notre machine. On notera que pour agir sur les performances, de nombreux leviers sont exploitables avant le sharding : Disque, RAM, CPU, indexes…

Des serveurs, des données... et des outils

Il ne semble pas y avoir d’architecture “typique” imposée pour la création d’un cluster mongoDB, les services nécessaires au fonctionnement du cluster peuvent tourner de concert avec d’autres, se partager des serveurs physiques, de petites machines virtuelles, des grosses instances dans le cloud. Tous doivent cependant être monitorés et accessibles en cas de défaillance. La société éditrice de mongoDB propose à ce titre un utilitaire en ligne (MMS) qui permet de gérer et superviser votre système entier. Facturé au nombre de serveurs, il semble indispensable à une mise en ouvre fiable et performante de mongoDB : configuration, supervision, logs, backups, reprises sur incident.