Découvrir MongoDB et le modèle document

Découvrir MongoDB et le modèle document

1. Présentation du cours

   1. Public cible

      Ce cours s'adresse aux :

      • Développeurs full-stack ou back-end
      • Data analysts et data scientists
      • Administrateurs de bases de données
      • Architectes solutions cloud
      • Étudiants en informatique

   2. Objectifs d'apprentissage

      À l'issue de cette formation, vous serez capable de :

      Comprendre les concepts fondamentaux des bases de données NoSQL

      Maîtriser les opérations CRUD avec MongoDB

      Concevoir des schémas de documents efficaces

      Mettre en place des agrégations complexes

      Optimiser les performances des requêtes

      Intégrer MongoDB dans un écosystème Big Data

   3. Prérequis

      Connaissances de base

      • Concepts fondamentaux des bases de données
      • Notions de programmation (JavaScript ou Python)
      • Bases du langage JSON

      Environnement technique

      • Accès à un ordinateur avec 4 Go de RAM minimum
      • Connexion Internet stable
      • Droits d'administration pour l'installation de logiciels

   4. Durée et organisation

      ~40 heures de formation

      Réparties sur plusiers séquences

      Contenu pédagogique

      • modules théoriques
      • exercices pratiques
      • projets fil rouge
      • examens

      Planning type

      • en fonction du niveau et du temps disponible
      • Accès 24/7 aux ressources en ligne
      • Support pédagogique inclus

