Performances des Requêtes vs. Mises à Jour : Choisir des Opérations d'Écriture Efficaces

Les performances d'écriture de MongoDB ne concernent pas seulement la vitesse à laquelle le serveur peut accepter les données. Elles concernent la forme de l'écriture, les index qu'elle doit maintenir, le document qu'elle touche, l'accusé de réception que le client attend, et si le même enregistrement est martelé par de nombreuses requêtes à la fois.

Les lectures et les écritures échouent de différentes manières. Une mauvaise lecture scanne souvent trop de données. Une mauvaise mise à jour peut d'abord scanner, puis réécrire un document en croissance, mettre à jour plusieurs index, attendre la réplication, et bloquer d'autres travaux sur le même enregistrement chaud. C'est pourquoi choisir la bonne opération d'écriture est important.

Le Compromis Fondamental : Vitesse de Lecture vs. Durabilité d'Écriture

Dans tout système de base de données, il existe une tension inhérente entre la garantie de la sécurité des données (durabilité) et l'obtention d'une vitesse de transaction élevée (débit). MongoDB gère cela via deux mécanismes principaux pertinents pour les performances d'écriture : les Préoccupations d'Écriture et le type d'opération d'écriture lui-même (par exemple, les insertions simples par rapport aux mises à jour complexes).

Comprendre les Préoccupations d'Écriture

Les Préoccupations d'Écriture définissent le niveau d'accusé de réception que l'application exige de MongoDB avant de considérer une opération d'écriture comme réussie. Une préoccupation d'écriture plus stricte augmente la durabilité mais réduit souvent le débit d'écriture car le client doit attendre plus longtemps la confirmation.

Niveau de Préoccupation d'Écriture	Description	Durabilité	Impact sur la Latence/Débit
`0` (Tirer et Oublier)	Aucun accusé de réception requis.	La plus faible	Débit le plus élevé, Latence la plus faible
`majority`	Écriture accusée par la majorité des membres du jeu de réplicas.	Élevée	Latence modérée, Bon débit
`w: 'all'`	Écriture accusée par tous les membres du jeu de réplicas.	La plus élevée	Latence la plus élevée, Débit le plus faible

Exemple Pratique : Définir la Préoccupation d'Écriture

Lors de l'insertion de documents, vous définissez la préoccupation d'écriture au niveau du pilote :

const options = { writeConcern: { w: 'majority', wtimeout: 5000 } };

db.collection('logs').insertOne({ message: "Événement Critique" }, options, (err, result) => {
  // L'opération se termine seulement après confirmation majoritaire
});

Meilleure Pratique : Pour la journalisation à volume élevé ou les données non critiques où une perte occasionnelle est tolérable, l'utilisation de w: 0 peut réduire la latence d'accusé de réception, au risque d'une perte de données lors d'un arrêt non propre.

Caractéristiques de Performance des Requêtes

Les lectures (Requêtes) n'affectent généralement pas la durabilité intrinsèquement, se concentrant uniquement sur la vitesse de récupération. La performance des requêtes est principalement régie par :

Indexation : Une indexation appropriée est le facteur le plus important. Une requête utilisant un index surpassera presque toujours un scan de collection.
Taille de Récupération des Données : Récupérer moins de champs ou des documents plus petits accélère le transfert réseau et l'utilisation de la mémoire.
Complexité de la Requête : Les pipelines d'agrégation, en particulier ceux impliquant $lookup (jointures) ou des opérations $group lourdes, nécessitent un temps CPU et une mémoire importants, impactant la réactivité globale du serveur.

Exemple : Structure de Requête Efficace

Favorisez toujours les champs indexés dans le prédicat de la requête :

// Supposons que le champ 'status' est indexé
db.items.find({ status: 'actif', lastUpdated: { $gt: hier } }).limit(100);

Implications de Performance des Mises à Jour

Les mises à jour sont fondamentalement des opérations d'écriture et sont soumises aux mêmes considérations de durabilité que les insertions. Cependant, les mises à jour introduisent des complexités basées sur le fait qu'elles modifient la structure ou la taille du document.

Mises à Jour sur Place vs. Réécritures

MongoDB tente d'effectuer les mises à jour sur place chaque fois que possible. Une mise à jour sur place est beaucoup plus rapide car l'emplacement du document sur le disque ne change pas. Cela est possible si :

Les champs mis à jour ne font pas dépasser au document son espace de stockage alloué actuel.
L'opération de mise à jour ne modifie pas la taille du document d'une manière qui nécessite une restructuration interne.

Si une mise à jour fait grossir le document au-delà de son espace alloué actuel, MongoDB doit réécrire le document à un nouvel emplacement sur le disque. Cette opération de réécriture génère une surcharge d'E/S significative et verrouille le document pour une durée plus longue, dégradant sévèrement les performances, en particulier dans les scénarios à forte concurrence.

Minimiser les Réécritures

Pour optimiser les mises à jour :

