Plan de dimensionnement : du jeu de réplicas au cluster partitionné
Les apprenants élaboreront un plan de capacité et choisiront une clé de partition prenant en charge la répartition des lectures et des écritures de l’application sans créer de points chauds.
Plan de dimensionnement : du jeu de réplicas au cluster partitionné est une leçon MongoDB Academy gratuite sur CoddyKit. Ceci est la leçon 3 sur 4. Tu peux lire la leçon complète ci-dessous gratuitement — puis la pratiquer en direct dans le navigateur avec un éditeur de code intégré et un tuteur IA 24/7. Elle fait partie du parcours d'apprentissage MongoDB Academy, et ta progression se synchronise sur le web et l'application CoddyKit. Le cours MongoDB Academy comprend 4 leçons au total.
Quand devez-vous mettre à l’échelle ?
La plupart des applications commencent avec un seul ensemble de réplicas MongoDB et n’ont jamais besoin d’être partitionnées. Le partitionnement ajoute une complexité importante et doit être le dernier recours, et non le premier choix. Envisagez le partitionnement lorsque : le volume de données dépasse ce qu’un seul ensemble de réplicas peut stocker à un coût raisonnable ; le débit d’écriture dépasse ce qu’un seul nœud primaire peut gérer ; ou certaines collections sont trop volumineuses pour être indexées efficacement en mémoire. Avant de partitionner, essayez toujours la mise à l’échelle verticale (instances plus grandes) et la mise à l’échelle des lectures (répartir les lectures sur les nœuds secondaires).
Phase 1 : ensemble de réplicas unique
Le point de départ standard de tout déploiement MongoDB est un ensemble de réplicas à 3 membres : un nœud primaire et deux nœuds secondaires. Cela assure une haute disponibilité (basculement automatique en cas de défaillance du primaire), la durabilité des données (écritures répliquées sur plusieurs membres) et la mise à l’échelle des lectures (envoyer les lectures aux nœuds secondaires pour les charges de travail de rapport). Pour notre projet final de commerce en ligne, un cluster Atlas M30 à 3 membres gère confortablement plusieurs millions de commandes quotidiennes. Commencez par cette configuration et mesurez les performances avant d’envisager le partitionnement.
// Capacity metrics to monitor on a single replica set
// (via Atlas Metrics or db.serverStatus())
const metricsToWatch = [
'connections.current', // approaching maxIncomingConnections?
'opcounters.insert', // write ops/sec approaching primary limit?
'mem.resident', // working set fitting in RAM?
'wiredTiger.cache.bytesCurrentlyInCache', // cache utilisation
'replicationLag' // secondaries keeping up?
]Phase 2 : mise à l’échelle des lectures avec les lectures secondaires
Avant de partitionner, augmentez la capacité de lecture en acheminant les requêtes d’analyse et de rapport vers les nœuds secondaires à l’aide de readPreference: 'secondary'. Cela décharge le nœud primaire de la pression des lectures sans ajouter de complexité opérationnelle. Dans Atlas, les Analytics Nodes sont des nœuds secondaires dédiés (jamais élus comme nœuds primaires) qui absorbent les charges importantes de traitement des agrégations sans affecter les performances du primaire. Cette approche fonctionne bien jusqu’à ce que le débit d’écriture lui-même devienne le goulot d’étranglement.
// Route heavy analytics to secondary nodes
const { MongoClient } = require('mongodb')
const client = new MongoClient(process.env.ATLAS_URI, {
readPreference: 'secondary' // global default for this client
})
// Or per-operation
const result = await db.collection('orders').aggregate(
[ /* heavy reporting pipeline */ ],
{ readPreference: 'secondary' } // does not compete with primary writes
)Phase 3 : quand partitionner
Utilisez le partitionnement lorsque la mise à l’échelle verticale ne suffit plus : le débit d’écriture du nœud primaire est saturé même avec l’instance la plus grande disponible ; l’ensemble de travail d’une collection (données + index activement utilisés) ne tient pas dans la RAM du cluster, même avec le niveau le plus élevé ; ou une collection donnée est trop volumineuse pour être stockée sur le disque d’un seul cluster. En pratique, la plupart des applications atteignent les limites de RAM avant celles du débit d’écriture : surveillez chaque mois l’utilisation du cache WiredTiger et la taille de l’ensemble de travail.
// Indicator: working set exceeding cache
// db.serverStatus().wiredTiger.cache
const cache = db.serverStatus().wiredTiger.cache
const cacheHitRatio = 1 - (cache['pages read into cache'] / cache['pages requested from the cache'])
console.log('Cache hit ratio:', (cacheHitRatio * 100).toFixed(1) + '%')
// Below 95%: working set is not fitting in cache — time to scaleChoisir la ou les collections à partitionner
Ne partitionnez que la ou les collections à l’origine du goulot d’étranglement. Dans notre plateforme de commerce en ligne, la collection orders augmentera le plus rapidement et générera le plus grand volume d’écritures. La collection products peut être volumineuse, mais elle reçoit principalement des lectures qui peuvent être traitées par les nœuds secondaires. Partitionner orders tout en laissant products non partitionnée (sur chaque fragment en tant que collection diffusée) est une approche courante et pratique.
// Enable sharding on the database
sh.enableSharding('ecommerce')
// Shard the orders collection
sh.shardCollection('ecommerce.orders', { userId: 'hashed' })
// Verify shard distribution
sh.status()
db.orders.getShardDistribution()Choix de la clé de partitionnement pour orders
La clé de partitionnement de orders doit répartir les écritures uniformément entre les fragments et prendre en charge les schémas de requête les plus courants. Utiliser userId comme clé de partitionnement hachée répartit uniformément les écritures, car les identifiants utilisateur ont une forte cardinalité et sont aléatoires. Inconvénient : les requêtes limitées à un seul utilisateur sont distribuées à tous les fragments. Une clé de partitionnement par plage sur { userId: 1, _id: 1 } conserve les commandes d’un utilisateur sur le même fragment (ce qui accélère les requêtes propres à cet utilisateur), mais présente un risque de surcharge de certains fragments si quelques utilisateurs génèrent la majorité de l’activité.
// Option 1: Hashed shard key — uniform write distribution
sh.shardCollection('ecommerce.orders', { userId: 'hashed' })
// Pros: even distribution
// Cons: user order history queries scatter across all shards
// Option 2: Compound ranged shard key — user orders co-located
sh.shardCollection('ecommerce.orders', { userId: 1, _id: 1 })
// Pros: all orders for a user are on one shard — fast history queries
// Cons: may create hot shards if a few users dominate trafficPartitionnement par zones pour la résidence des données
Si la plateforme de commerce en ligne dessert plusieurs régions soumises à des exigences de résidence des données (les données de l’EU doivent rester en Europe), utilisez le partitionnement par zones pour affecter des documents à des fragments précis en fonction des plages de clés de partitionnement. Créez une zone pour chaque région, affectez les fragments aux zones et définissez les plages de clés de partitionnement correspondant à chaque zone. Les données des utilisateurs de l’EU restent sur les fragments de la région européenne, ce qui permet de respecter le GDPR sans gérer de clusters distincts.
// Zone sharding for regional data residency
// Assign shards to zones
sh.addShardToZone('shard0001', 'EU')
sh.addShardToZone('shard0002', 'US')
sh.addShardToZone('shard0003', 'APAC')
// Define shard key ranges for each region
// (Assuming userId prefix encodes region: 'EU-', 'US-', 'APAC-')
sh.updateZoneKeyRange('ecommerce.orders',
{ userId: 'EU-' }, { userId: 'EU-zzz' }, 'EU'
)
sh.updateZoneKeyRange('ecommerce.orders',
{ userId: 'US-' }, { userId: 'US-zzz' }, 'US'
)mongos et le serveur de configuration
Dans un cluster partitionné, les instances mongos constituent la couche de routage des requêtes. Les pilotes de l’application se connectent à mongos, et non directement aux fragments. mongos lit l’ensemble de réplicas du serveur de configuration (qui contient les métadonnées du cluster, les cartes des blocs et les affectations de zones) afin de déterminer quel ou quels fragments contiennent les données correspondant à chaque requête. Déployez toujours au moins deux instances mongos pour assurer une haute disponibilité : elles sont sans état et peuvent être redémarrées sans perte de données.
Requêtes ciblées ou distribuées à tous les fragments
Dans un cluster partitionné, une requête ciblée inclut la clé de partitionnement dans son filtre : mongos l’achemine vers un seul fragment. Une requête distribuée à tous les fragments n’inclut pas la clé de partitionnement : mongos doit la diffuser à tous les fragments et fusionner les résultats. Ces requêtes sont coûteuses et doivent être évitées dans les chemins critiques. Concevez votre clé de partitionnement et vos schémas de requête de façon que les requêtes les plus fréquentes incluent le champ de la clé de partitionnement.
// TARGETED: includes shard key (userId) — goes to one shard only
db.orders.find({ userId: 'user-123', status: 'pending' })
// SCATTER-GATHER: no shard key — hits ALL shards (expensive!)
db.orders.find({ status: 'pending', total: { $gt: 100 } })
// Verify with explain in sharded cluster
db.orders.find({ userId: 'user-123' }).explain('executionStats')
// Look for 'SINGLE_SHARD' vs 'SHARD_MERGE' in the winning planPlanification de la capacité et surveillance
Construisez un modèle de capacité : estimez la croissance quotidienne du nombre de documents × la taille moyenne d’un document afin de prévoir le moment où chaque fragment sera plein. Dans Atlas, utilisez la mise à l’échelle automatique du cluster pour ajouter automatiquement du stockage ou mettre à niveau les niveaux d’instance lorsque des seuils d’utilisation sont franchis. Configurez des alertes Atlas pour les situations suivantes : utilisation du disque supérieure à 80 %, utilisation du processeur supérieure à 70 % pendant plus d’une heure et retard de réplication supérieur à 10 secondes. Une surveillance proactive évite les interventions précipitées à 3 heures du matin.
// Capacity projection script
const avgDocBytes = 1024 // 1 KB average order document
const dailyOrders = 50000
const retentionDays = 365 * 3 // 3 years
const totalOrders = dailyOrders * retentionDays
const totalBytes = totalOrders * avgDocBytes
const totalGB = totalBytes / 1e9
console.log('Projected orders:', totalOrders.toLocaleString())
console.log('Projected storage:', totalGB.toFixed(0), 'GB')
// Add 3x for indexes + WiredTiger overhead
console.log('Recommended disk:', (totalGB * 3).toFixed(0), 'GB')Clusters partitionnés Atlas ou autogérés
Atlas gère automatiquement toute l’infrastructure de partitionnement : mise à disposition des routeurs mongos, des serveurs de configuration et des ensembles de réplicas des fragments ; équilibrage des blocs ; et mise à jour corrective du cluster. Pour les déploiements autogérés, chaque composant doit être mis à disposition, surveillé et entretenu manuellement, ce qui représente une charge opérationnelle importante. Pour la plupart des équipes, les économies opérationnelles du partitionnement Atlas justifient le surcoût par rapport à une solution autogérée, sauf si des exigences de conformité imposent un déploiement sur site.
Vérification rapide
Vérifiez votre compréhension des concepts MongoDB et NoSQL Databases abordés dans cette leçon.
Récapitulatif de la leçon
Dans cette leçon, vous avez appris que : vous devez effectuer une mise à l’échelle verticale et tirer parti des lectures secondaires avant d’utiliser le partitionnement — le partitionnement ajoute une complexité importante dont la plupart des applications n’ont jamais besoin ; le choix de la clé de partitionnement doit équilibrer la répartition des écritures (clé hachée) et le ciblage des requêtes (clé par plage) ; et les requêtes ciblées qui incluent la clé de partitionnement sont envoyées à un seul fragment, tandis que les requêtes distribuées à tous les fragments les sollicitent tous et sont coûteuses. La prochaine étape consiste à terminer le projet final avec le renforcement de la sécurité et la liste de contrôle de préparation à la production.
Apprends JavaScript avec un tuteur IA — gratuit
Écris et exécute du vrai code dans ton navigateur, obtiens de l'aide instantanée d'un tuteur IA disponible 24h/24, et reprends là où tu t'es arrêté sur le web ou dans l'app.
- Cours
- 30
- Leçons
- 120
Questions Fréquemment Posées
La leçon « Plan de dimensionnement : du jeu de réplicas au cluster partitionné » est-elle gratuite ?
Oui — le texte complet de « Plan de dimensionnement : du jeu de réplicas au cluster partitionné » est gratuit à lire ici sur le web. Pour la pratiquer de manière interactive (un éditeur de code intégré et un tuteur IA 24/7) et déverrouiller le reste du cours MongoDB Academy, passe à CoddyKit PRO. Le cours MongoDB Academy comprend 4 leçons au total.
Qu'est-ce que j'apprendrai dans « Plan de dimensionnement : du jeu de réplicas au cluster partitionné » ?
Les apprenants élaboreront un plan de capacité et choisiront une clé de partition prenant en charge la répartition des lectures et des écritures de l’application sans créer de points chauds. Tu pratiques MongoDB Academy avec du code pratique que tu exécutes directement dans le navigateur, et un tuteur IA 24/7 répond à tes questions au fur et à mesure que tu avances dans la leçon.
Dois-je avoir de l'expérience pour commencer MongoDB Academy ?
Aucune expérience préalable n'est requise. MongoDB Academy sur CoddyKit est structuré pour les débutants jusqu'aux apprenants avancés, donc tu peux commencer ici ou depuis le début et avancer à ton rythme. Ceci est la leçon 3 sur 4.
Combien de temps prend la leçon « Plan de dimensionnement : du jeu de réplicas au cluster partitionné » ?
La plupart des leçons CoddyKit prennent environ 5–10 minutes. Chacune est courte et interactive, tu progresses régulièrement et tu repiques exactement où tu t'es arrêté sur le web et l'app.
Peux-tu écrire et exécuter du code dans cette leçon MongoDB Academy ?
Oui. Chaque leçon MongoDB Academy inclut un éditeur de code intégré, tu écris et exécutes du vrai code directement dans ton navigateur et tu reçois des retours IA instantanés — aucune configuration locale requise.
Toutes les leçons de ce cours
- Analyse des exigences et conception du schéma
- Stratégie d’indexation et validation du planificateur de requêtes
- Plan de dimensionnement : du jeu de réplicas au cluster partitionné
- Renforcement de la sécurité et liste de contrôle de mise en production