2. Introduction à MongoDB

   Écosystème et Architecture de MongoDB

   %%{init: {'theme': 'base', 'themeVariables': { 'primaryColor': '#e1f5e1', 'primaryTextColor': '#0d6e0d', 'primaryBorderColor': '#13AA52'}}}%% flowchart TD classDef cloud fill:#13AA52,color:white,stroke:#0d6e0d; classDef enterprise fill:#5d9cec,color:white,stroke:#2c3e50; classDef tools fill:#a0d468,color:white,stroke:#5d7c1d; classDef router fill:#2c3e50,color:white,stroke:#1a252f; classDef config fill:#8e44ad,color:white,stroke:#5d2d7d; classDef primary fill:#e74c3c,color:white,stroke:#c0392b; classDef secondary fill:#f39c12,color:white,stroke:#d68910; classDef storage fill:#3498db,color:white,stroke:#2980b9; subgraph "MongoDB Ecosystem" direction TB subgraph "MongoDB Atlas (Cloud)" direction TB A1[fa:fa-cloud Atlas UI] <--> A2[fa:fa-cogs Atlas API] A2 <--> A3[fa:fa-database Atlas Data Lake] A2 <--> A4[fa:fa-search Atlas Search] A2 <--> A5[fa:fa-mobile-alt Atlas Device Sync] end subgraph "MongoDB Enterprise (On-Premise)" direction TB E1[fa:fa-tachometer-alt Ops Manager] <--> E2[fa:fa-server Enterprise Server] E1 <--> E3[fa:fa-chart-line Monitoring] E1 <--> E4[fa:fa-hdd Backup] end subgraph "MongoDB Tools" direction TB T1[fa:fa-compass Compass] <--> T2[fa:fa-tools Database Tools] T3[fa:fa-terminal MongoDB Shell] <--> T4[fa:fa-plug Drivers] T5[fa:fa-plug Connectors] <--> T6[fa:fa-chart-bar BI Connector] end subgraph "MongoDB Cluster" direction TB subgraph "Mongos Routers" M1["fa:fa-route Mongos 1 --- 🔍 Routeur de requêtes 📦 Cache de métadonnées ⚖️ Équilibrage de charge"] M2["fa:fa-route Mongos 2 --- 🔍 Routeur de requêtes 📦 Cache de métadonnées ⚖️ Équilibrage de charge"] end subgraph "Config Servers (C1, C2, C3)" C1["fa:fa-cog Config 1 --- 📋 Métadonnées 🗺️ Mapping des shards 🔄 Réplication"] C2[fa:fa-cog Config 2] <--> C1 C2 <--> C3[fa:fa-cog Config 3] end subgraph "Shard 1 (S1)" direction TB S1P["fa:fa-star Primary --- ✏️ Écritures 🔄 Réplication 👑 Leader"] S1P -->|réplique| S1S1["fa:fa-clone Secondary 1 --- 📥 Réplication 👁️ Lecture seule 🔄 Candidat à l'élection"] S1P -->|réplique| S1S2[fa:fa-clone Secondary 2] end subgraph "Shard 2 (S2)" direction TB S2P[fa:fa-star Primary] -->|réplique| S2S1[fa:fa-clone Secondary 1] S2P -->|réplique| S2S2[fa:fa-clone Secondary 2] end M1 -->|route| S1P M1 -->|route| S2P M1 -->|métadonnées| C1 M2 -->|route| S1P M2 -->|route| S2P M2 -->|métadonnées| C1 end %% Connexions entre les composants A2 -.-> M1 A2 -.-> M2 E1 -.-> S1P E1 -.-> S2P T1 --> M1 T1 --> M2 T3 --> M1 T3 --> M2 %% Classes CSS class A1,A2,A3,A4,A5 cloud; class E1,E2,E3,E4 enterprise; class T1,T2,T3,T4,T5,T6 tools; class M1,M2 router; class C1,C2,C3 config; class S1P,S2P primary; class S1S1,S1S2,S2S1,S2S2 secondary; %% Légende legend[fa:fa-list Legend] legend --> cloud_legend[Cloud Services] legend --> enterprise_legend[Enterprise Tools] legend --> tools_legend[Client Tools] legend --> router_legend[Routeur Mongos] legend --> config_legend[Config Servers] legend --> primary_legend[Nœud Primaire] legend --> secondary_legend[Nœud Secondaire] class legend,cloud_legend,enterprise_legend,tools_legend,router_legend,config_legend,primary_legend,secondary_legend legend-style; classDef legend-style fill:#f8f9fa,stroke:#ddd,stroke-width:1px,color:#333,padding:5px,font-size:12px; end

   Figure 1 : Vue d'ensemble de l'écosystème et de l'architecture MongoDB

   Explication du schéma :

   MongoDB Atlas (Cloud)

   Solution cloud complète avec interface de gestion, API, data lake et synchronisation mobile.

   MongoDB Enterprise

   Version auto-hébergée avec outils de gestion, surveillance et sauvegarde.

   Outils Clients

   Applications et bibliothèques pour interagir avec MongoDB (Compass, Shell, Drivers).

   Architecture du Cluster

   • Routeurs Mongos : Point d'entrée des requêtes clientes
   • Config Servers (C1-C3) : Stockent les métadonnées du cluster
   • Shards (S1-S2) : Stockent les données (chaque shard est un replica set)
   • Replica Sets : Groupes de nœuds (1 Primaire + Secondaires) pour la haute disponibilité

   Qu'est-ce que MongoDB ?

   MongoDB est une base de données NoSQL orientée documents, classée parmi les bases de données les plus populaires au monde. Contrairement aux bases de données relationnelles traditionnelles, MongoDB stocke les données sous forme de documents flexibles et évolutifs, ce qui en fait un choix idéal pour les applications modernes.

   À retenir

   • MongoDB est une base de données NoSQL orientée documents
   • Stockage des données en format BSON (JSON binaire)
   • Modèle de données flexible et sans schéma imposé
   • Idéal pour les applications nécessitant une grande évolutivité

   Caractéristiques clés :

   Modèle de documents

   Stockage des données en format BSON (binaire JSON) pour une grande flexibilité

   Évolutivité horizontale

   Distribution des données via le sharding pour gérer de grandes charges

   Haute performance

   Indexation avancée et accès mémoire pour des temps de réponse rapides

   Sécurité renforcée

   Chiffrement, authentification et RBAC (contrôle d'accès basé sur les rôles)

   Points clés

   • Modèle de données flexible avec BSON
   • Évolutivité horizontale via le partitionnement (sharding)
   • Performances optimisées avec indexation et cache mémoire
   • Sécurité complète avec chiffrement et contrôle d'accès fin

   Cas d'utilisation

   Applications mobiles

   Stockage flexible pour les données utilisateur et le contenu des applications mobiles avec synchronisation hors ligne.

   E-commerce

   Gestion de catalogues produits complexes avec des attributs variables selon les catégories.

   Analytique en temps réel

   Analyse de données massives avec des agrégations puissantes et des pipelines de traitement.

   Réseaux sociaux

   Gestion des profils utilisateurs, des publications et des interactions sociales avec des schémas évolutifs.

   Écosystème MongoDB

   MongoDB Atlas

   Service cloud entièrement géré pour MongoDB, offrant évolutivité et haute disponibilité.

   MongoDB Compass

   Interface graphique officielle pour explorer et analyser vos données MongoDB.

   MongoDB Shell

   Interface en ligne de commande (CLI) interactive pour administrer et interroger MongoDB.

   MongoDB Realm

   Plateforme de développement d'applications avec synchronisation des données en temps réel.

   Écosystème clé en main

   • Atlas : Solution cloud complète avec automatisation des opérations
   • Compass : GUI pour visualiser et analyser les données
   • Shell : Interface ligne de commande avancée
   • Realm : Développement d'applications mobiles et web temps réel

   Modèle de documents

   Contrairement aux bases de données relationnelles qui utilisent des tables et des lignes, MongoDB stocke les données sous forme de documents au format BSON (binaire JSON).

   Avantages

   • Schéma dynamique pour une grande flexibilité
   • Structure hiérarchique des données
   • Support natif des tableaux et documents imbriqués
   • Représentation plus naturelle des données pour les développeurs

   Exemple de document

   {
     "_id": ObjectId("5f8d8d8d8d8d8d8d8d8d8d8d"),
     "titre": "Le Seigneur des Anneaux",
     "annee": 2001,
     "duree": 178,
     "genres": ["Aventure", "Fantasy", "Action"],
     "realisateur": {
       "nom": "Jackson",
       "prenom": "Peter"
     },
     "acteurs": ["Elijah Wood", "Ian McKellen", "Viggo Mortensen"],
     "pays": "Nouvelle-Zélande",
     "note_imdb": 8.8
   }

   Architecture de MongoDB

   %%{init: {'theme': 'base', 'themeVariables': { 'primaryColor': '#e1f5e1', 'primaryTextColor': '#0d6e0d', 'primaryBorderColor': '#13AA52'}}}%% graph TD subgraph "MongoDB Cluster" subgraph "Shard 1" direction TB P1[Primary] -->|réplication| S1a[Secondary 1] P1 -->|réplication| S1b[Secondary 2] end subgraph "Shard 2" direction TB P2[Primary] -->|réplication| S2a[Secondary 1] P2 -->|réplication| S2b[Secondary 2] end subgraph "Config Servers" direction TB C1[Config 1] <--> C2[Config 2] C2 <--> C3[Config 3] end Mongos1[Mongos Router] -->|route| P1 Mongos1 -->|route| P2 Mongos1 -->|métadonnées| C1 App[Application] --> Mongos1 end style App fill:#13AA52,color:white,stroke:#0d6e0d style Mongos1 fill:#2c3e50,color:white style C1,C2,C3 fill:#5d9cec,color:white style P1,P2 fill:#48cfad,color:white style S1a,S1b,S2a,S2b fill:#a0d468,color:white

   Figure 1 : Architecture MongoDB avec Sharding et Réplication

   MongoDB est conçu pour être hautement évolutif et disponible. Voici ses composants clés :

   %%{init: {'theme': 'base', 'themeVariables': { 'primaryColor': '#e1f5e1', 'primaryTextColor': '#0d6e0d', 'primaryBorderColor': '#13AA52'}}}%% classDiagram class BaseDeDonnees { +string nom +Collection[] collections } class Collection { +string nom +Document[] documents +createIndex() +find() +insertOne() +updateMany() +aggregate() } class Document { +ObjectId _id +any champs +Date dateCreation +save() +update() +delete() } BaseDeDonnees "1" *-- "0..*" Collection : contient Collection "1" *-- "0..*" Document : contient

   Figure 2 : Modèle de données de MongoDB

   Structure de base

   Document

   Unité de base des données, stockée en format BSON (binaire JSON). Peut contenir des tableaux et des documents imbriqués.

   Collection

   Groupe de documents, équivalent à une table dans les bases relationnelles. Pas de schéma imposé.

   Base de données

   Conteneur pour les collections, avec son propre ensemble de fichiers sur le système de fichiers.

   Structure de base

   • Document : Unité de base en BSON (comme JSON mais binaire)
   • Collection : Groupe de documents (équivalent aux tables SQL)
   • Base de données : Conteneur logique pour les collections
   • Schéma dynamique : Pas de structure fixe imposée

   %%{init: {'theme': 'base', 'themeVariables': { 'primaryColor': '#e1f5e1', 'primaryTextColor': '#0d6e0d', 'primaryBorderColor': '#13AA52'}}}%% graph TD classDef database fill:#13AA52,color:white,stroke:#0d6e0d; classDef collection fill:#5d9cec,color:white,stroke:#2c3e50; classDef document fill:#a0d468,color:white,stroke:#5d7c1d; %% Base de données DB[(Base de données)]:::database %% Collection Utilisateurs DB --> C1[Utilisateurs]:::collection C1 --> D1["{\n _id: ObjectId('...')\n nom: 'Dupont'\n email: 'jean@exemple.com'\n }"]:::document %% Collection Produits DB --> C2[Produits]:::collection C2 --> P1["{\n _id: ObjectId('...')\n nom: 'Ordinateur'\n prix: 999.99\n }"]:::document %% Légende L1[Base de données]:::database L2[Collection]:::collection L3[Document]:::document

   Figure 3 : Structure hiérarchique de MongoDB

   Légende :

   Base de données

   Collection

   Document (BSON)

   Sharding (Partitionnement)

   %%{init: {'theme': 'base', 'themeVariables': { 'primaryColor': '#e1f5e1', 'primaryTextColor': '#0d6e0d', 'primaryBorderColor': '#13AA52'}}}%% flowchart LR A[Application] --> B[Mongos Router] B -->|Requête| C[Config Servers] B -->|Route| D[Shard 1] B -->|Route| E[Shard 2] B -->|Route| F[Shard 3] subgraph "Shard 1" D1[Primary] --> D2[Secondary] D1 --> D3[Secondary] end subgraph "Shard 2" E1[Primary] --> E2[Secondary] E1 --> E3[Secondary] end subgraph "Shard 3" F1[Primary] --> F2[Secondary] F1 --> F3[Secondary] end style A fill:#13AA52,color:white,stroke:#0d6e0d style B fill:#2c3e50,color:white style C fill:#5d9cec,color:white style D1,E1,F1 fill:#48cfad,color:white style D2,D3,E2,E3,F2,F3 fill:#a0d468,color:white

   Figure 3 : Architecture de Sharding dans MongoDB

   MongoDB utilise le partitionnement horizontal pour répartir les données sur plusieurs machines :

   • Shard : Instance MongoDB contenant un sous-ensemble des données (partition)
   • Config Server : Stocke les métadonnées du cluster (état du sharding)
   • Mongos : Routeur de requêtes qui aiguille vers les bons shards
   • Shard Key : Champ utilisé pour répartir les données entre les shards

   Points clés du Sharding

   • Distribution horizontale des données sur plusieurs serveurs
   • Shard Key : Clé de partitionnement critique pour les performances
   • Mongos : Point d'entrée unique pour les applications
   • Équilibrage automatique des données entre les shards

   Avantages :

   • Distribution de la charge de lecture/écriture
   • Capacité de stockage illimitée
   • Haute disponibilité et tolérance aux pannes
   • Évolutivité linéaire en ajoutant des shards

   Mongos Router

   Shard 1

   Primary

   Secondary

   Secondary

   Shard 2

   Secondary

   Primary

   Secondary

   Config Servers

   C1

   C2

   C3

   Réplication

   %%{init: {'theme': 'base', 'themeVariables': { 'primaryColor': '#e1f5e1', 'primaryTextColor': '#0d6e0d', 'primaryBorderColor': '#13AA52'}}}%% sequenceDiagram participant C as Client participant P as Primary participant S1 as Secondary 1 participant S2 as Secondary 2 C->>P: Écriture des données P-->>C: Accusé réception par Réplication P->>S1: Oplog Entry 1 P->>S2: Oplog Entry 1 S1-->>P: Accusé S2-->>P: Accusé P->>S1: Oplog Entry 2 P->>S2: Oplog Entry 2 S1-->>P: Accusé S2-->>P: Accusé end Note over P: Heartbeat régulier alt Défaillance du Primary S1->>S2: Élection S2-->>S1: Vote S1->>P: Step Down S1->>C: Nouveau Primary end

   Figure 4 : Processus de réplication et élection dans un Replica Set

   MongoDB utilise des ensembles de réplication (Replica Sets) pour assurer la haute disponibilité :

   • Primary : Nœud qui reçoit toutes les opérations d'écriture (oplog)
   • Secondaries : Nœuds qui répliquent les données du primary (synchrone/asynchrone)
   • Arbiter : Nœud spécial qui participe aux élections mais ne stocke pas de données
   • Oplog : Journal des opérations pour la réplication

   Points clés de la Réplication

   • Haute disponibilité avec basculement automatique
   • Répartition de la charge de lecture sur les secondaires
   • Oplog : Journal des opérations pour la synchronisation
   • Élections automatiques pour le nouveau primary en cas de défaillance

   Avantages :

   • Haute disponibilité (basculement automatique en cas de panne)
   • Récupération après sinistre avec les données à jour
   • Possibilité de lectures locales depuis les secondaires
   • Maintenance sans interruption de service

   Primary

   Reçoit toutes les opérations d'écriture (oplog)

   Secondaries

   Reproduisent les opérations du primary. Peuvent être utilisés pour les lectures.

   Arbiter

   Ne stocke pas de données, participe uniquement aux élections.

   Performance et optimisation

   Indexation

   MongoDB prend en charge différents types d'index pour optimiser les performances :

   • Index unique : Garantit l'unicité des valeurs
   • Index composé : Sur plusieurs champs
   • Index géospatial : Pour les requêtes de localisation
   • Index de texte : Pour la recherche plein texte
   • Index TTL : Pour l'expiration des documents

   Stockage en mémoire

   MongoDB utilise la mémoire pour optimiser les performances :

   • Cache des documents fréquemment accédés
   • Moteur de stockage WiredTiger avec compression
   • Gestion efficace des E/S disque
   • Journalisation pour la durabilité

   Agrégation

   Pipeline d'agrégation puissant pour le traitement des données :

   %%{init: {'theme': 'base', 'themeVariables': { 'primaryColor': '#e1f5e1', 'primaryTextColor': '#0d6e0d', 'primaryBorderColor': '#13AA52'}}}%% flowchart LR A[Collection] --> B[$match] B --> C[$group] C --> D[$sort] D --> E[$project] E --> F[Résultats] style A fill:#a0d468,color:white style B fill:#5d9cec,color:white style C fill:#5d9cec,color:white style D fill:#5d9cec,color:white style E fill:#5d9cec,color:white style F fill:#48cfad,color:white

   Figure 5 : Pipeline d'agrégation MongoDB

   • $match : Filtrage des documents
   • $group : Regroupement et calculs
   • $sort et $limit : Tri et limitation
   • $lookup : Jointures entre collections
   • $facet : Agrégations multiples en parallèle

   // Exemple de pipeline d'agrégation
   db.orders.aggregate([
     { $match: { status: "completed" } },
     { $group: {
         _id: "$customer_id",
         total: { $sum: "$amount" },
         count: { $sum: 1 }
     }},
     { $sort: { total: -1 } },
     { $limit: 10 }
   ])

   Optimisation des performances

   • Indexation stratégique pour les requêtes fréquentes
   • Utilisation de la RAM pour le cache des données
   • Sharding pour la distribution de la charge
   • Optimisation du schéma de données pour les cas d'usage
   • Surveillance avec MongoDB Atlas ou MongoDB Ops Manager

   Concepts avancés

   Sécurité avancée

   • Chiffrement au repos avec WiredTiger
   • RBAC (Role-Based Access Control)
   • Intégration LDAP et Kerberos
   • Audit des opérations
   • Chiffrement côté client

   Points clés sécurité

   • Authentification et autorisation avancées
   • Chiffrement des données sensibles
   • Audit des opérations critiques
   • Intégration avec les systèmes d'entreprise

   Transactions ACID

   • Support des transactions multi-documents
   • Niveaux d'isolation configurables
   • Optimisation pour les clusters distribués
   • Gestion des conflits
   • Support des opérations atomiques

   Transactions

   • ACID : Atomicité, Cohérence, Isolation, Durabilité
   • Transactions multi-documents
   • Support dans les environnements distribués
   • Gestion des conflits et des verrous

   Modélisation des données

   • Patterns de conception (Bucket, Subset, etc.)
   • Relations (références vs embedding)
   • Optimisation des schémas pour les requêtes
   • Gestion des hiérarchies complexes
   • Approche sans schéma mais avec validation

   Modélisation

   • Choix entre embedding et références
   • Optimisation pour les cas d'usage courants
   • Gestion des relations entre documents
   • Validation des schémas optionnelle

3. Structure d'une base et organisation des données

   %%{init: {'theme': 'base', 'themeVariables': { 'primaryColor': '#e1f5e1', 'primaryTextColor': '#0d6e0d', 'primaryBorderColor': '#13AA52'}}}%% flowchart TD classDef database fill:#13AA52,color:white,stroke:#0d6e0d; classDef collection fill:#5d9cec,color:white,stroke:#2c3e50; classDef document fill:#a0d468,color:white,stroke:#5d7c1d; subgraph "Base de données MongoDB" direction TB DB[("fa:fa-database Base de données")]:::database subgraph "Collections" C1["fa:fa-folder Collection Utilisateurs"]:::collection C2["fa:fa-folder Collection Commandes"]:::collection C3["fa:fa-folder Collection Produits"]:::collection end subgraph "Documents (Format BSON)" D1["{\n _id: ObjectId('...'),\n nom: 'Jean Dupont',\n email: 'jean@exemple.com'\n }"]:::document D2["{\n _id: ObjectId('...'),\n produit: 'Ordinateur',\n prix: 999.99,\n stock: 15\n }"]:::document end DB --> C1 & C2 & C3 C1 --> D1 C2 --> D2 end %% Légende subgraph " " direction TB L1[Base de données]:::database L2[Collection]:::collection L3[Document]:::document end

   Figure 3 : Structure hiérarchique de MongoDB

   Légende :

   Base de données

   Collection

   Document (BSON)