NoSQL c'est quoi ? Les familles de bases et MongoDB

NoSQL désigne les bases de données qui ne rangent pas leurs données dans des tables reliées par des clés, comme le fait une base relationnelle. Elles suivent d'autres modèles : documents, paires clé-valeur, colonnes larges, graphes. MongoDB, la plus connue des bases NoSQL, stocke des documents proches du JSON. Ce chapitre explique ce qui distingue ces familles du modèle relationnel, et comment décider si MongoDB convient à ton application.

Le modèle relationnel et ses limites

Une base relationnelle (MySQL, MariaDB, PostgreSQL, SQL Server) range les données dans des tables au schéma fixe : chaque ligne a les mêmes colonnes, chaque colonne un type. Les tables sont reliées par des clés étrangères, et le SGBD garantit que ces liens restent valides. On interroge le tout avec SQL, un langage normalisé, et les jointures reconstituent l'information répartie entre les tables. Le cours SQL détaille ce modèle.

Ce modèle a fait ses preuves depuis cinquante ans. Il garde trois points faibles, qui ont poussé à chercher autre chose dans les années 2000 :

• Le décalage avec les objets du code. Une fiche de frais d'AppliFrais, dans le code JavaScript, est un objet qui contient ses lignes de frais. En base relationnelle, elle est éclatée dans trois tables (fiche_frais, ligne_forfait, ligne_hors_forfait). Il faut la découper à l'écriture et la recoller avec des jointures à la lecture. On appelle ce décalage l'impedance mismatch.
• Le schéma rigide. Ajouter un attribut demande un ALTER TABLE sur toute la table. Quand les attributs varient d'un enregistrement à l'autre (un catalogue où un ordinateur a une taille d'écran, et une imprimante un nombre de pages par minute), on finit avec des dizaines de colonnes vides, ou une table « attribut-valeur » pénible à interroger.
• La montée en charge. Un serveur relationnel grossit surtout verticalement : plus de processeurs, plus de mémoire, sur une seule machine. Répartir une base relationnelle sur plusieurs serveurs est possible, mais complexe, parce que les jointures et les transactions supposent d'avoir toutes les données sous la main.

Les géants du web (Google, Amazon, Facebook) ont été les premiers à buter sur ces limites, avec des milliards d'enregistrements répartis sur des milliers de machines. Ils ont conçu leurs propres bases, et le mouvement a pris le nom de NoSQL vers 2009. On le lit aujourd'hui Not only SQL : il ne s'agit pas de remplacer SQL, mais d'ajouter d'autres outils.

Les quatre familles de bases NoSQL

Le mot NoSQL ne désigne pas une technologie : il regroupe des modèles très différents, qui n'ont en commun que de ne pas être relationnels.

Deux familles plus spécialisées complètent le paysage : les bases de séries temporelles (InfluxDB, TimescaleDB), pour les mesures horodatées de la supervision, et les bases vectorielles, qui retrouvent des textes ou des images « proches » pour les applications d'intelligence artificielle. MongoDB Atlas et PostgreSQL (avec l'extension pgvector) proposent aujourd'hui une recherche vectorielle.

Relationnel ou NoSQL : les différences

Deux idées reçues à corriger tout de suite. « NoSQL veut dire sans schéma. » Faux en pratique : les données ont toujours une structure, que l'application suppose. La différence, c'est qui la vérifie : en relationnel, le SGBD ; en NoSQL, l'application (avec Mongoose, par exemple), ou la base si tu lui donnes un schéma de validation (chapitre 6). « NoSQL est plus rapide. » Pas en soi : une lecture d'un document complet est rapide parce qu'il n'y a pas de jointure à faire, mais une requête qui croise beaucoup de données est souvent plus simple et plus rapide en SQL.

Cohérence et répartition : ACID, BASE et CAP

