Comment Profiler et Optimiser les Pipelines d'Agrégation MongoDB Lentes

Les pipelines d'agrégation MongoDB sont faciles à faire croître une étape à la fois. Un rapport commence par un $match, puis quelqu'un ajoute un $lookup, puis un $group, puis un tri, et six mois plus tard, le point de terminaison est suffisamment lent pour que tout le monde ait peur d'y toucher.

La solution commence par des preuves. Vous devez savoir quelle étape lit trop, se développe trop, trie trop ou joint trop tard. MongoDB vous offre deux outils pratiques pour ce travail : le profileur de base de données pour les opérations lentes historiques et .explain("executionStats") pour un examen approfondi d'un pipeline spécifique.

Comprendre le Profileur MongoDB

Le Profileur MongoDB enregistre les détails d'exécution des opérations de base de données, y compris les commandes find, update, delete et, surtout pour ce guide, aggregate. Il enregistre la durée d'une opération, les ressources qu'elle a consommées et les étapes qui ont le plus contribué à la latence.

Activation et Configuration des Niveaux de Profilage

Avant de pouvoir profiler, vous devez vous assurer que le profileur est actif et réglé sur un niveau qui capture les données nécessaires. Les niveaux de profilage vont de 0 (désactivé) à 2 (toutes les opérations enregistrées).

Niveau	Description
0	Le profileur est désactivé.
1	Enregistre les opérations qui prennent plus de temps que le paramètre slowOpThresholdMs.
2	Enregistre toutes les opérations exécutées sur la base de données.

Pour définir le niveau du profileur, utilisez la commande db.setProfilingLevel(). Il est généralement recommandé d'utiliser le niveau 1 ou 2 temporairement pendant les tests de performance pour éviter une E/S disque excessive.

Exemple : Réglage du Profileur au Niveau 1 (enregistrement des opérations plus lentes que 100 ms)

// Connectez-vous à votre base de données : use myDatabase
db.setProfilingLevel(1, { slowOpThresholdMs: 100 })

// Vérifiez le paramètre
db.getProfilingStatus()

Meilleure Pratique : Ne laissez jamais le profileur au niveau 2 sur un système de production indéfiniment, car l'enregistrement de chaque opération peut avoir un impact significatif sur les performances d'écriture.

Affichage des Données d'Agrégation Profilées

Les opérations profilées sont stockées dans la collection system.profile de la base de données que vous profilez. Vous pouvez interroger cette collection pour trouver les agrégations lentes récentes.

Pour trouver les requêtes d'agrégation lentes, vous filtrez les résultats où le champ op est 'aggregate' et le temps d'exécution (millis) dépasse votre seuil.

// Trouver toutes les opérations d'agrégation lentes de la dernière heure
db.system.profile.find(
  {
    op: 'aggregate',
    millis: { $gt: 100 } // Opérations plus lentes que 100 ms
  }
).sort({ ts: -1 }).limit(5).pretty()

Analyse des Détails d'Exécution du Pipeline d'Agrégation

La sortie du profileur est cruciale. Lorsque vous examinez un document d'agrégation lent, recherchez spécifiquement le planSummary et, plus important encore, le tableau stages dans le résultat.

Utilisation de la Sortie Détaillée .explain('executionStats')

Alors que le profileur capture les données historiques, l'exécution d'une agrégation avec .explain('executionStats') fournit des détails en temps réel et granulaires sur la façon dont MongoDB a exécuté le pipeline sur l'ensemble de données actuel, y compris les chronométrages par étape.

Exemple d'utilisation d'Explain :

db.collection('sales').aggregate([
  { $match: { status: 'A' } },
  { $group: { _id: '$customerId', total: { $sum: '$amount' } } }
]).explain('executionStats');

Dans la sortie, le tableau stages détaille chaque opérateur du pipeline. Pour chaque étape, recherchez :

• executionTimeMillis : Le temps passé à exécuter cette étape spécifique.
• nReturned : Le nombre de documents transmis à l'étape suivante.
• totalKeysExamined / totalDocsExamined : Métriques indiquant le coût d'E/S.

Les étapes avec un executionTimeMillis très élevé ou les étapes qui examinent beaucoup plus de documents (totalDocsExamined) qu'elles n'en renvoient sont vos principales cibles d'optimisation.

Stratégies pour Optimiser les Étapes d'Agrégation Lentes

Une fois que le profilage a identifié l'étape de goulot d'étranglement (par exemple, $match, $lookup ou les étapes de tri), vous pouvez appliquer des techniques d'optimisation ciblées.

1. Optimiser le Filtrage Initial ($match)

L'étape $match doit toujours être la première étape de votre pipeline si possible. Filtrer tôt réduit le nombre de documents que les étapes ultérieures gourmandes en ressources (comme $group ou $lookup) doivent traiter.

Le Rôle de l'Indexation : Si votre étape $match initiale est lente, il manque presque certainement un index sur les champs utilisés dans le filtre. Assurez-vous que les index couvrent les champs utilisés dans $match.

