Diagnostic et résolution des requêtes lentes dans MongoDB : Un guide pratique

MongoDB est réputé pour sa flexibilité et son évolutivité, ce qui en fait un choix de premier ordre pour les applications modernes. Cependant, à mesure que le volume de données augmente ou que les modèles d'application évoluent, les requêtes peuvent ralentir, impactant l'expérience utilisateur et la réactivité de l'application. Les requêtes lentes sont l'un des obstacles opérationnels les plus courants dans la gestion d'un déploiement MongoDB.

Ce guide propose une approche structurée pour identifier, analyser et résoudre les goulots d'étranglement de performance causés par des requêtes inefficaces. Nous utiliserons les outils intégrés de MongoDB, tels que explain(), et nous nous pencherons sur le rôle essentiel d'une indexation appropriée pour atteindre des performances optimales.

Comprendre pourquoi les requêtes deviennent lentes

Avant de plonger dans le diagnostic, il est crucial de comprendre les coupables typiques des requêtes lentes dans MongoDB :

1. Index manquants ou inefficaces : La cause la plus fréquente. Sans index, MongoDB doit effectuer un Scan de Collection (examiner chaque document) au lieu de rechercher rapidement les données requises.
2. Complexité des requêtes : Les opérations qui nécessitent des étapes d'agrégation, de grands tris ou des recherches inter-collections peuvent être intrinsèquement lentes si elles ne sont pas optimisées.
3. Volume de données : Même les requêtes indexées peuvent ralentir si l'ensemble de données est massif et que la requête doit encore traiter des millions de documents avant le filtrage.
4. Contraintes matérielles : Une RAM insuffisante (entraînant un échange intensif sur disque) ou une I/O disque lente peuvent dégrader les performances de toutes les opérations.

Étape 1 : Identification des requêtes lentes à l'aide du profilage

La première étape de la résolution est l'identification. Le profileur de base de données de MongoDB enregistre les temps d'exécution des opérations de base de données, vous permettant de localiser précisément les requêtes qui causent des problèmes.

Activation et configuration du profileur

Le profileur fonctionne à différents niveaux. Le niveau 0 désactive le profilage. Le niveau 1 profile toutes les opérations d'écriture. Le niveau 2 profile toutes les opérations.

Pour analyser les requêtes lentes, nous réglons généralement le profileur pour capturer les opérations dépassant un seuil spécifique (par exemple, 100 millisecondes) :

// Basculer vers la base de données que vous souhaitez profiler
use myDatabase

// Définir le niveau du profileur pour capturer les opérations prenant plus de 50 ms (50000 microsecondes)
// Note : le seuil est spécifié en microsecondes.
db.setProfilingLevel(2, { slowms: 50 })

Examen des résultats du profileur

Les opérations lentes enregistrées sont stockées dans la collection system.profile. Vous pouvez interroger cette collection pour voir les requêtes lentes récentes :

// Trouver les opérations prenant plus de 50 ms
db.system.profile.find({ ns: "myDatabase.myCollection", millis: { $gt: 50 } }).sort({ ts: -1 }).limit(10).pretty()

Meilleure pratique : Surveiller le profilage au niveau 2 en continu peut générer une charge d'écriture importante sur la collection system.profile. Réglez le niveau de profilage temporairement pour le diagnostic, ou utilisez des outils de surveillance de production qui utilisent le Performance Advisor à la place.

Étape 2 : Analyse de l'exécution des requêtes avec explain()

Une fois qu'une requête lente est identifiée, la méthode explain() est votre outil de diagnostic le plus puissant. Elle renvoie un plan d'exécution détaillé, montrant comment MongoDB traite la requête.

Utilisation de explain('executionStats')

Le niveau de verbosité executionStats fournit la sortie la plus complète, y compris les temps d'exécution réels et l'utilisation des ressources.

Considérez cette requête lente ciblant la collection users :

db.users.find({ status: "active", city: "New York" }).sort({ registrationDate: -1 }).explain('executionStats')

Interprétation de la sortie

Les champs clés à inspecter dans la sortie de explain() sont :

Champ	Description	Indicateur de lenteur
winningPlan.stage	La méthode d'exécution finale choisie par l'optimiseur de requêtes.	Recherchez COLLSCAN (Scan de Collection).
executionStats.nReturned	Le nombre de documents renvoyés par l'opération.	Un nombre élevé lorsqu'on attend peu de résultats indique souvent un filtrage médiocre dès le début.
executionStats.totalKeysExamined	Combien de clés d'index ont été vérifiées.	Devrait généralement être proche de nReturned si un index est utilisé efficacement.
executionStats.totalDocsExamined	Combien de documents ont été réellement récupérés du disque/de la mémoire.	Un nombre élevé suggère que l'index n'était pas suffisamment sélectif.
executionStats.executionTimeMillis	Le temps total pris pour l'exécution.	Comparez cela à la latence réelle.

