Chapitre 2 : Bases de données NoSQL Fondamentaux Plan du chapitre

Plan du Chapitre

Introduction aux bases NoSQL

Pourquoi NoSQL ? Contexte et besoins
Les bases de données NoSQL et le BIG DATA Principes des bases NoSQL
Schéma flexible (schema-less)
: Bases de données NoSQL Fondamentaux Scalabilité horizontale
Tolérance aux pannes (fault tolerance)
Limites des SGBDR
ACID vs. BASE
Problèmes de scalabilité et de flexibilité
Théorème CAP
Cohérence, Disponibilité, Tolérance au partitionnement
Compromis et exemples
Yassine Sabri, PhD
Enseignant-chercheur, University Ibnou Zohr Agadir Typologie des bases NoSQL
[Link]@[Link] Clé-valeur, Document, Colonne, Graphe
Cas d’usage spécifiques

Yassine Sabri, PhD ( Les bases de données NoSQL et le BIG DATA 1 / 70 Yassine Sabri, PhD ( Les bases de données NoSQL et le BIG DATA 2 / 70
Chapitre 2 : Bases de données NoSQL Fondamentaux Introduction aux bases NoSQL Chapitre 2 : Bases de données NoSQL Fondamentaux Introduction aux bases NoSQL

Systèmes distribués Scaling Computationnel : Traitement (1/2)

Définition
Un système distribué est un système logiciel qui permet de coordonner
plusieurs ordinateurs, généralement par l’envoi de messages via un réseau Objectif : Augmenter la capacité de traitement des données en
auquel ces ordinateurs sont connectés. parallèle.
Approches :
Pourquoi ? Distribution des calculs sur plusieurs noeuds.
Utilisation de frameworks adaptés aux gros volumes.
Manipulation d’un très grand volume de données.
Exemples :
Sans distribution, pas d’application scalable.
MapReduce
Apache Spark
Contexte
L’explosion des données (Big Data) nécessite des architectures capables de
gérer des volumes, une vélocité et une variété croissants.

Yassine Sabri, PhD ( Les bases de données NoSQL et le BIG DATA 3 / 70 Yassine Sabri, PhD ( Les bases de données NoSQL et le BIG DATA 4 / 70
 Chapitre 2 : Bases de données NoSQL Fondamentaux Introduction aux bases NoSQL Chapitre 2 : Bases de données NoSQL Fondamentaux Introduction aux bases NoSQL

Scaling Computationnel : Exemples (2/2) Scaling de Stockage : Données (1/2)

MapReduce : Objectif : Stocker et gérer des volumes massifs de données de

Divise les tâches en étapes Map (filtrage) et Reduce (agrégation). manière distribuée.
Exemple : Calcul de moyennes sur des téraoctets de logs.
Approches :
Scalabilité via Hadoop sur des clusters de machines.
Partitionnement des données sur plusieurs serveurs.
Apache Spark : Réplication pour la tolérance aux pannes.
Traitement en mémoire, plus rapide que MapReduce.
Exemples :
Exemple : Analyse en temps réel de flux de données.
Scalabilité via RDD (Resilient Distributed Datasets) sur plusieurs HDFS (Hadoop Distributed File System)
noeuds. MongoDB

Yassine Sabri, PhD ( Les bases de données NoSQL et le BIG DATA 5 / 70 Yassine Sabri, PhD ( Les bases de données NoSQL et le BIG DATA 6 / 70
Chapitre 2 : Bases de données NoSQL Fondamentaux Introduction aux bases NoSQL Chapitre 2 : Bases de données NoSQL Fondamentaux Introduction aux bases NoSQL

Scaling de Stockage : Exemples (2/2) Relation entre machines, clusters, racks et data centers

Structure et niveaux de communication

HDFS : Les data centers utilisent des LANs (Local Area Networks) avec 3
Système de fichiers distribué pour Hadoop. niveaux :
Exemple : Stockage de fichiers volumineux (vidéos, logs) sur des 1 Serveurs dans les racks :

clusters. Serveurs regroupés en racks (40 serveurs/rack typiquement).

Scalabilité via ajout de DataNodes pour augmenter la capacité. Liaison réseau rapide : environ 1 Go/sec.
MongoDB : 2 Interconnexion des racks dans un data center :
Sharding pour répartir les collections sur plusieurs noeuds. Grand nombre de racks interconnectés par des switches/routeurs.
Exemple : Gestion de millions de documents dans une base utilisateurs. Liaison plus lente : environ 100 Mo/sec.
Scalabilité via ajout de shards et replica sets. 3 Entre data centers :
Communication possible via Internet.
Liaison très lente : 2-3 Mo/sec.

Yassine Sabri, PhD ( Les bases de données NoSQL et le BIG DATA 7 / 70 Yassine Sabri, PhD ( Les bases de données NoSQL et le BIG DATA 8 / 70
 Chapitre 2 : Bases de données NoSQL Fondamentaux Introduction aux bases NoSQL Chapitre 2 : Bases de données NoSQL Fondamentaux Introduction aux bases NoSQL

Relation entre machines, clusters, racks et data centers Pourquoi NoSQL ?

Contexte
Exemples concrets (2010) Explosion des données non structurées (réseaux sociaux, IoT).
Google : Besoin de scalabilité massive pour gérer des milliards d’utilisateurs.
1 data center = 100 à 200 racks.
5000 serveurs/data center, total Limites des bases relationnelles dans les environnements distribués.
estimé 1M de serveurs.
Facebook : Exemple : Twitter
2500 CPU, 1 Po d’espace disque. 500M de tweets par jour, données non structurées (texte, hashtags).
250 Go compressés (>2 To non Nécessite une base NoSQL (ex : Cassandra) pour gérer la vélocité et
compressés). la variété.
Schéma d’un data center avec
racks
Objectif
Architecture
Les bases NoSQL offrent flexibilité, performance et évolutivité pour le Big
Shared Nothing : Les serveurs communiquent par messages, sans partage Data.
de disque ni ressources de traitement.
Yassine Sabri, PhD ( Les bases de données NoSQL et le BIG DATA 9 / 70 Yassine Sabri, PhD ( Les bases de données NoSQL et le BIG DATA 10 / 70
Chapitre 2 : Bases de données NoSQL Fondamentaux Principes des bases NoSQL Chapitre 2 : Bases de données NoSQL Fondamentaux Principes des bases NoSQL

Principe 1 : Schéma flexible (schema-less) Principe 2 : Scalabilité horizontale

Définition
Augmentation de la capacité en ajoutant des noeuds (serveurs) plutôt
qu’en améliorant un seul serveur (scalabilité verticale).

Répartition des données sur plusieurs noeuds (sharding).

Définition Équilibrage de charge automatique.
Contrairement aux SGBDR, les bases NoSQL n’imposent pas de schéma Exemple : Cassandra chez Netflix
rigide. Les données peuvent évoluer dynamiquement.
Netflix gère 2,5 milliards de requêtes par jour.
Cassandra distribue les données sur des milliers de noeuds.
Temps de réponse < 1ms même avec 150M d’utilisateurs.

Yassine Sabri, PhD ( Les bases de données NoSQL et le BIG DATA 11 / 70 Yassine Sabri, PhD ( Les bases de données NoSQL et le BIG DATA 12 / 70
 Chapitre 2 : Bases de données NoSQL Fondamentaux Principes des bases NoSQL Chapitre 2 : Bases de données NoSQL Fondamentaux Principes des bases NoSQL

Principe 3 : Tolérance aux pannes Qu’est-ce que ACID ?

Définition Définition
Les bases NoSQL garantissent la continuité du service malgré des ACID est un ensemble de propriétés garantissant la fiabilité des
défaillances matérielles ou réseau grâce à la réplication. transactions dans les bases de données relationnelles (SGBDR). Il signifie :
Atomicité
Réplication synchrone ou asynchrone des données.
Redondance sur plusieurs noeuds ou centres de données. Cohérence
Isolation
Exemple : DynamoDB
Durabilité
Amazon utilise DynamoDB pour ses services critiques (ex : panier
d’achat). Contexte
Réplication multi-région : disponibilité à 99,999%. Essentiel pour les systèmes où chaque opération doit être correcte et
En cas de panne d’un noeud, les autres prennent le relais. persistante, comme les transactions bancaires.

Objectif
Garantir que les données restent intègres même en cas d’erreur ou de
panne.
Yassine Sabri, PhD ( Les bases de données NoSQL et le BIG DATA 13 / 70 Yassine Sabri, PhD ( Les bases de données NoSQL et le BIG DATA 14 / 70
Chapitre 2 : Bases de données NoSQL Fondamentaux Principes des bases NoSQL Chapitre 2 : Bases de données NoSQL Fondamentaux Principes des bases NoSQL

Propriété 1 : Atomicité Propriété 2 : Cohérence

Définition Définition
L’Atomicité garantit qu’une transaction est exécutée entièrement ou pas La Cohérence garantit que chaque transaction amène la base de données
du tout. Si une partie échoue, tout est annulé (rollback). d’un état valide à un autre état valide, respectant toutes les règles et
contraintes définies.
Exemple : Virement bancaire
Opération : Transférer 100 du compte A (solde 500) au compte B Exemple : Contrôle d’âge dans une base
(solde 200). Contrainte : Âge des utilisateurs doit être > 18.
Étapes : Transaction : Ajouter un nouvel utilisateur (âge = 16).
1 Débiter 100 de A Solde A = 400.
2 Créditer 100 à B Solde B = 300. Résultat attendu : Transaction rejetée, car elle viole la contrainte.
Si l’étape 2 échoue (ex : panne serveur), le débit sur A est annulé État avant : Valide (tous > 18).
(rollback). État après : Valide (pas de changement).
Résultat : A = 500, B = 200 (pas de perte d’argent).
Sans cohérence, les données pourraient devenir incohérentes (ex :
Sans atomicité, risque d’incohérence (ex : argent débité mais non crédité). utilisateurs mineurs acceptés).
Yassine Sabri, PhD ( Les bases de données NoSQL et le BIG DATA 15 / 70 Yassine Sabri, PhD ( Les bases de données NoSQL et le BIG DATA 16 / 70
 Chapitre 2 : Bases de données NoSQL Fondamentaux Principes des bases NoSQL Chapitre 2 : Bases de données NoSQL Fondamentaux Principes des bases NoSQL

Propriété 3 : Isolation Propriété 4 : Durabilité

Définition Définition
L’Isolation garantit que les transactions en cours sont indépendantes les La Durabilité garantit que les modifications d’une transaction validée
unes des autres. Les modifications d’une transaction ne sont visibles (commit) sont enregistrées de manière permanente, même en cas de panne
qu’une fois terminées. système.

Exemple : Réservation de billets Exemple : Commande en ligne

10 billets disponibles pour un concert. Transaction : Client passe une commande de 50.
Transaction 1 : Utilisateur A achète 3 billets (en cours). Étapes : Paiement validé Commande enregistrée Commit.
Transaction 2 : Utilisateur B vérifie les billets restants. Panne juste après commit : Serveur redémarre.
Sans isolation : B voit 7 billets (10 - 3), mais A pourrait annuler. Résultat : Commande toujours présente dans la base (stockée sur
Avec isolation : B voit 10 billets tant que A n’a pas validé. disque).
Résultat : A valide 7 billets restants, sinon 10.
Mécanisme
Utilisation de journaux (logs) écrits sur disque avant le commit pour
récupérer les données après une panne.
Yassine Sabri, PhD ( Les bases de données NoSQL et le BIG DATA 17 / 70 Yassine Sabri, PhD ( Les bases de données NoSQL et le BIG DATA 18 / 70
Chapitre 2 : Bases de données NoSQL Fondamentaux Principes des bases NoSQL Chapitre 2 : Bases de données NoSQL Fondamentaux Principes des bases NoSQL

Qu’est-ce que BASE ? Propriété 1 : Basically Available

Définition Définition
BASE est un paradigme utilisé dans les bases de données NoSQL pour Basically Available (Fondamentalement Disponible) garantit que le
privilégier la disponibilité et la flexibilité au détriment de la cohérence système reste accessible pour répondre aux requêtes, même en cas de
immédiate. Il signifie : défaillance partielle.
Basically Available
Exemple : Réseau social
Soft state
Scénario : Un utilisateur poste un message sur Twitter.
Eventual consistency
Problème : Un noeud du cluster est hors ligne à cause d’une panne.
Contexte Résultat : Le message est accepté par un autre noeud disponible.
Idéal pour les systèmes distribués où la disponibilité est prioritaire, comme BASE : L’utilisateur peut poster, le système reste opérationnel.
les réseaux sociaux ou les applications web à grande échelle. Contraire à ACID : Une banque pourrait rejeter la transaction si un
serveur est hors ligne.
Objectif
Assurer un service continu même en cas de pannes ou de partitions réseau, Priorité à l’accès continu, même si certaines données ne sont pas
avec une cohérence atteinte à terme. immédiatement synchronisées.
Yassine Sabri, PhD ( Les bases de données NoSQL et le BIG DATA 19 / 70 Yassine Sabri, PhD ( Les bases de données NoSQL et le BIG DATA 20 / 70
 Chapitre 2 : Bases de données NoSQL Fondamentaux Principes des bases NoSQL Chapitre 2 : Bases de données NoSQL Fondamentaux Principes des bases NoSQL

Propriété 2 : Soft State Propriété 3 : Eventual Consistency

Définition Définition
Soft State (État Souple) signifie que l’état du système peut être Eventual Consistency (Cohérence Éventuelle) garantit que, si aucune
temporairement incohérent et changer sans intervention explicite, en nouvelle mise à jour n’est effectuée, toutes les copies des données finiront
attendant une mise à jour. par converger vers un état cohérent.

Exemple : Système de cache Exemple : Système de messagerie

Scénario : Une application utilise Redis comme cache pour afficher le Scénario : Un utilisateur envoie un email via Gmail.
nombre de vues d’une vidéo. Propagation : L’email est stocké sur un noeud, mais pas encore
État initial : 1000 vues sur le noeud principal. synchronisé sur tous les serveurs.
Mise à jour : 10 vues supplémentaires, mais pas encore propagées à Résultat : Un autre utilisateur peut ne pas voir l’email
tous les noeuds. immédiatement.
Résultat : Certains utilisateurs voient 1000, d’autres 1010 BASE : Après un délai (ex : quelques secondes), tous les noeuds
(incohérence temporaire). affichent l’email.
BASE : L’état est souple et se stabilisera plus tard. Contraire à ACID : Une base relationnelle garantirait une cohérence
Yassine Sabri, PhD ( Les bases de données NoSQL et le BIG DATA 21 / 70
immédiate.
Yassine Sabri, PhD ( Les bases de données NoSQL et le BIG DATA 22 / 70
Impact
Chapitre 2 : Bases de données NoSQL Fondamentaux Limites des SGBDR Chapitre 2 : Bases de données NoSQL Fondamentaux Limites des SGBDR

Limites des SGBDR : ACID vs. BASE Autres limites des SGBDR

Propriétés ACID 1. Scalabilité verticale

Propriétés BASE
Atomicité : Tout ou rien. Nécessite des serveurs plus puissants (coût élevé).
Basically Available : Toujours
Cohérence : Respect des Limite physique : impossible d’ajouter indéfiniment des ressources.
accessible.
contraintes.
Soft state : État
Isolation : Transactions 2. Gestion des données non structurées
temporairement incohérent.
indépendantes. Difficulté à stocker des données variées (JSON, vidéos).
Eventual consistency :
Durabilité : Persistance après Cohérence à terme. Schéma rigide : migration complexe pour ajouter un champ.
validation.
Idéal pour réseaux sociaux.
Idéal pour transactions bancaires. 3. Performances
Temps de réponse élevé pour des requêtes complexes sur gros
Exemple volumes.
Une banque privilégie ACID (MySQL), un réseau social privilégie BASE Exemple : MySQL peut prendre 10s pour une jointure sur 1 To de
(MongoDB). données.

Yassine Sabri, PhD ( Les bases de données NoSQL et le BIG DATA 23 / 70 Yassine Sabri, PhD ( Les bases de données NoSQL et le BIG DATA 24 / 70
 Chapitre 2 : Bases de données NoSQL Fondamentaux Limites des SGBDR Chapitre 2 : Bases de données NoSQL Fondamentaux Limites des SGBDR

Autres limites des SGBDR : Complexité dans un contexte Autres limites des SGBDR : Complexité dans un contexte
distribué (1/2) distribué (2/2)
Problématique Performances dégradées :
Les SGBDR, conçus pour des architectures centralisées, rencontrent des Latence élevée due à la coordination entre noeuds (ex : validation 2PC
difficultés majeures lorsqu’ils sont utilisés dans des systèmes distribués. - Two-Phase Commit).
Exemple : Une transaction distribuée sur 5 noeuds peut prendre 100ms
Complexité de mise en oeuvre : au lieu de 10ms en local.
Nécessité de mécanismes complexes (ex : réplication synchrone, Limitation face au partitionnement :
verrouillage distribué) pour maintenir les propriétés ACID.
Selon le théorème CAP, un SGBDR privilégiant la cohérence (CA)
Configuration lourde : gestion manuelle des noeuds, synchronisation
devient indisponible en cas de partition réseau.
des transactions.
Exemple : Une banque utilisant Oracle peut refuser des retraits si un
Exemple : Mettre en place un cluster MySQL avec réplication demande
noeud est isolé.
des ajustements fréquents et une expertise pointue.
Cas concret Conséquence
Une application e-commerce avec MySQL distribué sur plusieurs data Les SGBDR sont mal adaptés aux exigences de scalabilité et de
centers doit configurer des réplications complexes pour éviter les pertes de disponibilité des systèmes distribués modernes.
données.
Yassine Sabri, PhD ( Les bases de données NoSQL et le BIG DATA 25 / 70 Yassine Sabri, PhD ( Les bases de données NoSQL et le BIG DATA 26 / 70
Chapitre 2 : Bases de données NoSQL Fondamentaux Théorème CAP Chapitre 2 : Bases de données NoSQL Fondamentaux Théorème CAP

Théorème CAP : Définition Théorème CAP : Compromis

1. Systèmes CP (Cohérence + Partitionnement)
Principe Privilégient la cohérence au détriment de la disponibilité.
Dans un système distribué, il est impossible de garantir simultanément : Exemple : HBase, utilisé pour des analyses critiques.
Cohérence (Consistency) : Toutes les lectures renvoient la dernière Cas d’usage : Systèmes bancaires où la cohérence est essentielle.
écriture.
Disponibilité (Availability) : Chaque requête reçoit une réponse. 2. Systèmes AP (Disponibilité + Partitionnement)
Tolérance au partitionnement (Partition Tolerance) : Le système Privilégient la disponibilité au détriment de la cohérence immédiate.
fonctionne malgré des pannes réseau. Exemple : Cassandra, utilisé par Twitter.
Cas d’usage : Réseaux sociaux où une légère incohérence est tolérable.
Réalité
Les systèmes distribués doivent Exemple pratique
tolérer les partitions, donc choisir Si un noeud Cassandra est hors ligne, les utilisateurs peuvent toujours
entre CP ou AP. tweeter (disponibilité), mais les données seront synchronisées plus tard
(cohérence éventuelle).
Yassine Sabri, PhD ( Les bases de données NoSQL et le BIG DATA 27 / 70 Yassine Sabri, PhD ( Les bases de données NoSQL et le BIG DATA 28 / 70
 Chapitre 2 : Bases de données NoSQL Fondamentaux Typologie des bases NoSQL Chapitre 2 : Bases de données NoSQL Fondamentaux Typologie des bases NoSQL

Type 1 : Bases Clé-valeur Type 2 : Bases orientées Document

Caractéristiques
Structure simple : une clé unique associée à une valeur.
Très rapide pour les lectures/écritures. Caractéristiques
Peu adapté aux requêtes complexes. Données stockées sous forme de documents (JSON, BSON).
Utilisé pour gérer des sessions utilisateur ou des caches. Flexibilité : chaque document peut avoir une structure différente.
Requêtes puissantes sur les champs des documents.

Utilisé pour des catalogues de produits (ex : Amazon).

Avantage
Idéal pour des applications avec des données semi-structurées.
Cas d’usage
Cache pour accélérer un site web
(ex : Wikipédia utilise Redis).

Yassine Sabri, PhD ( Les bases de données NoSQL et le BIG DATA 29 / 70 Yassine Sabri, PhD ( Les bases de données NoSQL et le BIG DATA 30 / 70
Chapitre 2 : Bases de données NoSQL Fondamentaux Typologie des bases NoSQL Chapitre 2 : Bases de données NoSQL Fondamentaux Typologie des bases NoSQL

Type 3 : Bases orientées Colonne Type 4 : Bases orientées Graphe

Caractéristiques Caractéristiques
Données stockées par colonnes plutôt que par lignes. Données sous forme de noeuds (entités) et d’arêtes (relations).
Optimisé pour les analyses sur de grands volumes. Optimisé pour explorer les relations complexes.
Scalabilité massive grâce au partitionnement. Moins adapté aux grands volumes de données brutes.

Exemple : HBase Utilisé pour des recommandations (ex : LinkedIn).

Utilisé par Facebook pour stocker les messages du Messenger.
Capable de gérer des pétaoctets de données.
Requêtes rapides sur des colonnes spécifiques.

Cas d’usage
Détection de fraudes ou réseaux
sociaux.
Yassine Sabri, PhD ( Les bases de données NoSQL et le BIG DATA 31 / 70 Yassine Sabri, PhD ( Les bases de données NoSQL et le BIG DATA 32 / 70
 Chapitre 2 : Bases de données NoSQL Fondamentaux Typologie des bases NoSQL Chapitre 2 : Bases de données NoSQL Fondamentaux Typologie des bases NoSQL

Comparaison des types NoSQL

Type Exemple Structure Fort Limite

Clé-valeur Redis Key-Value Rapidité Requêtes simples
Document MongoDB JSON/BSON Flexibilité Cohérence éventuelle Préparatif du Chapitre : MongoDB
Colonne HBase Colonnes Scalabilité Complexité Chapitre 4 : Cluster MongoDB Sharded avec Docker
Graphe Neo4j Noeuds/Arêtes Relations Volume limité

Synthèse
Le choix dépend du cas d’usage : Yassine Sabri, PhD

Cache rapide : Clé-valeur.

Données variées : Document.
10 avril 2025
Analyse massive : Colonne.
Relations complexes : Graphe.

Yassine Sabri, PhD ( Les bases de données NoSQL et le BIG DATA 33 / 70 Yassine Sabri, PhD ( Préparatif du Chapitre : MongoDB 10 avril 2025 34 / 70
Chapitre 2 : Bases de données NoSQL Fondamentaux Cluster MongoDB Sharded avec Docker Chapitre 2 : Bases de données NoSQL Fondamentaux Cluster MongoDB Sharded avec Docker

Environnement de Travail : Docker Desktop Environnement de Travail : Studio 3T

Rôle : Plateforme pour exécuter et gérer des conteneurs Docker sur Rôle : Client graphique pour interagir avec MongoDB.
un ordinateur local. Fonctionnalités :
Fonctionnalités : Connexion à des instances MongoDB (locales ou distantes).
Déploiement rapide de MongoDB dans des conteneurs isolés. Exploration des bases, collections et documents.
Gestion des réseaux et volumes pour simuler un cluster. Exécution de requêtes, gestion des indexes, et visualisation des
Interface graphique pour visualiser conteneurs et logs. résultats.
Utilité : Idéal pour tester des configurations MongoDB (standalone, Utilité : Simplifie l’administration et le développement avec
replica set, sharded) sans installation directe. MongoDB, complémentaire à Docker pour un workflow efficace.

Yassine Sabri, PhD ( Préparatif du Chapitre : MongoDB 10 avril 2025 35 / 70 Yassine Sabri, PhD ( Préparatif du Chapitre : MongoDB 10 avril 2025 36 / 70
 Chapitre 2 : Bases de données NoSQL Fondamentaux Cluster MongoDB Sharded avec Docker Chapitre 2 : Bases de données NoSQL Fondamentaux Cluster MongoDB Sharded avec Docker

Modes de Travail avec MongoDB Mode 1 : Instance Standalone

Description : Une seule instance MongoDB sans réplication ni

MongoDB propose trois modes principaux pour répondre à différents
distribution.
besoins :
Instance Standalone Caractéristiques :
Replica Set Simple à configurer et gérer.
Sharded Cluster Pas de haute disponibilité ni de scalabilité.
Focus sur le mode professionnel : Sharded Cluster. Usage : Tests locaux ou applications avec faible charge.
Limites : Pas adapté aux environnements professionnels exigeants.

Yassine Sabri, PhD ( Préparatif du Chapitre : MongoDB 10 avril 2025 37 / 70 Yassine Sabri, PhD ( Préparatif du Chapitre : MongoDB 10 avril 2025 38 / 70
Chapitre 2 : Bases de données NoSQL Fondamentaux Cluster MongoDB Sharded avec Docker Chapitre 2 : Bases de données NoSQL Fondamentaux Cluster MongoDB Sharded avec Docker

Mode 2 : Replica Set Mode 3 : Sharded Cluster (1/2)

Description : Groupe d’instances MongoDB avec réplication (1

primary, plusieurs secondaries).
Caractéristiques :
Haute disponibilité via failover automatique.
Réplication des données pour redondance.
Usage : Applications nécessitant fiabilité et accès continu.
Limites : Pas de scalabilité horizontale pour gros volumes de données.

Yassine Sabri, PhD ( Préparatif du Chapitre : MongoDB 10 avril 2025 39 / 70 Yassine Sabri, PhD ( Préparatif du Chapitre : MongoDB 10 avril 2025 40 / 70
 Chapitre 2 : Bases de données NoSQL Fondamentaux Cluster MongoDB Sharded avec Docker Chapitre 2 : Bases de données NoSQL Fondamentaux Cluster MongoDB Sharded avec Docker

Mode 3 : Sharded Cluster (1/2) Mode 3 : Sharded Cluster (2/2) - Mode Professionnel

Usage Professionnel :
Description : Cluster MongoDB avec distribution des données sur
Gestion de bases massives (big data, applications à fort trafic).
plusieurs shards, chacun pouvant être un replica set. Répartition des charges pour performances optimales.
Composants : Tolérance aux pannes grâce aux replica sets.
Shards : Contiennent une partie des données. Exemple : Déploiement avec Docker pour simuler un cluster sharded
Config Servers : Stockent les métadonnées.
sur un réseau local.
Mongos : Routeurs pour diriger les requêtes.
Avantages :
Caractéristiques :
Évolutivité : ajout de shards selon les besoins.
Scalabilité horizontale pour gérer de gros volumes.
Flexibilité : adapte la capacité aux charges variables.
Haute disponibilité via replica sets par shard.
Défis : Complexité de configuration et gestion des clés de sharding.

Yassine Sabri, PhD ( Préparatif du Chapitre : MongoDB 10 avril 2025 41 / 70 Yassine Sabri, PhD ( Préparatif du Chapitre : MongoDB 10 avril 2025 42 / 70
Chapitre 2 : Bases de données NoSQL Fondamentaux Cluster MongoDB Sharded avec Docker Chapitre 2 : Bases de données NoSQL Fondamentaux Cluster MongoDB Sharded avec Docker

Architecture MongoDB : Cluster Sharded avec Replica Set Architecture MongoDB : Cluster Sharded avec Replica Set
(1/2) (2/2)

Un cluster sharded MongoDB divise les données en shards pour une

distribution horizontale. Replica Set : ensemble de noeuds (primary + secondaries) avec
réplication des données.
Chaque shard peut être un replica set pour assurer la redondance et la
disponibilité. Le primary traite les écritures, les secondaries répliquent et peuvent
gérer les lectures.
Composants principaux :
Shards : stockent les données. Les shards sont connectés via les routeurs pour une gestion unifiée des
Config Servers : gèrent les métadonnées. requêtes.
Mongos (routeurs) : dirigent les requêtes clients.

Yassine Sabri, PhD ( Préparatif du Chapitre : MongoDB 10 avril 2025 43 / 70 Yassine Sabri, PhD ( Préparatif du Chapitre : MongoDB 10 avril 2025 44 / 70
 Chapitre 2 : Bases de données NoSQL Fondamentaux Cluster MongoDB Sharded avec Docker Chapitre 2 : Bases de données NoSQL Fondamentaux Cluster MongoDB Sharded avec Docker

Cas de Panne : Membre Primary Cas de Panne : Membre Secondary

Si le primary tombe en panne, un secondary est élu comme nouveau Si un secondary tombe en panne, le cluster reste opérationnel.
primary.
Le primary continue à traiter les écritures, les lectures peuvent être
Processus d’élection basé sur un consensus (majorité des noeuds du affectées si dirigées vers ce secondary.
replica set).
La réplication est temporairement interrompue vers ce noeud.
Les écritures sont temporairement bloquées jusqu’à l’élection
(quelques secondes). Une fois le secondary restauré, il se resynchronise automatiquement
avec le primary.
Une fois élu, le nouveau primary reprend les opérations d’écriture.

Yassine Sabri, PhD ( Préparatif du Chapitre : MongoDB 10 avril 2025 45 / 70 Yassine Sabri, PhD ( Préparatif du Chapitre : MongoDB 10 avril 2025 46 / 70
Chapitre 2 : Bases de données NoSQL Fondamentaux Cluster MongoDB Sharded avec Docker Chapitre 2 : Bases de données NoSQL Fondamentaux Cluster MongoDB Sharded avec Docker

Réplication dans MongoDB Exécution des Requêtes dans un Cluster Sharded

Les clients se connectent au routeur mongos, pas directement aux

Réplication via un journal d’opérations (oplog) maintenu par le shards.
primary.
Mongos analyse la requête et la dirige vers le shard concerné (via la
Les secondaries récupèrent l’oplog et appliquent les changements clé de sharding).
localement.
Les requêtes globales (non shardées) interrogent tous les shards et
Assure la cohérence des données et la tolérance aux pannes. agrègent les résultats.
Paramètres configurables : délai de réplication, priorités des noeuds. Les config servers fournissent les métadonnées pour localiser les
données.

Yassine Sabri, PhD ( Préparatif du Chapitre : MongoDB 10 avril 2025 47 / 70 Yassine Sabri, PhD ( Préparatif du Chapitre : MongoDB 10 avril 2025 48 / 70
 Chapitre 2 : Bases de données NoSQL Fondamentaux Cluster MongoDB Sharded avec Docker Chapitre 2 : Bases de données NoSQL Fondamentaux Cluster MongoDB Sharded avec Docker

Scalabilité d’un Cluster Sharded Introduction au Cluster Sharded

Scalabilité horizontale : ajout de nouveaux shards pour répartir la

charge et les données. Ce chapitre guide à travers le déploiement d’un cluster sharded
Les replica sets augmentent la disponibilité et la capacité de lecture. MongoDB avec Docker.
Les routeurs (mongos) peuvent être multipliés pour gérer plus de Idéal pour les tests locaux, l’apprentissage et l’exploration des bases
connexions clients. de données.
Limites : gestion complexe des clés de sharding et équilibrage des
données.

Yassine Sabri, PhD ( Préparatif du Chapitre : MongoDB 10 avril 2025 49 / 70 Yassine Sabri, PhD ( Préparatif du Chapitre : MongoDB 10 avril 2025 50 / 70
Chapitre 2 : Bases de données NoSQL Fondamentaux Cluster MongoDB Sharded avec Docker Chapitre 2 : Bases de données NoSQL Fondamentaux Cluster MongoDB Sharded avec Docker

Prérequis et Création du Réseau Commande : Création du Réseau Docker

Docker doit être installé et en cours d’exécution.

docker network create mongodb - networ k
Connexion Internet pour télécharger les images des conteneurs.
Outil mongosh pour se connecter aux instances MongoDB.

Yassine Sabri, PhD ( Préparatif du Chapitre : MongoDB 10 avril 2025 51 / 70 Yassine Sabri, PhD ( Préparatif du Chapitre : MongoDB 10 avril 2025 52 / 70
 Chapitre 2 : Bases de données NoSQL Fondamentaux Cluster MongoDB Sharded avec Docker Chapitre 2 : Bases de données NoSQL Fondamentaux Cluster MongoDB Sharded avec Docker

Explication : Création du Réseau Docker Configuration des Shards (1/2)

Cette commande crée un réseau Docker personnalisé nommé Chaque shard est une instance MongoDB avec un ensemble de
mongodb-network. réplicas.
Cela permet à tous les conteneurs MongoDB de communiquer entre Les commandes suivantes lancent trois noeuds pour le premier shard.
eux sur un réseau dédié.

Yassine Sabri, PhD ( Préparatif du Chapitre : MongoDB 10 avril 2025 53 / 70 Yassine Sabri, PhD ( Préparatif du Chapitre : MongoDB 10 avril 2025 54 / 70
Chapitre 2 : Bases de données NoSQL Fondamentaux Cluster MongoDB Sharded avec Docker Chapitre 2 : Bases de données NoSQL Fondamentaux Cluster MongoDB Sharded avec Docker

Commandes : Lancement du Shard 1 Explication : Lancement du Shard 1

docker run -d -p 271 01:27017 -- name mongo - shard1 -1 --

net work mongodb - net work mongo :5 mongod -- sh ardsvr
-- rep lSet mongo - shard1 - rs -- port 27017 -- bind _ ip Ces commandes démarrent trois instances de MongoDB, chacune sur
localhost , mongo - shard1 -1 un port différent (27101, 27102, 27103).
docker run -d -p 271 02:27017 -- name mongo - shard1 -2 --
net work mongodb - net work mongo :5 mongod -- sh ardsvr Les options –shardsvr et –replSet mongo-shard1-rs spécifient
-- rep lSet mongo - shard1 - rs -- port 27017 -- bind _ ip que chaque conteneur est un shard et fait partie d’un replica set.
localhost , mongo - shard1 -2 L’option –bind_ip permet de lier chaque instance à une adresse IP
docker run -d -p 271 03:27017 -- name mongo - shard1 -3 -- spécifique.
net work mongodb - net work mongo :5 mongod -- sh ardsvr
-- rep lSet mongo - shard1 - rs -- port 27017 -- bind _ ip
localhost , mongo - shard1 -3

Yassine Sabri, PhD ( Préparatif du Chapitre : MongoDB 10 avril 2025 55 / 70 Yassine Sabri, PhD ( Préparatif du Chapitre : MongoDB 10 avril 2025 56 / 70
 Chapitre 2 : Bases de données NoSQL Fondamentaux Cluster MongoDB Sharded avec Docker Chapitre 2 : Bases de données NoSQL Fondamentaux Cluster MongoDB Sharded avec Docker

Initialisation du Replica Set (1/2) Commande : Initialisation du Shard 1

docker exec - it mongo - shard1 -1 mongos h -- port 27017

rs . in itiate ({
Après avoir lancé les noeuds, il faut initialiser l’ensemble de réplicas. _ id : " mongo - shard1 - rs " ,
me mber s : [
Connexion au premier noeud pour exécuter la commande { _ id : 0, host : " mongo - shard1 -1:27017"} ,
d’initialisation. { _ id : 1, host : " mongo - shard1 -2:27017"} ,
{ _ id : 2, host : " mongo - shard1 -3:2701 7"}
]
})

Yassine Sabri, PhD ( Préparatif du Chapitre : MongoDB 10 avril 2025 57 / 70 Yassine Sabri, PhD ( Préparatif du Chapitre : MongoDB 10 avril 2025 58 / 70
Chapitre 2 : Bases de données NoSQL Fondamentaux Cluster MongoDB Sharded avec Docker Chapitre 2 : Bases de données NoSQL Fondamentaux Cluster MongoDB Sharded avec Docker

Explication : Initialisation du Replica Set Serveurs de Configuration (1/2)

Cette commande initialise le replica set pour les trois instances

MongoDB. Les serveurs de configuration stockent les métadonnées du cluster.
[Link] est une commande MongoDB qui configure le replica Trois instances sont lancées pour assurer la haute disponibilité.
set en spécifiant les membres du groupe.

Yassine Sabri, PhD ( Préparatif du Chapitre : MongoDB 10 avril 2025 59 / 70 Yassine Sabri, PhD ( Préparatif du Chapitre : MongoDB 10 avril 2025 60 / 70
 Chapitre 2 : Bases de données NoSQL Fondamentaux Cluster MongoDB Sharded avec Docker Chapitre 2 : Bases de données NoSQL Fondamentaux Cluster MongoDB Sharded avec Docker

Commandes : Lancement des Serveurs de Configuration Explication : Lancement des Serveurs de Configuration

docker run -d -p 271 04:27017 -- name mongo - config -1 --

net work mongodb - net work mongo :5 mongod -- configs vr
-- rep lSet mongo - config - rs -- port 27017 -- bind _ ip
localhost , mongo - config -1 Ces commandes lancent trois instances de MongoDB configurées
docker run -d -p 271 05:27017 -- name mongo - config -2 -- comme serveurs de configuration.
net work mongodb - net work mongo :5 mongod -- configs vr L’option –configsvr indique qu’il s’agit de serveurs de configuration,
-- rep lSet mongo - config - rs -- port 27017 -- bind _ ip tandis que –replSet configure un replica set pour la haute
localhost , mongo - config -2
disponibilité.
docker run -d -p 271 06:27017 -- name mongo - config -3 --
net work mongodb - net work mongo :5 mongod -- configs vr
-- rep lSet mongo - config - rs -- port 27017 -- bind _ ip
localhost , mongo - config -3

Yassine Sabri, PhD ( Préparatif du Chapitre : MongoDB 10 avril 2025 61 / 70 Yassine Sabri, PhD ( Préparatif du Chapitre : MongoDB 10 avril 2025 62 / 70
Chapitre 2 : Bases de données NoSQL Fondamentaux Cluster MongoDB Sharded avec Docker Chapitre 2 : Bases de données NoSQL Fondamentaux Cluster MongoDB Sharded avec Docker

Commande : Initialisation des Serveurs de Configuration Explication : Initialisation des Serveurs de Configuration

docker exec - it mongo - config -1 mongos h -- port 27017

rs . in itiate ({
_ id : " mongo - config - rs " , Cette commande initialise les serveurs de configuration et les ajoute
c on figsv r : true ,
au replica set.
me mber s : [
{ _ id : 0, host : " mongo - config -1:27017"} , Le champ configsvr: true spécifie que ces serveurs sont
{ _ id : 1, host : " mongo - config -2:27017"} , responsables de la gestion des métadonnées.
{ _ id : 2, host : " mongo - config -3:2701 7"}
]
})

Yassine Sabri, PhD ( Préparatif du Chapitre : MongoDB 10 avril 2025 63 / 70 Yassine Sabri, PhD ( Préparatif du Chapitre : MongoDB 10 avril 2025 64 / 70
 Chapitre 2 : Bases de données NoSQL Fondamentaux Cluster MongoDB Sharded avec Docker Chapitre 2 : Bases de données NoSQL Fondamentaux Cluster MongoDB Sharded avec Docker

Routeur MongoDB (1/2) Commandes : Lancement des Routeurs

docker run -d -p 271 07:27017 -- name mongos -1 -- net work

mongodb - network mongo :5 mongos -- confi gdb mongo -
config - rs / mongo - config -1:27017 , mongo - config
Le routeur (mongos) dirige les requêtes vers les shards appropriés. -2:27017 , mongo - config -3:270 17 -- port 27017 -- bind _
Deux instances sont déployées pour éviter un point de défaillance ip localhost , mongos -1
unique. docker run -d -p 271 08:27017 -- name mongos -2 -- net work
mongodb - network mongo :5 mongos -- confi gdb mongo -
config - rs / mongo - config -1:27017 , mongo - config
-2:27017 , mongo - config -3:270 17 -- port 27017 -- bind _
ip localhost , mongos -2

Yassine Sabri, PhD ( Préparatif du Chapitre : MongoDB 10 avril 2025 65 / 70 Yassine Sabri, PhD ( Préparatif du Chapitre : MongoDB 10 avril 2025 66 / 70
Chapitre 2 : Bases de données NoSQL Fondamentaux Cluster MongoDB Sharded avec Docker Chapitre 2 : Bases de données NoSQL Fondamentaux Cluster MongoDB Sharded avec Docker

Explication : Lancement des Routeurs Ajout des Shards

Ces commandes démarrent deux instances de MongoDB en tant que

routeurs mongos. L’ajout des shards au cluster est la dernière étape pour compléter la
L’option –configdb permet de spécifier les serveurs de configuration configuration.
du cluster.

Yassine Sabri, PhD ( Préparatif du Chapitre : MongoDB 10 avril 2025 67 / 70 Yassine Sabri, PhD ( Préparatif du Chapitre : MongoDB 10 avril 2025 68 / 70
 Chapitre 2 : Bases de données NoSQL Fondamentaux Cluster MongoDB Sharded avec Docker Chapitre 2 : Bases de données NoSQL Fondamentaux Cluster MongoDB Sharded avec Docker

Commande : Ajout des Shards au Cluster Explication : Ajout des Shards au Cluster

docker exec - it mongos -1 mongosh -- port 27017

Cette commande ajoute le replica set mongo-shard1-rs comme
sh . ad dShard (" mongo - shard1 - rs / mongo - shard1 -1:27017 , shard au cluster sharded.
mongo - shard1 -2:27017 , mongo - shard1 -3 :27017") La commande [Link] permet d’ajouter un shard et ses
membres au cluster.

Yassine Sabri, PhD ( Préparatif du Chapitre : MongoDB 10 avril 2025 69 / 70 Yassine Sabri, PhD ( Préparatif du Chapitre : MongoDB 10 avril 2025 70 / 70