Qu’est-ce que MongoDB ? Fonctionnalités, modèle documentaire et cas d’usage

MongoDB est une base de données qui stocke les données sous forme de documents plutôt que de les organiser principalement dans des tables relationnelles. Envisagez de l'utiliser pour des données fréquemment lues ensemble, comme des catalogues de produits avec des attributs variables ou des profils utilisateur imbriqués, tout en concevant le schéma et en vérifiant les performances.

Ce guide explique le modèle de stockage de MongoDB, ses fonctionnalités, ses cas d'utilisation et ses critères d'adoption. Pour le panorama plus large, voir la comparaison des modèles NoSQL et des bases de données relationnelles.

Comment MongoDB stocke-t-il les données ?

Un document est constitué de paires champ-valeur. Une collection est un regroupement logique de documents, et une base de données peut contenir des collections pour différents usages, tels que les produits, les commandes et les clients.

MongoDB stocke les documents sous forme de BSON (Binary JSON). Le BSON exprime les structures JSON (JavaScript Object Notation) en format binaire et prend en charge des types supplémentaires, y compris les dates et les valeurs ObjectId. MongoDB ne doit donc pas être compris comme un stockage qui se contente de sauvegarder des fichiers texte JSON. Le document de référence explique les types et les règles d'identificateur.

Cet exemple JSON fictif de produit illustre la forme d'un document. Dans une collection standard, _id identifie un document. L'exemple utilise une chaîne lisible ; une application nécessite néanmoins un format d'identificateur et des règles de gestion des doublons.

{
  "_id": "book-101",
  "name": "Database Basics",
  "category": "books",
  "price_krw": 24000,
  "attributes": {
    "author": "Mina Kim",
    "pages": 320
  },
  "tags": [
    "database",
    "beginner"
  ]
}

attributes est un objet imbriqué et tags est un tableau. Les livres peuvent avoir des champs auteur et pages tandis que les appareils électroniques ont des informations sur la batterie. Conservez les règles partagées pour les types de prix, les champs obligatoires et les valeurs manquantes.

Principales fonctionnalités et leurs conditions

Schéma flexible et validation

Un schéma définit les champs, les types et les conditions requises. MongoDB n'exige pas par défaut que chaque document d'une collection ait des champs identiques. Cette flexibilité n'élimine pas la conception de schéma.

La validation de schéma peut contraindre les types autorisés et les plages de valeurs. Coordonnez les vérifications côté application et la validation de la base de données pour éviter les mélanges de prix numériques/texte ou des représentations de dates incohérentes. Avant d'ajouter des règles aux données existantes, identifiez les documents non conformes et décidez comment les mises à jour seront gérées.

Requêtes, agrégation et données associées

Les requêtes MongoDB utilisent des conditions de champ et des opérateurs au lieu d'accepter les instructions SQL telles quelles. Apprenez la syntaxe utilisée par le pilote de votre langage ou le shell. La notation par points accède aux champs imbriqués, et les requêtes peuvent également exprimer des conditions sur les tableaux.

Un pipeline d'agrégation traite les documents à travers des étapes telles que le filtrage, le regroupement et le calcul. Par exemple, filtrer les articles de commande non annulés et totaliser les quantités par produit. Le guide sur les pipelines d’agrégation explique le fonctionnement des étapes.

$lookup fournit une jointure externe gauche avec une autre collection, donc « MongoDB n'a pas de jointures » est inexact. Consultez le support $lookup et les conditions de performance. Ne supposez pas que les références reçoivent automatiquement l'application de l'intégrité référentielle associée aux contraintes de clé étrangère relationnelle.

Index et performance

Un index est une structure de données qui peut réduire les données examinées pour trouver des documents correspondants. Les index à champ unique et composés servent à différents types d'accès. La documentation de l'index explique à la fois les avantages pour les requêtes et les coûts en écriture.

Plus d'index nécessitent du stockage et du travail pour les maintenir pendant les opérations d'écriture. Les performances dépendent également de la taille des documents, du mélange lecture/écriture, de la mémoire, des disques et du réseau. Évaluez les requêtes représentatives en utilisant des plans d'exécution et une charge réaliste au lieu de supposer que NoSQL est intrinsèquement rapide.

Transactions et garanties de lecture/écriture