Une base relationnelle garantit les propriétés ACID de ses transactions : atomicité, cohérence, isolation, durabilité (transactions SQL). Les premières bases NoSQL réparties ont assoupli ces garanties pour rester disponibles quand le réseau entre leurs serveurs se coupe : on parlait de modèle BASE (Basically Available, Soft state, Eventually consistent), avec une cohérence à terme : les serveurs finissent par avoir tous la même donnée, mais pas forcément à l'instant où tu lis. Le théorème CAP formalise ce choix entre cohérence et disponibilité en cas de coupure réseau.

MongoDB se situe du côté de la cohérence. Une écriture sur un document est toujours atomique : soit tout le document est modifié, soit rien. Depuis la version 4.0, MongoDB offre aussi des transactions ACID sur plusieurs documents (chapitre 11). Par défaut, une écriture est confirmée quand la majorité des serveurs du groupe l'a enregistrée, et on lit sur le serveur principal : tu relis donc ce que tu viens d'écrire.

MongoDB en quelques repères

MongoDB est une base orientée documents créée en 2007 par la société 10gen, devenue MongoDB Inc. ; la première version publique date de 2009. Son nom vient de humongous, « gigantesque » en argot américain. C'est aujourd'hui l'une des bases de données les plus utilisées au monde, et la plus connue des bases NoSQL.

Quand choisir MongoDB

MongoDB convient bien quand :

• les données ont une forme d'arbre naturelle : un objet et ses sous-éléments, lus et écrits ensemble (une fiche et ses lignes, une commande et ses articles, un article de blog et ses blocs de contenu) ;
• la structure varie d'un enregistrement à l'autre, ou évolue souvent pendant le développement ;
• l'application est écrite en JavaScript de bout en bout (React, Node.js) : le même objet JSON circule du navigateur à la base sans conversion ;
• le volume ou le débit d'écriture impose de répartir la base sur plusieurs serveurs.

Le relationnel reste préférable quand :

• les données sont très liées entre elles et interrogées dans tous les sens (un parc informatique, un planning, une gestion de stocks avec fournisseurs, commandes et livraisons) ;
• l'intégrité doit être garantie par la base elle-même : clés étrangères, contraintes, cascades ;
• l'application produit beaucoup de statistiques croisées et de tableaux de bord ;
• l'équipe, ou le sujet d'examen, attend du SQL.

Pour AppliFrais, le modèle document tombe juste pour la fiche de frais : elle est toujours lue avec ses lignes, ses lignes n'existent pas sans elle, et la fiche d'un mois ne grossit pas indéfiniment. Les visiteurs, eux, sont partagés entre toutes leurs fiches : on les rangera dans leur propre collection et la fiche gardera une référence vers son visiteur. Ce raisonnement, imbriquer ou référencer, est le cœur du chapitre 6.

MongoDB au BTS SIO

MongoDB n'est pas imposé par le référentiel : en SLAM, le cœur de la compétence « Gérer les données » reste le relationnel et SQL, que les sujets d'E7 utilisent. Mais le référentiel parle bien de « développer des fonctionnalités applicatives au sein d'un système de gestion de base de données (relationnel ou non) », et l'un des indicateurs de l'E6 est que « le type de base est pertinent » (compétences évaluées à l'E6). Si une de tes réalisations utilise MongoDB, prépare donc la question « pourquoi pas MySQL ? » : la réponse tient en deux arguments tirés de tes données, comme ceux de la section précédente.

Exercices

Exercice 1 sur 3 Choisir une famille de base Réussi À revoir

Pour chaque besoin, propose une famille de base de données (relationnelle, clé-valeur, document, colonnes larges ou graphe) et justifie en une phrase.

1. Garder en mémoire les paniers des visiteurs d'un site marchand pendant 30 minutes.
2. La gestion des prêts de matériel d'un lycée : élèves, matériels, prêts, retours, pénalités.
3. Les fiches produits d'un site de vente de matériel informatique : un écran a une diagonale et une fréquence, un disque une capacité et une interface, une souris un nombre de boutons.
4. Suggérer à un médecin les confrères qui prescrivent les mêmes médicaments que lui.
5. Enregistrer les mesures de 50 000 compteurs électriques toutes les 15 minutes, sur 10 ans.