Le drapeau rouge : COLLSCAN

Si winningPlan.stage affiche COLLSCAN, MongoDB a analysé la collection entière. C'est le principal indicateur qu'un index approprié est manquant ou a été ignoré.

Étape 3 : Mise en œuvre de stratégies d'indexation

La résolution de COLLSCAN implique généralement la création ou l'ajustement d'index pour correspondre au modèle de requête.

Création d'index composés

Pour les requêtes impliquant plusieurs champs (comme les correspondances d'égalité, les filtres de plage ou le tri), un index composé est souvent nécessaire. MongoDB utilise la Règle ESR (Égalité, Tri, Plage) pour déterminer l'ordre optimal des champs dans un index composé.

Scénario d'exemple :
Requête : db.orders.find({ status: "PENDING", customerId: 123 }).sort({ orderDate: -1 })

Selon ESR, l'index doit suivre cette structure :

1. Prédicats d'égalité (status, customerId)
2. Prédicats de tri (orderDate)

Création d'index :

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

Cet index permet à MongoDB de filtrer rapidement par statut et par ID client, puis de récupérer efficacement les résultats déjà triés par orderDate.

Gestion des opérations de tri

Si explain() affiche une étape SORT qui a nécessité le chargement de nombreux documents en mémoire (indiqué par un docsExamined élevé et une dépendance potentielle à la mémoire), cela signifie que MongoDB n'a pas pu utiliser un index pour satisfaire l'exigence de tri.

Avertissement : MongoDB impose une limite de mémoire par défaut (généralement 100 Mo) pour les tris en mémoire. Si l'opération de tri dépasse cette limite, elle échoue ou force un tri sur disque, ce qui est extrêmement lent.

Assurez-vous que les champs utilisés dans la clause .sort() sont présents en tant qu'éléments finaux de l'index composé approprié.

Étape 4 : Techniques d'optimisation avancées

Si l'indexation seule ne résout pas la lenteur, envisagez ces étapes avancées :

Optimisation de la projection

Utilisez la projection (.select() ou le deuxième argument de .find()) pour renvoyer uniquement les champs strictement nécessaires à l'application. Cela réduit la latence réseau et la quantité de données que MongoDB doit traiter et transférer.

// Ne renvoyer que les champs _id, name et email
db.users.find({ city: "Boston" }, { name: 1, email: 1, _id: 1 })

Index couvrants

Un index couvrant est l'objectif de performance ultime. Cela se produit lorsque tous les champs requis par la requête (dans le filtre, la projection et le tri) sont présents dans l'index lui-même. Lorsque cela se produit, MongoDB n'a jamais besoin de récupérer le document réel (COLLSCAN est évité, et totalDocsExamined sera de 0 ou très faible).

Dans la sortie explain(), un index couvrant se traduit par une étape affichant IXSCAN et totalDocsExamined égal à 0.

Examen du matériel et de la configuration

Si le profileur affiche un totalKeysExamined élevé même avec des index présents, le problème pourrait être lié à l'I/O. Assurez-vous que votre ensemble de travail (working set) tient dans la RAM, car cela minimise les accès disque pour les données fréquemment interrogées. Examinez les paramètres de configuration de mongod liés au mappage mémoire et à la journalisation si les performances restent médiocres sous forte charge.

Résumé et prochaines étapes

Le diagnostic des requêtes MongoDB lentes est un processus itératif : Profilez pour trouver les coupables, Expliquez pour comprendre pourquoi ils sont lents, et Indexez pour corriger le plan d'exécution sous-jacent. En appliquant systématiquement ces techniques, en particulier en se concentrant sur des index composés et couvrants efficaces, vous pouvez améliorer considérablement la santé et la réactivité de votre déploiement MongoDB.

Checklist d'actions :

1. Activez temporairement le profileur pour capturer les requêtes lentes (slowms).
2. Exécutez la requête problématique en utilisant explain('executionStats').
3. Vérifiez la présence de COLLSCAN ou d'un totalDocsExamined élevé.
4. Créez ou modifiez des index composés basés sur la règle ESR pour couvrir les filtres et les tris.
5. Vérifiez l'amélioration en réexécutant la commande explain().