Une mise à jour d'un seul document est atomique : elle n'applique pas partiellement cette mise à jour. Pour les modifications qui doivent réussir ou échouer ensemble sur plusieurs documents, envisagez des transactions multi-documents sur des ensembles de réplicas ou des clusters partitionnés (sharded clusters). Ne supposez pas que la même capacité existe sur un serveur autonome.

ACID signifie Atomicité, Cohérence, Isolation et Durabilité. Passez en revue les conditions de déploiement et de configuration dans la documentation sur les transactions. Lorsque la création de commandes et la réduction des stocks affectent des documents séparés, définissez les limites de transaction, la gestion des requêtes concurrentes et le comportement de nouvelle tentative.

Le paramètre read concern contrôle l'état des données qu'une lecture peut observer, tandis que le paramètre write concern contrôle le niveau d'accusé de réception pour une écriture. Établissez les garanties nécessaires avant d'informer un utilisateur qu'un paiement est effectué et distinguez les opérations qui peuvent accepter des valeurs plus anciennes provenant des réplicas.

Les données connexes doivent-elles être intégrées ou référencées ?

L'intégration place les données connexes à l'intérieur d'un document. La référence crée un lien vers l'identifiant d'un autre document. Le guide de modélisation recommande de stocker ensemble ce qui est accédé ensemble ; le guide sur l'intégration versus référence explique les compromis pour les relations et les mises à jour.

Copier une adresse de livraison dans une commande peut préserver sa signification historique. Copier les coordonnées actuelles d’un client dans chaque commande crée des copies à maintenir lorsque ces coordonnées changent. Il faut d’abord distinguer les faits historiques des valeurs qui doivent toujours être à jour.

La taille maximale d’un document BSON ordinaire est de 16 mébioctets (MiB). Ajouter chaque commentaire ou entrée de journal dans un même tableau peut atteindre cette limite et augmenter le coût des mises à jour. Utilisez des collections distinctes, des références ou des groupes de taille bornée, en tenant compte de la limite de taille des documents MongoDB.

Quels cas d’utilisation méritent d’être pris en considération ?

Ce sont des raisons d'évaluer un modèle de document, plutôt que des garanties basées sur des catégories de secteur d’activité. Les lectures et mises à jour réelles doivent guider le choix.

Comparez également les bases de données relationnelles lorsque les rapports flexibles entre tables, les relations et contraintes partagées ou les mises à jour complexes de type plusieurs-à-plusieurs sont des exigences centrales. Stocker uniquement du JSON ne justifie pas le remplacement d'une base de données existante. Vérifiez si un modèle de document améliore les requêtes importantes et la charge opérationnelle.

Un petit exemple d'insertion et de requête

Les commandes suivantes utilisent MongoDB Shell, mongosh. Connectez-vous d'abord à un environnement d’exercice distinct, en utilisant un compte disposant des autorisations de lecture, d’écriture et de création d’index pour la base de données cible et un shell installé. Consultez la documentation de MongoDB Shell pour les instructions de connexion.

L'exemple insère un produit dans product_catalog dans la base de données mongodb_intro_demo. Commencez avec une collection vide de ce nom dans un environnement de pratique et vérifiez que votre connexion cible cet environnement avant d’exécuter les commandes.

db = db.getSiblingDB("mongodb_intro_demo");

db.product_catalog.insertMany([
{
  "_id": "book-101",
  "name": "Database Basics",
  "category": "books",
  "price_krw": 24000,
  "attributes": {
    "author": "Mina Kim",
    "pages": 320
  },
  "tags": [
    "database",
    "beginner"
  ]
}
]);

insertMany() insère des documents. Répéter le même _id dans une collection standard produit une erreur de clé en double. Pour des exercices répétés, utilisez une nouvelle base de données de pratique ou identifiez et gérez explicitement uniquement le document d'exemple que vous avez ajouté. Ne supprimez pas une collection existante pour résoudre cette erreur.

Cette requête trouve les produits dans books dont le prix est inférieur à 30 000 wons coréens, retourne leurs identificateurs, noms et prix, et trie par prix croissant. Avec seulement les données d'exemple présentes, book-101 correspond aux conditions.