Voir la réponseMasquer la réponse de l'exercice 1

1. Clé-valeur (Redis, Valkey) : on retrouve un panier par sa clé (l'identifiant de session), très vite, et une durée de vie automatique supprime les paniers abandonnés.
2. Relationnelle : des entités fortement liées (un prêt relie un élève et un matériel), des règles d'intégrité (pas de prêt d'un matériel inexistant) et des requêtes croisées (« les élèves en retard »).
3. Document : chaque produit a ses propres caractéristiques ; un document par produit, avec un sous-document caracteristiques de forme variable, évite une colonne par caractéristique possible.
4. Graphe : la question est un parcours de relations (médecin → prescrit → médicament ← prescrit ← autre médecin), la spécialité d'une base comme Neo4j.
5. Colonnes larges (Cassandra) ou une base de séries temporelles : 50 000 × 4 × 24 × 365 ≈ 1,75 milliard de mesures par an, écrites en continu et lues par compteur et par période.

Tu avais trouvé ?

Oui, j'avais bonPas encore

Exercice 2 sur 3 Vrai ou faux Réussi À revoir

Corrige chaque affirmation fausse.

1. Une base NoSQL n'a pas de schéma.
2. MongoDB ne gère pas les transactions.
3. Le modèle document évite les jointures quand les données lues ensemble sont rangées ensemble.
4. NoSQL signifie qu'on ne peut pas utiliser SQL.
5. MongoDB Community est gratuit, même pour une application commerciale.

Voir la réponseMasquer la réponse de l'exercice 2

1. Faux. Les données ont toujours une structure ; elle n'est simplement pas imposée par une table. On peut la faire vérifier par l'application (Mongoose) ou par la base (validateur $jsonSchema).
2. Faux. Une écriture sur un document est toujours atomique, et MongoDB gère les transactions ACID multi-documents depuis la version 4.0.
3. Vrai. C'est l'avantage principal du modèle : une fiche et ses lignes se lisent en une seule opération.
4. Faux. NoSQL se lit Not only SQL : ces bases ont leur propre langage, et certaines proposent même une syntaxe proche de SQL (CQL pour Cassandra).
5. Vrai, sous licence SSPL. La seule obligation forte concerne celui qui revendrait MongoDB lui-même comme service en ligne.

Tu avais trouvé ?

Oui, j'avais bonPas encore

Exercice 3 sur 3 Justifier un choix devant la commission Réussi À revoir

Ton binôme a développé l'application de réservation des salles de réunion de son entreprise d'alternance avec MongoDB : des salles, des employés, des réservations (une salle, un employé, un créneau). Un membre de la commission lui demande pourquoi il n'a pas choisi MySQL. Il répond : « Parce que MongoDB est plus moderne et plus rapide. » Que penses-tu de cette réponse ? Le choix de MongoDB est-il pertinent ici ?

Voir la réponseMasquer la réponse de l'exercice 3

La réponse ne vaut rien : « moderne » n'est pas un critère, et « plus rapide » n'est vrai que pour certaines lectures. Elle ne s'appuie sur aucune donnée de l'application.

Ici, le choix est discutable. Les données sont fortement liées (une réservation relie une salle et un employé), la règle centrale est une contrainte (pas deux réservations qui se chevauchent sur la même salle), et les requêtes sont croisées (« les salles libres jeudi à 14 h », « les réservations d'un service »). C'est le terrain du relationnel. Avec MongoDB, il faudrait garantir le non-chevauchement dans l'application, avec une transaction ou une conception particulière.

Une réponse acceptable reconnaîtrait la limite et montrerait comment elle est traitée : « Les réservations référencent la salle et l'employé ; le chevauchement est vérifié dans une transaction ; j'ai choisi MongoDB parce que l'API sert aussi un historique d'utilisation des salles, de forme variable. » Sans argument de ce type, mieux vaut MySQL.

Tu avais trouvé ?

Oui, j'avais bonPas encore