Si l'étape $match implique des champs qui ne sont pas indexés, l'étape peut effectuer une analyse complète de la collection, ce qui sera explicitement visible dans la sortie d'explication comme un totalDocsExamined élevé.

2. Utilisation Efficace de $lookup (Jointures)

L'étape $lookup est souvent le composant le plus lent. Elle effectue effectivement une anti-jointure contre une autre collection.

• Indexer la Clé Étrangère : Assurez-vous que le champ sur lequel vous effectuez la jointure dans la collection étrangère (recherchée) est indexé. Cela accélère considérablement le processus de recherche interne.
• Filtrer Avant la Recherche : Dans la mesure du possible, appliquez une étape $match avant le $lookup pour vous assurer que vous ne joignez que les documents nécessaires.

3. Traitement du Tri Coûteux ($sort)

Le tri des documents est coûteux en calcul, en particulier sur de grands ensembles de résultats. MongoDB ne peut utiliser un index pour le tri que si le préfixe de l'index correspond au filtre de la requête et si l'ordre de tri est aligné sur la définition de l'index.

Optimisation Clé pour $sort : Si une étape $sort semble coûteuse, essayez de créer un index couvrant qui correspond au filtre et à l'ordre de tri requis. Par exemple, si vous filtrez par { status: 1 } puis triez par { date: -1 }, un index sur { status: 1, date: -1 } permettrait à MongoDB de récupérer les documents dans l'ordre requis sans un tri mémoire coûteux.

4. Minimiser le Mouvement de Données avec $project

Utilisez l'étape $project de manière stratégique pour réduire la quantité de données transmises dans le pipeline. Si les étapes ultérieures n'ont besoin que de quelques champs, utilisez $project tôt dans le pipeline pour supprimer les champs et documents intégrés inutiles. Des documents plus petits signifient moins de données déplacées entre les étapes du pipeline et potentiellement une meilleure utilisation de la mémoire.

5. Éviter les Étapes Coûteuses Qui Ne Peuvent Pas Utiliser les Index

Des étapes comme $unwind peuvent créer de nombreux nouveaux documents, augmentant rapidement la surcharge de traitement. Bien que parfois nécessaire, assurez-vous que l'entrée de $unwind est aussi petite que possible. De même, les étapes qui forcent une réévaluation complète de l'ensemble de données, comme celles qui reposent sur des calculs ou des expressions complexes sans support d'index, doivent être minimisées.

Une Procédure d'Optimisation Réaliste

Imaginez un tableau de bord de support qui affiche le montant total des remboursements par client pour les 30 derniers jours. Il a commencé rapidement, puis est devenu lent après qu'une année de commandes se soit accumulée. Le pipeline semble inoffensif :

db.orders.aggregate([
  { $lookup: {
      from: "customers",
      localField: "customerId",
      foreignField: "_id",
      as: "customer"
  }},
  { $unwind: "$customer" },
  { $match: { status: "refunded", createdAt: { $gte: startDate } } },
  { $group: { _id: "$customerId", totalRefunded: { $sum: "$amount" } } },
  { $sort: { totalRefunded: -1 } },
  { $limit: 50 }
])

L'erreur coûteuse n'est pas évidente jusqu'à ce que vous regardiez l'ordre du travail. Ce pipeline joint chaque commande à un client avant de filtrer les commandes remboursées au cours des 30 derniers jours. Sur une grande collection, cela signifie que MongoDB effectue beaucoup de jointures pour des documents qui seront jetés plus tard.

Une meilleure première version filtre tôt :

db.orders.aggregate([
  { $match: { status: "refunded", createdAt: { $gte: startDate } } },
  { $group: { _id: "$customerId", totalRefunded: { $sum: "$amount" } } },
  { $sort: { totalRefunded: -1 } },
  { $limit: 50 },
  { $lookup: {
      from: "customers",
      localField: "_id",
      foreignField: "_id",
      as: "customer"
  }},
  { $unwind: "$customer" }
])

Maintenant, la jointure n'a lieu que pour les 50 meilleurs clients groupés, pas pour chaque commande de la collection. C'est le genre de changement vers lequel le profilage devrait vous guider : moins de données entrent dans les étapes coûteuses.

Pour cette version, un index utile sur orders pourrait être :

db.orders.createIndex({ status: 1, createdAt: -1, customerId: 1 })

L'index exact dépend de vos filtres réels et de vos besoins de tri, mais l'idée est stable : soutenir le $match précoce et inclure des champs qui aident le pipeline à éviter les lectures de documents supplémentaires lorsque cela est possible. Sur la collection customers, _id est déjà indexé, donc le $lookup est généralement correct. Si vous joignez sur un autre champ, indexez ce champ étranger.

