Le problème : la grille est trop serrée
Une base de données relationnelle classique range tout dans des tables, comme un immense chiffrier. Chaque table impose un schéma fixe : tout le monde doit avoir exactement les mêmes colonnes. Une planète a une colonne « masse », une « température », une « rayon »... et si une planète n'a pas la donnée, on laisse la case vide.
Ça marche très bien quand les objets se ressemblent tous. Mais deux situations cassent ce modèle :
- Quand chaque objet est différent : une étoile a un nombre variable de planètes, chaque planète a un nombre variable de lunes, et certains objets ont des champs que les autres n'ont pas du tout. Forcer tout ça dans une grille devient un casse-tête.
- Quand il y a des milliards d'écritures par seconde : un réseau social, une flotte de capteurs météo, des objets connectés... La grille rigide, vérifiée ligne par ligne, n'arrive plus à suivre le débit.
En réponse est née une grande famille de bases que l'on appelle NoSQL. Attention au nom : il ne veut pas dire « jamais de SQL ». Il signifie « not only SQL », c'est-à-dire « pas seulement le SQL ». L'idée est d'avoir d'autres façons de ranger les données quand la table ne convient pas.
À retenir : relationnel et NoSQL ne sont pas ennemis. Ce sont deux outils. On choisit selon la forme des données et la quantité.
Les 4 grandes familles NoSQL
Sous le mot NoSQL se cachent en réalité plusieurs façons très différentes de ranger l'information. Voici les quatre familles principales.
| Famille (exemple) | L'idée | Exemple d'usage |
|---|---|---|
| Document (MongoDB) |
Chaque enregistrement est un objet complet, souvent en JSON, qui peut contenir des listes et d'autres objets imbriqués. Pas besoin que tout le monde ait les mêmes champs. | Catalogue d'objets astronomiques où chaque étoile porte ses propres planètes. |
| Clé-valeur (Redis) |
Un gigantesque casier : on donne une clé, on récupère une valeur. Ultra rapide, très simple. | Garder en mémoire le score d'un joueur ou le panier d'un client, en une fraction de milliseconde. |
| Colonnes larges (Cassandra) |
Des tables géantes, réparties sur des centaines de machines, conçues pour avaler des écritures en continu. | Stocker les mesures de millions de capteurs météo qui écrivent sans arrêt. |
| Graphe (Neo4j) |
On range non pas les objets mais les liens entre eux : qui connaît qui, quoi mène à quoi. | Réseau social : trouver les amis des amis, ou suggérer une connaissance commune. |
Une base document, c'est un dictionnaire Python
Arrêtons-nous sur la famille document, la plus parlante pour nous. Une base document range chaque enregistrement comme un objet JSON. Voici un document qui décrit une étoile et ses planètes imbriquées :
Regarde bien cette forme : des clés entre guillemets ("nom", "planetes"), des valeurs de tout type (texte, nombre, vrai/faux), et même une liste imbriquée d'autres objets. Ça ne te rappelle rien ?
Ce document JSON, c'est exactement un dictionnaire Python, celui que tu as vu en classe. Mêmes accolades, mêmes paires clé-valeur, mêmes listes imbriquées :
Une base document, c'est un endroit qui stocke des millions de dictionnaires comme celui-là et qui sait les retrouver très vite. Tu as donc déjà la bonne intuition mentale.
Où on s'en sert vraiment
Le NoSQL n'est pas une mode : il tourne derrière une bonne partie de ce que tu utilises chaque jour, et dans la recherche scientifique.
Envie de voir à quoi ressemble une vraie requête sur une base document ? MongoDB propose un tutoriel pas à pas pour interroger des documents JSON.