Cours de SGBD NoSQL en PDF (Intermédiaire)

SGBD NoSQL. Ce cours intermédiaire fournit des outils techniques pour concevoir et choisir des solutions NoSQL adaptées aux architectures distribuées et aux charges Big Data.

Rédigé par Smile, cabinet de conseil en transformation digitale et en architecture cloud, avec un focus on l'ingénierie des données distribuées et les bonnes pratiques opérationnelles. Contenu technique basé sur des retours d'expérience en production et des références industrielles.

Comprendre l'écosystème NoSQL

Le Not Only SQL désigne une approche alternative au modèle relationnel classique : stockage flexible, schéma variable et optimisation pour la distribution. Les systèmes NoSQL s'éloignent parfois des garanties ACID strictes au profit de modèles davantage tolérants aux latences et aux partitions (approche dite BASE), afin de maximiser la disponibilité et la scalabilité dans des environnements distribués. Le modèle BASE inclut des notions de soft state et de cohérence éventuelle, qui autorisent des états transitoires et une convergence finale des données pour privilégier la haute disponibilité.

🎯 Ce que vous allez apprendre

• Introduction au NoSQL : fondements et évolution des SGBD non relationnels.
• Types de bases non relationnelles : catégories et spécificités.
• Comparaison avec SQL : différences majeures entre bases relationnelles et non relationnelles.
• Applications pratiques : cas d'usage, architecture, scalabilité horizontale pour données non structurées.
• Choisir une solution adaptée : critères et recommandations pour la sélection en contexte distribué.

Les 4 grandes familles de bases de données NoSQL

• Orienté Document — stockage de documents JSON/BSON (ex. : MongoDB, CouchDB), modèle adapté aux schémas flexibles et aux objets complexes.
• Clé‑Valeur — lecture/écriture très rapides pour paires clé/valeur (ex. : Redis). Souvent optimisées pour la rapidité en mémoire (in-memory).
• Colonnes — stockage par familles de colonnes (ex. : Cassandra, HBase) : contrairement au stockage par lignes du modèle relationnel, les bases orientées colonnes conservent physiquement les valeurs d'une même colonne côte à côte, ce qui accélère les lectures analytiques sur quelques colonnes d'une très large table. Ce format réduit le coût des E/S pour les requêtes analytiques et les écritures massives, et facilite le partitionnement et la réplication sur de nombreux nœuds.
• Graphes — relations et requêtes de graphe performantes (ex. : Neo4j), adaptées aux parcours de relations complexes.

Moteurs de recherche et Indexation

Elasticsearch et Solr complètent souvent les architectures NoSQL pour l'indexation et la recherche textuelle. Basés sur des index inversés, ces moteurs offrent des requêtes full‑text, des agrégations et des capacités de scalabilité qui s'intègrent avec des stores NoSQL pour fournir des recherches rapides et des analyses en quasi‑temps réel. L'indexation textuelle repose sur le sharding d'index pour répartir la charge et les données sur plusieurs nœuds, et permet ainsi des recherches distribuées et tolérantes aux pannes.

Pourquoi passer du SQL au NoSQL ?

Adopter les solutions non relationnelles se justifie lorsque les contraintes requièrent scalabilité horizontale, gestion de volumes massifs, ou structures de données évolutives. Le passage est motivé par des objectifs d'évolutivité, de latence et de réduction du coût d'infrastructure pour des architectures Big Data.

Le NewSQL apparaît comme une alternative cherchant à combiner la scalabilité du NoSQL et la consistance ACID du SQL, offrant ainsi une option pour les besoins hybrides qui exigent à la fois performance distribuée et garanties transactionnelles. Des exemples concrets incluent Google Spanner et CockroachDB, qui implémentent des transactions distribuées et des mécanismes de consensus pour maintenir une forte consistance à l'échelle.

Le compromis NewSQL

NewSQL vise à résoudre le dilemme entre consistance et scalabilité en proposant des architectures distribuées capables d'exécuter des transactions ACID tout en restant partitionnables. Ces systèmes utilisent souvent des protocoles de consensus, des horloges synchronisées (ex. TrueTime) ou des stratégies de réplication avancées pour préserver la consistance au prix d'une complexité opérationnelle et de concessions possibles sur la latence en présence de partitions.

Différences entre SGBDR et NoSQL

Le modèle relationnel repose sur des schémas normalisés et des jointures pour reconstruire les relations entre tables ; il convient aux opérations transactionnelles complexes. Les bases non relationnelles privilégient souvent la dénormalisation et des modèles orientés requête pour réduire le coût des jointures, optimiser les lectures et faciliter la montée en charge horizontale. Le choix influe sur la conception des données, la gestion des transactions et les patterns de requêtage.

Scalabilité horizontale vs verticale

La scalabilité verticale augmente la puissance d'un seul serveur ; la scalabilité horizontale ajoute des nœuds pour répartir charge et stockage. Les bases NoSQL sont conçues pour une mise à l'échelle horizontale, via des techniques comme le sharding (partitionnement de données) et la réplication pour assurer tolérance aux pannes et haute disponibilité. Ces mécanismes sont centraux dans une architecture Big Data et influencent le design des applications distribuées.

Réplication Master‑Slave vs Peer‑to‑Peer : la réplication master‑slave centralise les écritures sur un maître et propage les changements aux esclaves, simplifiant la consistance mais créant un point d'écriture unique ; la réplication peer‑to‑peer (multi‑maîtres) répartit les écritures sur plusieurs nœuds, améliore la disponibilité mais requiert des mécanismes de résolution de conflits et de convergence.

Le Théorème CAP : Fondement des systèmes distribués

Comprendre le Théorème CAP