Pré-allouer de l'Espace : Si vous savez que certains champs vont croître de manière significative (par exemple, ajouter des éléments à un tableau), envisagez d'initialiser ces champs avec des données factices pour réserver suffisamment d'espace initialement.
Éviter les Sur-Mises à Jour : Si les documents sont fréquemment redimensionnés, envisagez de restructurer le schéma pour utiliser des documents séparés plus petits liés par des références.

Modificateurs de Mise à Jour et Vitesse

Différents opérateurs de mise à jour ont des coûts de performance différents :

Opérations Atomiques ($set, $inc) : Celles-ci sont généralement rapides si elles aboutissent à une mise à jour sur place.
Manipulation de Tableaux ($push, $addToSet) : Celles-ci peuvent être particulièrement lentes si elles provoquent à plusieurs reprises des réécritures de documents en raison de la croissance du tableau.
Remplacement de Document (replaceOne) : Remplacer le document entier (replaceOne ou en utilisant { upsert: true, multi: false } avec findAndModify qui écrase tout le document) force une réécriture et doit être utilisé avec parcimonie, car cela invalide tous les index existants pointant vers l'ancien emplacement qui pourraient nécessiter une mise à jour.

Comparaison des Performances des Requêtes vs. Écritures

Bien que les requêtes soient généralement plus rapides que les écritures car elles évitent la surcharge de durabilité, la comparaison est nuancée :

Type d'Opération	Pilote Principal de Performance	Surcharge de Durabilité	Pire Scénario
Requête (Lecture)	Efficacité de l'index, Latence réseau.	Aucune (sauf lecture depuis un réplica obsolète).	Scan complet de la collection dû à un index manquant.
Mise à Jour (Écriture)	Confirmation de la Préoccupation d'Écriture, Sur place vs. Réécriture.	Élevée (dépend du paramètre `w`).	Réécritures fréquentes de documents sur le cluster.

Conseil Actionnable : Si votre application est limitée par les écritures, vérifiez d'abord les filtres de mise à jour, les documents chauds, la croissance des documents et la maintenance des index. La préoccupation d'écriture est un levier utile, mais abaisser la durabilité doit être une décision produit, pas un réflexe.

Choisir la Forme de l'Écriture, Pas Seulement la Préoccupation d'Écriture

La préoccupation d'écriture contrôle quand MongoDB dit au client qu'une écriture est accusée. Elle ne corrige pas un modèle de mise à jour inefficace. Deux écritures peuvent utiliser le même paramètre w: "majority" et avoir pourtant un coût très différent car l'une touche un petit champ et l'autre continue de faire croître un grand tableau dans un document chaud.

Un exemple courant est un document utilisateur avec un tableau events qui ne cesse de croître :

db.users.updateOne(
  { _id: userId },
  { $push: { events: { type: "connexion", at: new Date() } } }
)

C'est pratique au début. Plus tard, le document utilisateur devient volumineux, chaque connexion modifie le même document, et les mises à jour commencent à entrer en concurrence avec les lectures du profil utilisateur. Un meilleur modèle est souvent une collection user_events séparée :

db.user_events.insertOne({
  userId,
  type: "connexion",
  at: new Date()
})

Maintenant, le document de profil reste petit, et les écritures d'événements ajoutent de nouveaux documents au lieu de modifier à plusieurs reprises un document en croissance. Vous pouvez indexer { userId: 1, at: -1 } pour les écrans d'activité récente et expirer les anciens événements avec un index TTL si les données ne sont pas permanentes.

Un autre modèle est celui des compteurs. Si chaque requête incrémente un document global, ce document devient un point chaud d'écriture :

db.metrics.updateOne(
  { _id: "page_views" },
  { $inc: { count: 1 } },
  { upsert: true }
)

Pour un trafic faible, cela va bien. Sous un trafic élevé, utilisez des compteurs groupés comme un document par minute, tenant, route ou clé de shard. Vous échangez un peu d'agrégation au moment de la lecture contre une bien meilleure distribution des écritures.

db.metrics.updateOne(
  { metric: "page_views", minute: "2026-05-24T10:31Z" },
  { $inc: { count: 1 } },
  { upsert: true }
)

Les upserts méritent une attention particulière. Un upsert doit d'abord trouver un document correspondant. Si le filtre n'est pas indexé, un chemin d'écriture se transforme en un scan de lecture plus une écriture. Pour un rappel de paiement idempotent, par exemple, vous voulez une clé indexée unique :

db.payment_events.createIndex({ providerEventId: 1 }, { unique: true })

db.payment_events.updateOne(
  { providerEventId },
  { $setOnInsert: { providerEventId, receivedAt: new Date(), payload } },
  { upsert: true }
)

Cela permet aux tentatives d'être sûres sans scanner la collection ni créer d'enregistrements en double. Cela donne également à l'application un moyen propre de gérer les conflits de clés en double.

Les écritures en masse sont un autre levier utile. Si vous importez 10 000 changements de statut, un aller-retour réseau par mise à jour est généralement un gaspillage. bulkWrite vous permet d'envoyer un lot, et les lots non ordonnés peuvent continuer après des échecs individuels lorsque cela est acceptable pour le travail.

db.orders.bulkWrite(
  updates.map(({ id, status }) => ({
    updateOne: {
      filter: { _id: id },
      update: { $set: { status, updatedAt: new Date() } }
    }
  })),
  { ordered: false }
)

