L'essentiel à connaître
Une base NoSQL ne range pas ses données en tables reliées par des jointures (des requêtes qui recollent des tables) : chaque famille choisit sa forme. MongoDB stocke des documents, Redis des paires clé-valeur en mémoire vive. Par exemple, un client et ses deux adresses tiennent dans un seul document MongoDB, {nom: "Lina", adresses: [...]}, là où le SQL demande deux tables et une jointure. S'y ajoutent les bases à colonnes larges (Cassandra) et les bases de graphes (Neo4j), qui stockent les liens entre entités.
| SQL | MongoDB |
|---|---|
| table | collection |
| ligne | document |
| colonne | champ |
| clé primaire | _id |
| jointure | document imbriqué ou $lookup |
Un document MongoDB est stocké en BSON, du JSON binaire qui connaît plus de types. Son champ _id, unique, sert de clé primaire ; s'il manque, un ObjectId est créé. Les documents d'une collection n'ont pas besoin des mêmes champs, sauf règle de validation : c'est le schéma flexible. Un filtre place l'opérateur sous le champ : db.films.find({duree: {$gt: 120}}). On imbrique ce qui se lit ensemble, mais ce qui grossit sans limite part dans une autre collection, car un document ne dépasse pas 16 Mio. Une écriture est atomique (tout ou rien) sur un document ; sur plusieurs, il faut une transaction (manuel MongoDB).
Redis associe chaque clé, comme user:1000, à une valeur : chaîne, liste, ensemble, hash (paires champ-valeur) ou ensemble trié par score, fait pour les classements. Tout tient en mémoire vive : c'est très rapide, mais limité par la mémoire disponible. Redis écrit pourtant sur disque, par instantanés (RDB) ou par un journal des écritures (AOF) rejoué au redémarrage. EXPIRE fixe la durée de vie d'une clé en secondes ; TTL lit ce qu'il en reste, ou -1 si la clé n'en a pas. Un SET qui remplace la valeur efface cette durée de vie (documentation Redis).
Passer à l'échelle horizontale, c'est ajouter des serveurs plutôt que d'en muscler un seul : MongoDB le fait par sharding, en répartissant une collection entre plusieurs serveurs. La réplication sert à autre chose : un replica set copie les mêmes données sur plusieurs serveurs ; toutes les écritures passent par le primaire et, s'il tombe, un secondaire est élu à sa place.
Piège classique : réciter le théorème CAP comme « deux propriétés sur trois ». Son auteur, Eric Brewer, juge lui-même cette formule trompeuse : le choix entre cohérence (une seule version à jour de la donnée) et disponibilité (chaque requête reçoit une réponse) ne se pose que pendant une partition, une coupure réseau entre serveurs.
Quiz : teste tes connaissances
Les questions montent en difficulté : les trois dernières sont les plus piégeuses.
Question 1 : Dans MongoDB, quel est l'équivalent d'une ligne d'une table SQL ?
Réponse : B. Une ligne devient un document, comme une table devient une collection. Le piège A, la collection, correspond donc à la table entière.
Question 2 : Sous quelle forme MongoDB stocke-t-il ses documents ?
Réponse : D. MongoDB stocke du BSON, du JSON binaire qui connaît plus de types. Le piège C confond la syntaxe que tu tapes, proche du JSON, avec le format stocké.
Question 3 : Où Redis garde-t-il ses données pendant qu'il tourne ?
Réponse : A. Redis travaille en mémoire vive, d'où sa vitesse, et peut recopier ses données sur disque. B décrit l'inverse : une base classique, qui travaille sur disque.
Question 4 : Dans MongoDB, que fait le sharding d'une collection ?
Réponse : C. Chaque serveur reçoit une partie de la collection : c'est l'échelle horizontale. Le piège A décrit la réplication, qui copie les mêmes données pour survivre à une panne sans répartir les écritures.
Question 5 : Un réseau social veut trouver vite les amis des amis d'un utilisateur. Quelle famille NoSQL est faite pour ça ?
Réponse : A. Une base de graphes stocke les liens et les parcourt directement, d'ami en ami. Le piège B : un document range une liste d'amis, mais ne suit pas les liens de proche en proche.
Question 6 : La clé panier:42 doit disparaître au bout de 30 minutes. Quelle commande Redis tapes-tu ?
Réponse : D. EXPIRE attend des secondes : $30 \times 60 = 1\,800$. A garde les minutes et effacerait le panier au bout de 30 secondes ; TTL ne fixe rien, il lit le temps restant.
Question 7 : Tu insères dans MongoDB un document sans champ _id. Que se passe-t-il ?
Réponse : B. Le champ _id est obligatoire et unique ; s'il manque, un ObjectId est généré. Le piège A vient du SQL, qui refuse une ligne sans clé primaire quand rien ne la génère.
Question 8 : Dans une collection sans règle de validation, tu insères {nom: "Lina"} puis {nom: "Hugo", age: 19}. Que se passe-t-il ?
Réponse : C. Les documents d'une collection n'ont pas besoin des mêmes champs. Le refus de A n'arrive que si tu as posé une règle de validation, ce que la question exclut.
Question 9 : Pour tenir le classement des meilleurs scores d'un jeu en ligne, quel type Redis choisis-tu ?
Réponse : A. Un ensemble trié range chaque joueur selon son score : le classement est prêt à lire. Le piège B : une liste garde l'ordre d'insertion, pas celui des scores.
Question 10 : Quelle requête renvoie les étudiants dont l'âge dépasse 18 ?
Réponse : B. Le filtre s'écrit {champ: {$gt: valeur}} : l'opérateur se place sous le champ. D inverse cet ordre, c'est l'erreur la plus tentante ; C est du SQL, que find() ne comprend pas.
Question 11 : Sur un blog, un article et ses quelques commentaires s'affichent toujours ensemble. Quel modèle MongoDB choisis-tu ?
Réponse : D. Ce qui se lit ensemble s'imbrique : une seule lecture suffit. A est le réflexe SQL ; il devient le bon choix si les commentaires grossissent sans limite, car un document ne dépasse pas 16 Mio.
Question 12 : Un serveur Redis, persistance AOF activée, redémarre après une coupure de courant. Que deviennent ses données ?
Réponse : C. L'AOF note chaque écriture et Redis le rejoue au démarrage ; avec le réglage par défaut, on perd au pire une seconde d'écritures. Le piège A oublie que Redis garde aussi une copie sur disque.
Question 13 : Un système distribué tourne sans aucune coupure réseau. Que dit le théorème CAP de son cas ?
Réponse : B. CAP n'oblige à choisir entre cohérence et disponibilité que pendant une partition ; sans coupure, un système peut offrir les deux. A et C récitent la formule « deux sur trois », que Brewer juge lui-même trompeuse.
Question 14 : Tu tapes SET s:7 "abc", puis EXPIRE s:7 600, puis SET s:7 "def". Que renvoie aussitôt TTL s:7 ?
Réponse : A. Un SET qui remplace la valeur efface la durée de vie : la clé devient permanente, d'où -1. Le piège C : seules les commandes qui modifient la valeur sans la remplacer, comme INCR, gardent le délai.
Question 15 : Hors transaction, un updateMany() modifie mille documents. Que garantit MongoDB ?
Réponse : D. L'atomicité vaut document par document : aucun n'est modifié à moitié. L'opération entière ne l'est pas, et d'autres requêtes peuvent s'y intercaler ; le piège A décrit ce que seule une transaction garantit.
Sources
Manuel MongoDB, documentation officielle : documents, modélisation, atomicité, réplication, sharding.
Documentation Redis, FAQ officielle, avec ses pages sur les types de données, la persistance, EXPIRE et TTL.
Eric Brewer, « CAP Twelve Years Later », InfoQ, 2012, d'abord paru dans la revue Computer de l'IEEE.