Bonnes pratiques en matière de performances : Indexation

Bienvenue dans le troisième article de notre série de blogs consacrés aux bonnes pratiques en matière de performances avec MongoDB.

Dans cette série, nous abordons les considérations clés pour atteindre la performance à répartir à travers un certain nombre de dimensions importantes, y compris :

• Modélisation des données et dimensionnement de la mémoire

• Modèles de requête et profilage

• L'indexation, que nous aborderons aujourd'hui

• Le sharding

• Transactions et problèmes de lecture/écriture

• Hardware et configuration du système d'exploitation

• Benchwarming

Ayant tous deux travaillé pour plusieurs fournisseurs de bases de données au cours des 15 dernières années, nous pouvons affirmer sans crainte que le fait de ne pas définir les index appropriés est le principal problème de performance que les équipes de support technique doivent résoudre avec les utilisateurs.

Nous devons donc faire les choses correctement.....Voici les meilleures pratiques pour vous aider.

Les index dans MongoDB

Dans toute base de données, les index favorisent l'exécution efficace des requêtes. Sans eux, la base de données doit parcourir chaque document d'une collection ou d'une table pour sélectionner ceux qui correspondent à l'énoncé de la requête. S'il existe un index approprié pour une requête, la base de données peut l'utiliser pour limiter le nombre de documents qu'elle doit inspecter.

MongoDB offre une large gamme de types d'index et de fonctionnalités avec des ordres de tri spécifiques à la langue pour supporter des schémas d'accès complexes à vos données. Les index MongoDB peuvent être créés et supprimés à la demande pour s'adapter à l'évolution des exigences des applications et des modèles d'interrogation. Ils peuvent être déclarés sur n'importe quel champ de vos documents, y compris les champs imbriqués dans les gammes.

Voyons donc comment utiliser au mieux les index dans MongoDB.

Utiliser un composé index

Les index composés sont des index constitués de plusieurs champs différents. Par exemple, au lieu d'avoir un index sur "Nom de famille" et un autre sur "Prénom", il est généralement plus efficace de créer un index qui inclut à la fois "Nom de famille" et "Prénom" si vous effectuez une requête sur les deux noms. Notre index composé peut toujours être utilisé pour filtrer les requêtes qui spécifient uniquement le nom de famille.

Suivre la règle de l'ESR

Pour les index composés, cette règle empirique est utile pour décider de l'ordre des champs dans l'index :

• Commencez par ajouter les champs à partir desquels les requêtes Equality sont exécutées.

• Les prochains champs à indexer doivent refléter l'ordre de tri de la requête.

• Les derniers champs représentent la plage de données à accéder.

Utiliser des requêtes couvertes lorsque c'est possible

Les requêtes couvertes renvoient directement les résultats d'un index sans avoir à accéder aux documents sources, et sont donc très efficaces.

Pour qu'une requête soit couverte, tous les champs nécessaires au filtrage, au tri et/​ou au renvoi au client doivent être présents dans un index. Pour déterminer si une requête est une requête couverte, utilisez la méthode explain(). Si la sortie explain() affiche totalDocsExamined comme étant 0, cela indique que la requête est couverte par un index. Pour plus d'informations sur les résultats, voir la documentation.

Un problème fréquent lors de l'exécution de requêtes couvertes est que le champ ID est toujours renvoyé par défaut. Vous devez l'exclure explicitement des résultats de la requête ou l'ajouter à l'index.

Dans les clusters partitionnés, MongoDB doit accéder en interne aux champs de la clé de sharding. Cela signifie que les requêtes couvertes ne sont possibles que lorsque la clé de sharding fait partie de l'index. C'est généralement une bonne idée de le faire de toute façon.

Soyez prudent lorsque vous envisagez d'utiliser des index sur des champs de faible cardinalité.

Les requêtes portant sur des champs ayant un petit nombre de valeurs uniques (faible cardinalité) peuvent renvoyer des résultats importants définir. Les index composés peuvent inclure des champs de faible cardinalité, mais la valeur des champs combinés doit présenter une cardinalité élevée.

Éliminer les index inutiles

Les index sont gourmands en ressources : même avec la compression dans le moteur de stockage MongoDB WiredTiger, ils consomment RAM et du disque. Au fur et à mesure que les champs sont mis à jour, les index associés doivent être maintenus, ce qui entraîne des frais généraux supplémentaires pour l'unité centrale et les entrées/​sorties sur disque.

MongoDB fournit des outils pour vous aider à comprendre l'utilisation de l'index, que nous aborderons plus loin dans ce billet.

Les index Wildcard ne remplacent pas la planification d'index basée sur la charge de travail

Pour les charges de travail comportant de nombreux modèles d'interrogation ad hoc ou traitant des structures de documents très polymorphes, les index génériques offrent une grande souplesse supplémentaire. Vous pouvez définir un filtre qui indexe automatiquement tous les champs, sous-documents et gammes correspondants dans une collection.

Comme tout index, ils doivent également être stockés et mis à jour, ce qui ajoute des frais généraux à la base de données. Si les modèles de requête de votre application sont connus à l'avance, vous devriez utiliser des index plus sélectifs sur les champs spécifiques accédés par les requêtes.

Utiliser la recherche de texte pour faire correspondre des mots à l'intérieur d'un champ