db.product_catalog.find(
  { category: "books", price_krw: { $lt: 30000 } },
  { _id: 1, name: 1, price_krw: 1 }
).sort({ price_krw: 1 });

$lt signifie « moins que ». Le deuxième objet spécifie les champs retournés, une projection, et 1 dans sort() signifie ordre croissant. La référence find() explique les filtres et les projections.

Pour les filtres de prix fréquents spécifiques à une catégorie et le tri, envisagez cet index composé. Examinez la distribution réelle et les autres requêtes avant d'appliquer createIndex() en production.

db.product_catalog.createIndex(
  { category: 1, price_krw: 1 }
);

La commande suivante exécute la requête et rapporte les statistiques d'exécution sans modifier les documents. Dans les résultats explain("executionStats"), inspectez le plan choisi, les clés et les documents examinés, ainsi que les documents retournés. Une petite collection peut utiliser un balayage de collection ; créer simplement un index ne démontre pas une amélioration de la vitesse.

db.product_catalog.find(
  { category: "books", price_krw: { $lt: 30000 } }
).sort({ price_krw: 1 }).explain("executionStats");

La réplication et le sharding ont des rôles différents

Un ensemble de réplicas est un groupe de serveurs maintenant les mêmes données. Typiquement, un primaire accepte les écritures et les secondaires répliquent les changements ; les membres éligibles peuvent élire un nouveau primaire après une panne. Le guide de réplication explique les élections et la réplication asynchrone.

Le basculement peut provoquer des délais ou des erreurs d'écriture temporaires, et les lectures secondaires peuvent refléter un retard de réplication. La réplication ne garantit pas de manière absolue un service ininterrompu ni ne prévient toute perte de données. Concevez les tentatives, la gestion des requêtes en double et les garanties de lecture/écriture requises avec l'application.

Le sharding distribue les données sur plusieurs serveurs pour un passage à l’échelle horizontal. Une clé de shard contient les champs utilisés pour la distribution et le routage des requêtes. Les clés concentrées ou les requêtes qui doivent visiter chaque shard peuvent limiter l’avantage. Le guide sharding explique la sélection des clés et la complexité opérationnelle.

La réplication et le sharding peuvent être utilisés ensemble, mais ils ont des objectifs différents. Vérifiez le modèle, les index et les goulots d’étranglement actuels avant d’introduire le sharding simplement parce que les données pourraient croître. Il doit y avoir une raison pour accepter sa complexité et son coût supplémentaires.

Que devriez-vous vérifier avant d’adopter MongoDB ?

1. Définir les opérations importantes. Spécifier les filtres, l'ordre et les unités de mise à jour pour les détails du produit, les recherches de prix par catégorie et la création de commandes ; comparer les implémentations relationnelles et documentaires réelles.
2. Examiner le modèle et la validité des données. Décider de l'intégration ou des références, de la taille des documents, de la validation, des index, des transactions et des exigences de lecture immédiate.
3. Comparer la charge représentative. Mesurer la latence, le débit et les erreurs avec des données réalistes et une distribution des requêtes. Enregistrer les versions, le matériel et les paramètres, et examiner les scénarios de défaillance et de récupération.
4. Choisir un modèle opérationnel. Décider entre l'autogestion et un service géré, en attribuant la responsabilité pour la sauvegarde, la restauration, la surveillance, les mises à niveau et le support.
5. Préparez la migration et un itinéraire de retour. Définissez les conversions d'identifiant/type, les vérifications des données manquantes, les écritures pendant le basculement et les conditions pour revenir au magasin existant.

MongoDB Atlas est un service cloud géré avec une répartition différente des responsabilités opérationnelles par rapport à un déploiement autogéré. Utilisez la documentation Atlas pour vérifier les fonctionnalités nécessaires et les options de déploiement. Incluez le stockage, les sauvegardes, la mise en réseau et le travail opérationnel en plus des coûts des instances.

Pour la production, examinez les comptes à privilèges minimaux, les connexions chiffrées, les restrictions réseau et la gestion des informations d'identification en utilisant les directives de sécurité appropriées à votre déploiement. Une suppression accidentelle peut se propager aux répliques, donc la réplication ne remplace pas la sauvegarde. Suivez les directives de méthode de sauvegarde et vérifiez que la restauration fonctionne réellement.