Install with Codex or Claude Copy this prompt, paste it into Codex, Claude, or another assistant, and let it review the skill page and install it for you.
A direct command skips the review prompt. Inspect the source before running it.
Compétence MongoDB — Agrégation, Indexation, Sharding et Réplica Sets
Vue d'ensemble
MongoDB est le leader des bases NoSQL orientées documents. Il stocke les données en BSON (JSON binaire), supporte les transactions ACID multi-documents (depuis 4.0), le sharding natif, les réplica sets, un pipeline d'agrégation extrêmement puissant, et les index de types variés (text, geospatial, TTL, partial, hashed).
Cette compétence couvre la modélisation de documents, le pipeline d'agrégation, l'indexation avancée, les réplica sets, le sharding, les transactions, et les bonnes pratiques de performance.
Quand l'utiliser
Activez cette compétence lorsque l'utilisateur :
Veut modéliser des données en documents NoSQL
A besoin d'écrire un pipeline d'agrégation complexe ($match, $group, $lookup, $unwind)
Demande de configurer un réplica set ou un cluster shardé
Veut optimiser des requêtes (index, explain, hint)
A besoin de géospatial (2dsphere), de recherche textuelle, ou de TTL
Migre d'un SGBD relationnel vers MongoDB
1. Modélisation des Documents
1.1 Principes fondamentaux
Contrairement au SQL, MongoDB ne normalise pas par défaut. Les choix de modélisation :
// Lire depuis le secondaire (tolérance à la stale)
db.getMongo().setReadPref("secondaryPreferred");
// Lire depuis le primary (consistance forte, défaut)
db.getMongo().setReadPref("primary");
// Tag-aware read preference
db.getMongo().setReadPref("secondary", [
{ region: "eu-west-1" }
]);
4.3 Write Concern
// Écriture acquittée par le primary seulement
db.mesures.insertOne(doc, { writeConcern: { w: 1 } });
// Écriture acquittée par majorité des membres du réplica set
db.mesures.insertOne(doc, { writeConcern: { w: "majority" } });
// Avec journalisation
db.mesures.insertOne(doc, { writeConcern: { w: "majority", j: true } });
5. Sharding (Distribution)
5.1 Architecture
mongos → [config server (3)] → shard1, shard2, shard3
5.2 Activation
// Se connecter au mongos
sh.enableSharding("eva_db");
// Configurer une clé de shard// Range-based (recommandé pour les données avec bonne cardinalité)
sh.shardCollection("eva_db.mesures", { capteur_id: 1, ts: 1 });
// Hashed (distribution uniforme garantie)
sh.shardCollection("eva_db.mesures_hash", { _id: "hashed" });
5.3 Zone-based sharding
// Associer une zone à un shard
sh.addShardTag("shard01", "EUROPE");
sh.addShardTag("shard02", "AMERICA");
// Définir la plage de clés pour la zone
sh.updateZoneKeyRange(
"eva_db.utilisateurs",
{ region: "EU" },
{ region: "EU\uFFFF" },
"EUROPE"
);
# mongodump (binaire, plus lent, plus fiable)
mongodump --uri="mongodb://localhost:27017/eva_db" --out=/backup/mongo_$(date +%Y%m%d)
mongodump --uri="mongodb://localhost:27017/eva_db" --gzip --archive=/backup/eva_db_$(date +%Y%m%d).gz
# mongorestore
mongorestore --uri="mongodb://localhost:27018/eva_db" --drop /backup/mongo_20250601/eva_db
mongorestore --uri="mongodb://localhost:27018/eva_db" --gzip --archive=/backup/eva_db_20250601.gz
# mongodump avec réplica set (--oplog pour point-in-time)
mongodump --uri="mongodb://192.168.1.10:27017/eva_db" --oplog --out=/backup/mongo_oplog
# mongotools avancé (par collection)
mongodump --uri="mongodb://localhost:27017" --collection=mesures --db=eva_db --out=/backup/mesures
Pièges Courants
Documents trop gros. MongoDB a une limite de 16 Mo par document. Un document embedded qui dépasse casse l'écriture. Solution : utiliser le pattern Bucket ou Reference.
Pas d'index sur les requêtes fréquentes. Un COLLSCAN (collection scan) sur des millions de documents ruine les performances. Vérifier avec .explain("executionStats").
$lookup sans index. La collection from du $lookup doit avoir un index sur le champ de jointure, sinon c'est un Nested Loop sans index.
Write Concern trop laxiste.w: 0 ou w: 1 sans journalisation peut perdre des écritures. Mettre w: "majority" pour les données critiques.
Sharding avec une clé de faible cardinalité. Une clé comme { statut: 1 } ne crée que 2-3 chunks max. Toujours choisir une clé avec haute cardinalité.
Oublier les indexes dans les pipelines. Chaque $match en début de pipeline doit être couvert par un index. Les stages suivants ne peuvent pas en bénéficier.
Checklist
Chaque collection a au moins un index sur le champ de filtre le plus fréquent
Les requêtes utilisent explain("executionStats") pour vérifier IXSCAN
Les documents ne dépassent pas 1 Mo (sauf cas justifié)
Les $lookup ont un index sur la collection référencée
Réplica set configuré avec au moins 3 membres
Write Concern = majority pour les données critiques
Sharding activé avec une clé à haute cardinalité
Index TTL configuré pour les données temporaires (logs, sessions)
Backup régulier avec mongodump --oplog pour restauration point-in-time