Ne relâchez pas aveuglément la préoccupation d'écriture pour gagner en vitesse. Passer de majority à w: 1 peut réduire la latence, mais cela change aussi ce qui peut se produire lors d'un basculement. Passer à w: 0 signifie que le client peut ne pas savoir si l'écriture a échoué du tout. Cela peut être acceptable pour de la télémétrie jetable. C'est un mauvais choix pour les commandes, les modifications de compte ou tout ce qu'un utilisateur s'attend à voir confirmé.

La meilleure question est : pouvez-vous rendre l'écriture plus petite, plus ciblée, moins disputée et plus facile à réessayer ? Utilisez $set, $inc, $unset et $setOnInsert au lieu de remplacer des documents entiers lorsqu'un seul champ a changé. Gardez les tableaux non bornés hors des documents qui sont mis à jour fréquemment. Ajoutez des index pour les filtres de mise à jour, pas seulement pour les filtres de lecture. Concevez les tentatives autour de clés uniques afin que les requêtes en double ne créent pas d'effets en double.

Mesurer les Performances d'Écriture Sans Se Tromper

Un benchmark qui insère de minuscules documents dans une base de données locale vide ne vous dit pas grand-chose sur les performances d'écriture en production. Les écritures réelles sont en concurrence avec les index, la réplication, la journalisation, le travail en arrière-plan et d'autres clients. Si vous testez un chemin à forte mise à jour, exécutez le test contre des documents qui ressemblent à de vrais documents et des index qui correspondent à la production.

Suivez au moins quatre nombres : la latence de l'application, la durée de la commande MongoDB, le retard de réplication, et les erreurs d'écriture ou les dépassements de délai. Un changement qui améliore la latence moyenne mais crée un retard de réplication peut simplement déplacer la douleur vers les secondaires. Un changement qui semble rapide avec w: 1 peut ne pas répondre à l'exigence de durabilité dont le produit a réellement besoin.

Les index font partie du coût d'écriture. Chaque insertion ou mise à jour qui modifie un champ indexé doit mettre à jour les entrées d'index pertinentes. Cela ne signifie pas que les index sont mauvais ; cela signifie que les index inutilisés ne sont pas gratuits. Si une collection a de nombreux index créés au cours d'années de travail sur des fonctionnalités, examinez s'ils prennent encore en charge de vraies requêtes. Supprimer un index inutilisé peut améliorer la vitesse d'écriture et réduire le stockage, mais faites-le avec précaution après avoir vérifié les journaux de requêtes et testé les plans de restauration.

Choisir des Opérations pour les Tâches Courantes de l'Application

Pour un formulaire d'édition de profil, utilisez $set sur les champs que l'utilisateur a modifiés. Ne remplacez pas tout le document utilisateur à partir d'une copie client obsolète, car cela peut effacer accidentellement des champs ajoutés par un autre processus.

Pour les réservations d'inventaire, utilisez une mise à jour conditionnelle afin que la vérification et le changement se produisent ensemble :

db.inventory.updateOne(
  { sku, available: { $gte: quantity } },
  { $inc: { available: -quantity, reserved: quantity } }
)

Ensuite, vérifiez matchedCount et modifiedCount. Cela évite la condition de concurrence où deux clients lisent la même quantité disponible et décident tous les deux qu'ils peuvent la réserver.

Pour les suppressions logiques, $set un champ deletedAt et assurez-vous que les lectures normales le filtrent. Si vous interrogez fréquemment des enregistrements actifs, incluez ce champ dans les index pertinents. Pour les suppressions physiques en masse, supprimez par lots afin de ne pas créer d'opérations de longue durée qui perturbent le reste de la charge de travail.

Pour les migrations en arrière-plan, préférez les petits lots avec des points de contrôle. Un seul updateMany massif peut être simple, mais il peut créer une pression de réplication et rendre la restauration plus difficile. Une migration qui met à jour 1 000 ou 5 000 documents à la fois, enregistre la progression et dort lorsque le retard de réplication augmente est moins dramatique et généralement plus sûre.

Le modèle est le même dans tous ces cas : faites faire à la base de données un changement atomique précis, rendez les tentatives sûres et évitez de faire croître indéfiniment les documents chauds.

Une Note Pratique de Conclusion : Stratégie d'Optimisation des Performances

Choisir des opérations d'écriture efficaces dans MongoDB repose sur l'alignement des besoins de l'application avec les capacités de la base de données. Des exigences de durabilité élevées (utilisant w: 'all') sont intrinsèquement plus lentes que des exigences de débit élevé (utilisant w: 0). Simultanément, les développeurs doivent se prémunir contre la dégradation des performances causée par le fait de forcer les documents à se réécrire sur le disque en raison de mises à jour qui dépassent l'espace de stockage alloué.

En sélectionnant soigneusement les préoccupations d'écriture en fonction de la criticité des données et en structurant les mises à jour pour favoriser les modifications sur place, vous pouvez équilibrer efficacement une persistance robuste des données avec les exigences de concurrence élevée des applications modernes.