MongoDB : comprendre la base documentaire
Auteur : Rédaction Domeny.ForSale Publié le
En bref : MongoDB est une base de données documentaire : elle stocke les informations dans des structures semblables à des objets JSON, plutôt que de les organiser uniquement en tables composées de lignes et de colonnes. Elle convient notamment aux applications dont les données présentent une structure imbriquée ou des ensembles d’attributs différents. Elle n’est toutefois pas automatiquement plus rapide ni plus simple qu’une base SQL : le choix dépend avant tout de la manière dont les données sont enregistrées et lues.
Comment MongoDB stocke les données
MongoDB appartient à la famille des bases NoSQL, qui regroupe les systèmes ne reposant pas exclusivement sur le modèle relationnel traditionnel. L’unité de données de base est le document : un ensemble de champs et de valeurs décrivant, par exemple, un produit, un utilisateur ou une commande. Les documents sont regroupés dans des collections, dont le rôle est proche de celui des tables, sans imposer à tous les enregistrements une structure de champs identique.
Un document peut être représenté sous une forme JSON lisible :
{
"_id": "produit-101",
"nom": "Sac à dos urbain",
"prixGroszy": 18900,
"couleurs": ["noir", "bleu marine"],
"caracteristiques": {
"capaciteLitres": 20,
"impermeable": true
}
}
Le champ _id est l’identifiant unique du document. Si l’application ne le fournit pas, un identifiant de type ObjectId est généralement attribué lors d’une insertion standard. Les autres champs peuvent notamment contenir du texte, des nombres, des listes et d’autres documents.
En interne, MongoDB utilise BSON, un format binaire de documents qui prend aussi en charge des types de données absents du format JSON, comme les dates. Dire que MongoDB « stocke du JSON » est donc une simplification utile, et non une description exacte du format de stockage.
En quoi MongoDB diffère d’une base SQL
Les bases de données relationnelles, comme PostgreSQL ou MySQL, organisent les données en tables et permettent de les joindre à partir de champs communs. Une table de commandes peut, par exemple, faire référence à une table de clients. SQL est un langage servant notamment à interroger ces bases.
Dans MongoDB, les informations liées sont souvent placées dans un même document. Une commande peut contenir la liste des articles et l’adresse de livraison au moment de l’achat. L’application récupère ainsi toutes les données nécessaires sans devoir les réunir à partir de plusieurs structures distinctes.
| Aspect | MongoDB | Base de données relationnelle |
|---|---|---|
| Structure principale | Documents regroupés en collections | Lignes regroupées en tables |
| Modèle de données | Imbrications et listes naturelles | Colonnes et relations explicitement définies |
| Liens entre données | Données intégrées ou références | Clés étrangères et jointures |
| Requêtes | Opérations sur les documents et pipelines d’agrégation | Requêtes SQL |
Cette comparaison ne signifie pas que leurs possibilités sont strictement séparées. Les bases relationnelles peuvent prendre en charge JSON, et MongoDB permet de joindre les données de plusieurs collections, notamment avec l’opération $lookup. MongoDB prend également en charge les transactions portant sur plusieurs documents, mais leur coût et leurs exigences de déploiement doivent être pris en compte dans le projet.
Un schéma souple ne signifie pas une absence de règles
Les documents d’une même collection peuvent avoir des champs différents. Dans le catalogue d’une boutique, un sac à dos peut avoir une capacité en litres, tandis qu’un écran possède une diagonale et une résolution. Il n’est pas nécessaire de créer le même ensemble de colonnes vides pour chaque type de produit.
Cette souplesse ne dispense toutefois pas de concevoir un modèle de données. Si une partie de l’application enregistre le prix sous forme de nombre et une autre sous forme de texte, le filtrage et les calculs deviennent plus difficiles. MongoDB propose une validation du schéma : des règles qui vérifient notamment les champs obligatoires et leurs types.
Il faut aussi décider quelles données intégrer dans un document et lesquelles conserver sous forme de références. L’adresse de livraison enregistrée dans une commande doit généralement rester une copie historique. Il vaut mieux conserver le profil actuel du client séparément, plutôt que de mettre à jour ses copies dans toutes les commandes.
Il ne faut pas ajouter indéfiniment des données à un même document. MongoDB limite la taille d’un document BSON à 16 MiB : un historique d’événements qui ne cesse de croître nécessite donc généralement une collection distincte.
Quand choisir MongoDB et quand envisager PostgreSQL
MongoDB est un choix à envisager lorsque l’application manipule des objets complexes dont le contenu est souvent lu dans son ensemble. C’est le cas, par exemple, d’un catalogue de produits aux attributs variés, d’un système de gestion de contenu ou de configurations d’appareils. Le seul fait qu’une application utilise JavaScript ne suffit pas à justifier ce choix.
Une base relationnelle mérite d’être envisagée en priorité lorsque les besoins essentiels sont de nombreux liens entre données, des contraintes d’intégrité entre tables et des rapports réunissant plusieurs types de données. C’est notamment le cas d’un système de gestion des règlements, où la facilité à contrôler les relations peut compter davantage que la liberté offerte par la structure des documents.
Avant de décider, notez les trois opérations les plus fréquentes de l’application, par exemple rechercher un produit, récupérer un panier et enregistrer une commande. Préparez ensuite un modèle d’exemple dans les deux bases. Vérifiez combien de lectures et de mises à jour chaque opération nécessite, ainsi que les endroits où les mêmes informations sont dupliquées.
Comment démarrer et préparer le déploiement
Vous pouvez exécuter MongoDB sur votre propre infrastructure ou utiliser MongoDB Atlas, un service cloud géré. Pour travailler avec les données, vous disposez notamment de l’outil graphique MongoDB Compass, du shell mongosh et de pilotes pour les langages de programmation. Vérifiez les tarifs actuels, les limites et l’étendue des sauvegardes d’Atlas dans la documentation officielle et la grille tarifaire de l’offre choisie.
Pour commencer, créez une collection de test, ajoutez une douzaine à une vingtaine de documents et exécutez des requêtes courantes. Choisissez ensuite les index, des structures supplémentaires qui accélèrent les recherches, en fonction des filtres et des tris réellement utilisés. Un excès d’index occupe de l’espace et augmente le coût des écritures.
Avant le déploiement en production, configurez l’authentification, les restrictions d’accès réseau et les sauvegardes, puis testez la restauration des données. Utilisez le premier prototype pour vérifier le modèle et les requêtes : seules des mesures sur des données représentatives permettront d’évaluer si MongoDB convient à l’application concernée.
À lire aussi : Qu’est-ce que la 2FA ?
À lire aussi