Le théorème CAP formalise le compromis entre Cohérence, Disponibilité et Tolérance au partitionnement dans les systèmes distribués. Il est impossible de garantir simultanément les trois propriétés dans toutes les conditions réseau ; il faut donc prioriser selon le cas d'usage.

Systèmes CP, AP et CA

• CP (Cohérence + Partition tolerance) : privilégient la cohérence en cas de partitionnement, au détriment de la disponibilité temporaire.
• AP (Disponibilité + Partition tolerance) : maintiennent la disponibilité malgré les partitions, avec une cohérence cohérence éventuelle.
• CA (Cohérence + Disponibilité) : réalisable uniquement en l'absence de partitionnement réseau (scénarios non distribués ou fortement contrôlés).

Les enjeux de la cohérence éventuelle (Eventual Consistency)

La cohérence éventuelle signifie que, après une série de mises à jour et un temps suffisant sans nouvelles modifications, toutes les répliques convergeront vers le même état. Ce modèle accepte des lectures potentiellement divergentes à court terme pour garantir la disponibilité et la tolérance aux partitions. Les architectes doivent évaluer l'impact sur les cas d'usage : certaines opérations métier nécessitent une consistance forte immédiate tandis que d'autres tolèrent une convergence différée au profit de performances et d'évolutivité.

Cas d'usage concrets du NoSQL

• Gestion de catalogues e‑commerce à grande échelle (ex. : MongoDB) — modèles documents pour fiches produit flexibles.
• Analyse de logs en temps réel et ingestion volumique (ex. : Cassandra) — écriture distribuée et lecture rapide pour métriques et monitoring.

Guide pratique : Installation et configuration d'un cluster NoSQL

Étapes types pour installer et configurer un nœud NoSQL dans un cluster de production :

• Préparer l'environnement : droits, ports réseau, configuration du système d'exploitation et paramètres de sécurité.
• Installer le paquet du SGBD choisi (binary, package manager ou conteneur).
• Configurer la réplication et le discovery des nœuds (seed nodes, adresses RPC).
• Définir le sharding/partitionnement selon la clé de distribution et la topologie.
• Mettre en place la surveillance et les sauvegardes : métriques, alerting et snapshots.
• Tester la tolérance aux pannes et la montée en charge avant mise en production.

Tutoriel : Comment débuter avec MongoDB ou Cassandra

Exemples rapides pour démarrer (tutoriel NoSQL, guide pratique PDF) : installation minimale, création d'une collection/table et opération de lecture/écriture.

MongoDB (exécution locale)

# démarrer mongod (exemple simplifié)
mongod --dbpath /data/db --bind_ip 0.0.0.0

# insérer un document via mongo shell
mongo --eval 'db.products.insertOne({name:"T-shirt", price:19.99})'

Cassandra (CQL)

# démarrer Cassandra (exemple simplifié)
cassandra -f

# créer une keyspace et une table
cqlsh -e "CREATE KEYSPACE demo WITH replication = {'class':'SimpleStrategy','replication_factor':3};"
cqlsh -e "CREATE TABLE demo.products (id uuid PRIMARY KEY, name text, price decimal);"

Comparatif détaillé : MongoDB vs Cassandra vs Redis

Points de comparaison synthétiques pour orienter un choix technique :

• MongoDB : modèle document flexible (BSON), indexation riche, adapté aux schémas évolutifs et aux requêtes ad hoc.
• Cassandra : orienté colonnes, très résilient en écriture distribuée et adapté aux volumes massifs et à la réplication multi‑maîtres.
• Redis : store clé‑valeur en mémoire, latence très faible pour caches, sessions et files d'attente.

Focus on MongoDB et le format BSON

BSON (Binary JSON) est le format de stockage interne de MongoDB. Contrairement au JSON texte, BSON encode les types binaires et inclut des métadonnées de longueur, ce qui permet :

• la représentation de types additionnels (dates, ObjectId, binaire) non natifs en JSON ;
• des lectures et parcours d'objets plus rapides côté moteur grâce aux préfixes de longueur et à l'optimisation de stockage ;
• un compromis taille/performance : BSON peut être plus volumineux que JSON pour certains documents mais facilite l'indexation et l'accès rapide aux champs.

La connaissance des types BSON guide la conception de schémas, la définition d'index et la gestion des conversions lors des échanges avec des clients JSON.

Sécurité et administration

La sécurité couvre authentification, autorisations, chiffrement en transit et au repos, et gestion des clés. Pour l'administration au quotidien, des outils graphiques et clients facilitent le diagnostic et la maintenance : MongoDB Compass, Robo 3T pour MongoDB, ainsi que des consoles et dashboards fournis par les distributions (monitoring, métriques). Ces outils simplifient l'exploration des schémas, la création d'index et l'analyse des performances.

❓ Foire Aux Questions (FAQ)

Qu'est-ce qu'une base de données NoSQL ?
Un système de gestion qui n'utilise pas nécessairement le modèle relationnel, conçu pour stocker et interroger des volumes importants de données hétérogènes avec flexibilité de schéma.

Quand utiliser une base de données NoSQL ?
Lorsque l'application nécessite scalabilité horizontale, faible latence sous forte charge, ou traitement de données semi‑structurées et non structurées.

Quelle est la différence entre ACID et BASE ?
ACID garantit des transactions strictes (atomicité, cohérence, isolation, durabilité), adapté aux opérations transactionnelles. BASE privilégie la disponibilité et la tolérance au partitionnement, acceptant une cohérence éventuelle pour améliorer performances et scalabilité.

📑 Sommaire du document

• Préambule
• Les limites du relationnel
• Les modèles de données NoSQL
• Panorama des solutions open source
• Choisir une solution NoSQL
• Cas d'usage et scalabilité
• Sécurité et administration
• Annexes et références