Les index réguliers sont utiles pour faire correspondre la valeur totale d'un champ. Si vous souhaitez uniquement faire correspondre un mot spécifique dans un champ contenant beaucoup de texte, utilisez un index de texte.

Si vous utilisez MongoDB dans le service Atlas, envisagez d'utiliser Atlas Full Text Search qui fournit un index Lucene entièrementmanaged intégré à la base de données MongoDB. FTS offre de meilleures performances et une plus grande flexibilité pour filtrer, classer et trier votre base de données afin de faire apparaître rapidement les résultats les plus pertinents pour vos utilisateurs.

Utiliser des index partiels

Réduire la taille et les frais généraux des index en n'incluant que les documents qui seront accessibles par l'intermédiaire de l'index. Par exemple, créer un index partiel sur le champ orderID qui n'inclut que les documents de commande dont l'état est "En cours", ou qui n'indexe le champ emailAddress que pour les documents où il existe.

Tirer parti des index multi-clefs pour l'interrogation de la gamme

Si vos requêtes nécessitent l'accès à des éléments individuels de la gamme, utilisez un index à plusieurs clés. MongoDB crée une clé d'indexation pour chaque élément de la gamme et peut être construit sur des gammes contenant à la fois des valeurs scalaires et des documents imbriqués.

Éviter les expressions régulières qui ne sont pas ancrées ou enracinées à gauche

Les index sont classés par valeur. Les caractères génériques de tête sont inefficaces et peuvent entraîner des balayages complets de l'index. Les caractères génériques de fin peuvent être efficaces si l'expression contient suffisamment de caractères de tête sensibles à la casse.

Éviter les expressions régulières insensibles à la casse

Si la seule raison d'utiliser une expression rationnelle est l'insensibilité à la casse, utilisez plutôt un index insensible à la casse, qui est plus rapide.

Utiliser les optimisations d'index disponibles dans le moteur de stockage WiredTiger

Si vous gérez vous-même MongoDB, vous pouvez éventuellement placer les index sur leur propre volume séparé, ce qui permet d'accélérer la pagination sur le disque et de réduire la contention. Voir WiredTiger options pour plus d'informations.

Utiliser le plan d'explication

Nous avons abordé l'utilisation du plan d'explication de MongoDB dans l'article précédent sur les modèles de requête et le profilage, et il s'agit du meilleur outil pour vérifier la couverture de l'index pour des requêtes individuelles.

À partir du plan d'explication, MongoDB fournit des outils de visualisation qui permettent de mieux comprendre vos index, et qui fournissent des recommandations intelligentes et automatiques sur les index à ajouter.

Visualiser la couverture de l'index avec MongoDB Compass et Atlas Data Explorer

En tant qu'interface graphique gratuite, MongoDB Compass offre de nombreuses fonctionnalités pour vous aider à optimiser les performances des requêtes, notamment l'exploration de votre schéma et la visualisation des plans d'explication des requêtes - deux domaines abordés précédemment dans cette série.

L'onglet "index" de Compass ajoute un nouvel outil à votre arsenal. Il répertorie les index existants pour une collection, en indiquant le nom et les clés de l'index, ainsi que son type, sa taille et toutes les propriétés spéciales. L'onglet Index permet également d'ajouter et de supprimer des index en fonction des besoins.

Une fonctionnalité très utile est l'utilisation de l'index, qui vous indique combien de fois un index a été utilisé. Le fait d'avoir trop d'index peut être presque aussi préjudiciable à vos performances que d'en avoir trop peu, ce qui rend cette fonctionnalité particulièrement utile pour vous aider à identifier et à supprimer les index qui ne sont pas utilisés. Cela vous permet de libérer de l'espace de travail et d'éliminer les frais généraux de la base de données liés à la maintenance de l'index.

Si vous utilisez MongoDB dans notre service Atlas entièrementmanaged, la vue des index dans l'explorateur de données vous donnera la même fonctionnalité que Compass, sans que vous ayez à vous connecter à votre base de données avec un outil séparé.

Vous pouvez également récupérer les statistiques de l'index à l'aide de l'étape $indexStats aggregation pipeline.

Recommandations automatisées index

Même avec toutes les données télémétriques fournies par les outils de MongoDB, vous êtes toujours responsable de l'extraction et de l'analyse des données nécessaires pour prendre des décisions sur les index à ajouter.

Le seuil pour les requêtes lentes varie en fonction du temps moyen des opérations sur votre cluster afin de fournir des recommandations pertinentes pour votre charge de travail.

Les index recommandés sont accompagnés d'exemples de requêtes, regroupés par forme de requête (c'est-à-dire des requêtes avec une structure de prédicat, un tri et une projection similaires), qui ont été exécutées sur une collection qui bénéficierait de l'ajout d'un index suggéré. Le Performance Advisor n'affecte pas négativement les performances de votre Atlas cluster.

Si vous êtes satisfait de la recommandation, vous pouvez alors déployer les nouveaux index automatiquement, sans interruption de l'application.

Prochaines étapes

Voilà qui conclut ce dernier épisode de la série des meilleures pratiques en matière de performances. MongoDB University propose une formation en ligne gratuite sur les performances de MongoDB. C'est un excellent moyen d'en savoir plus sur la puissance de l'indexation.