Lors de l'examen de .explain("executionStats"), ne regardez pas seulement le temps d'exécution total. Recherchez le fan-out. Si une étape renvoie 500 documents et la suivante en renvoie 2 millions à cause de $unwind, vous avez trouvé l'étape qui a changé la forme du problème. Si totalDocsExamined est bien plus grand que nReturned, l'index n'est pas assez sélectif ou n'est pas utilisé comme vous le pensiez. Si un tri apparaît tard dans le pipeline après un grand groupe, demandez-vous si vous pouvez limiter plus tôt ou pré-agréger dans une collection séparée pour les tableaux de bord qui n'ont pas besoin d'une fraîcheur à la seconde près.

Surveillez également le comportement de la mémoire. $group, $sort, $setWindowFields et certains modèles $lookup peuvent nécessiter beaucoup de mémoire. allowDiskUse: true peut empêcher un pipeline d'échouer lorsqu'il dépasse les limites de mémoire, mais ce n'est pas une solution de performance en soi. Le débordement sur disque signifie généralement que le pipeline fait trop de travail à la fois. Cela peut être acceptable pour un rapport de nuit. C'est rarement acceptable pour un point de terminaison d'API orienté utilisateur qui s'exécute à chaque chargement de page.

Une habitude pratique consiste à enregistrer le pipeline lent, la sortie d'explication et les index ensemble dans les notes d'incident. La personne suivante ne devrait pas avoir à redécouvrir pourquoi un index existe ou pourquoi $lookup a été déplacé après $limit. L'optimisation de l'agrégation est beaucoup plus facile lorsque le raisonnement survit à la session de débogage.

Index Qui Aident les Agrégations et Index Qui Ne Font Que Sembler Utiles

Les pipelines d'agrégation exposent souvent des index composites faibles. Supposons que votre API filtre par locataire et date, puis regroupe par statut :

db.orders.aggregate([
  { $match: { tenantId, createdAt: { $gte: start, $lt: end } } },
  { $group: { _id: "$status", count: { $sum: 1 } } }
])

Un index sur { createdAt: -1 } peut aider un peu, mais dans un système multi-locataire, il peut encore analyser une large plage de dates pour chaque locataire. Un index sur { tenantId: 1, createdAt: -1 } correspond généralement mieux au modèle d'accès car il se limite d'abord au locataire, puis parcourt la plage de dates. Si la plupart des requêtes incluent également le statut, testez si { tenantId: 1, status: 1, createdAt: -1 } est meilleur pour cette charge de travail. Ne devinez pas. Exécutez explain, comparez keysExamined, docsExamined et le temps écoulé sur des données proches de la production.

Soyez prudent avec les champs de faible cardinalité au début d'un index. Un index commençant par { status: 1 } peut ne pas être sélectif si presque toutes les commandes sont complete. Il peut toujours être utile lorsqu'il est combiné avec d'autres champs, mais il doit refléter la forme de la requête. Le meilleur index n'est pas celui qui a le plus de champs ; c'est celui qui réduit l'espace de recherche tôt sans créer de surcharge d'écriture inutile.

Quand Arrêter d'Optimiser le Pipeline

Parfois, la bonne solution n'est pas une autre réécriture du pipeline. Si un tableau de bord exécute la même agrégation coûteuse chaque fois qu'un gestionnaire ouvre la page, la pré-agrégation peut être plus propre. Un travail planifié peut écrire des totaux horaires dans une collection order_stats_hourly, et le tableau de bord peut lire quelques petits documents. Vous échangez la fraîcheur contre une latence prévisible.

Cet échange est souvent acceptable lorsque des humains lisent des tendances. Il est moins acceptable lorsque le pipeline alimente une décision de paiement ou une règle de fraude. Rendez explicite l'exigence de fraîcheur. "Dans les cinq minutes" ouvre la pré-agrégation et la mise en cache. "Doit inclure la dernière commande confirmée" vous maintient probablement plus près des lectures en direct avec un comportement d'écriture et de lecture plus fort.

L'optimisation de l'agrégation ne consiste pas à rendre chaque pipeline intelligent. Il s'agit de supprimer le travail que la base de données ne devrait pas avoir à faire sur le chemin de la requête.

Résumé et Prochaines Étapes

Profiler et optimiser les pipelines d'agrégation MongoDB nécessite une approche systématique et fondée sur des preuves. En tirant parti du profileur intégré (db.setProfilingLevel) et en exécutant des statistiques d'exécution détaillées (.explain('executionStats')), vous pouvez transformer des problèmes de performance complexes en étapes résolubles.

Le flux de travail d'optimisation est :

1. Activer le Profilage : Définissez le niveau 1 et un slowOpThresholdMs.
2. Exécuter la Requête : Exécutez le pipeline d'agrégation lent.
3. Analyser les Données Profilées : Identifiez l'étape spécifique consommant le plus de temps.
4. Expliquer en Détail : Utilisez .explain('executionStats') sur le pipeline problématique.
5. Optimiser : Créez les index nécessaires, réorganisez les étapes (filtrez d'abord) et simplifiez les données transmises aux opérateurs coûteux.

Une surveillance continue garantit que les nouvelles fonctionnalités ajoutées ou l'augmentation du volume de données ne réintroduisent pas les problèmes de performance que vous avez résolus.