Les traductions sont fournies par des outils de traduction automatique. En cas de conflit entre le contenu d'une traduction et celui de la version originale en anglais, la version anglaise prévaudra.

Bonnes pratiques pour Amazon DocumentDB

Découvrez les meilleures pratiques pour travailler avec Amazon DocumentDB (compatible avec MongoDB). Cette section est mise à jour en continu à mesure que de nouvelles bonnes pratiques sont identifiées.

Directives opérationnelles de base

Voici les directives opérationnelles de base que tout le monde doit suivre lorsqu'il travaille avec Amazon DocumentDB. L'accord de niveau de service Amazon DocumentDB exige que vous suiviez ces directives.

Dimensionnement des instances

L'un des aspects les plus critiques du choix d'une taille d'instance dans Amazon DocumentDB est la quantité RAM de cache. Amazon DocumentDB en réserve un tiers RAM pour ses propres services, ce qui signifie que seuls les deux tiers de l'instance RAM sont disponibles pour le cache. Il est donc recommandé d'Amazon DocumentDB de choisir un type d'instance suffisamment adapté RAM à votre ensemble de travail (c'est-à-dire les données et les index) en mémoire. Disposer d’instances correctement dimensionnées aide à optimiser les performances globales et à minimiser potentiellement les coûts d'E/S. Vous pouvez utiliser le calculateur de dimensionnement tiers Amazon DocumentDB pour estimer la taille de l'instance pour une charge de travail particulière.

Pour déterminer si la capacité de travail de votre application est suffisante pour la mémoire, surveillez BufferCacheHitRatio l'utilisation d'Amazon CloudWatch pour chaque instance d'un cluster en charge.

La BufferCacheHitRatio CloudWatch métrique mesure le pourcentage de données et d'index servis à partir du cache mémoire d'une instance (par rapport au volume de stockage). En règle générale, la valeur de BufferCacheHitRatio doit être aussi élevée que possible, car la lecture des données à partir de la mémoire de l’ensemble de travail est plus rapide et plus rentable que la lecture à partir du volume de stockage. Bien qu'il soit souhaitable de conserver BufferCacheHitRatio le plus proche possible de 100 %, la meilleure valeur possible dépend des modèles d'accès et des exigences de performances de votre application. Pour maintenir le niveau le plus élevé possibleBufferCacheHitRatio, il est recommandé de provisionner les instances de votre cluster en quantité suffisante RAM pour pouvoir mettre en mémoire vos index et votre ensemble de données de travail.

Si vos index ne tiennent pas en mémoire, BufferCacheHitRatio aura une valeur moins élevée. La lecture continue depuis le disque entraîne des coûts d'E/S supplémentaires et n'est pas meilleure que la lecture depuis la mémoire. Si votre BufferCacheHitRatio ratio est inférieur aux prévisions, augmentez la taille de l'instance pour votre cluster afin d'en fournir davantage RAM pour contenir les données des ensembles de travail en mémoire. Si la mise à l'échelle de la classe d'instance entraîne une augmentation spectaculaire de BufferCacheHitRatio, cela signifie que l'ensemble de travail de votre application ne tenait pas en mémoire. Continuez à monter en puissance jusqu'à ce que la valeur de BufferCacheHitRatio n'augmente plus considérablement après une opération de mise à l'échelle. Pour de plus amples informations sur la surveillance des métriques d'une instance, veuillez consulter Métriques Amazon DocumentDB.

En fonction de vos besoins de charge de travail et de latence, votre application peut avoir des valeurs BufferCacheHitRatio plus élevées lors de son utilisation à l'état stable, mais BufferCacheHitRatio peut chuter périodiquement lorsque des requêtes analytiques devant analyser une collection entière sont exécutées sur une instance. Ces chutes périodiques de BufferCacheHitRatio peuvent se traduire par une latence plus élevée pour les requêtes ultérieures qui doivent repeupler les données de l'ensemble de travail à partir du volume de stockage dans le cache tampon. Nous vous recommandons de tester vos charges de travail dans un environnement de préproduction avec une charge de travail de production représentative afin de comprendre les caractéristiques de performances et BufferCacheHitRatio avant de déployer la charge de travail en production.

BufferCacheHitRatio est une métrique spécifique à l'instance, de sorte que différentes instances d'un même cluster peuvent avoir des valeurs BufferCacheHitRatio différentes selon la façon dont les lectures sont réparties entre les instances principale et de réplica. Si votre charge de travail opérationnelle ne peut pas gérer les augmentations périodiques de latence résultant du repeuplement du cache de l'ensemble de travail après l'exécution des requêtes analytiques, essayez d'isoler le cache tampon de la charge de travail normale de celui des requêtes analytiques. Vous pouvez obtenir une isolation BufferCacheHitRatio complète en dirigeant les requêtes opérationnelles vers l'instance principale et les requêtes analytiques uniquement vers les instances de réplica. Vous pouvez également réaliser une isolation partielle en dirigeant les requêtes analytiques vers une instance de réplica spécifique, en sachant qu'un certain pourcentage de requêtes régulières s'exécuteront également sur ce réplica et peuvent être affectées.

Les valeurs BufferCacheHitRatio appropriées dépendent de votre cas d'utilisation et des exigences de l'application. Il n'y a pas de valeur optimale ou minimale pour cette métrique ; vous seul pouvez décider si le compromis d'une valeur BufferCacheHitRatio temporairement inférieure est acceptable du point de vue des coûts et des performances.

Utilisation des index

Création d'index

Lorsque vous importez des données dans Amazon DocumentDB, vous devez créer vos index avant d'importer des ensembles de données volumineux. Vous pouvez utiliser l'outil d'indexation Amazon DocumentDB pour extraire des index d'une instance ou d'un mongodump répertoire MongoDB en cours d'exécution, et créer ces index dans un cluster Amazon DocumentDB. Pour plus d'informations sur les migrations, consultez Migration vers Amazon DocumentDB.

Sélectivité des indices

Nous vous recommandons de limiter la création d'index aux champs dont le nombre de valeurs en double est inférieur à 1 % du nombre total de documents de la collection. Par exemple, si votre collection contient 100 000 documents, créez uniquement des index sur les champs où la même valeur se produit 1 000 fois ou moins.

Le choix d'un index avec un grand nombre de valeurs uniques (c.-à-d. une cardinalité élevée) garantit que les opérations de filtrage renvoient un petit nombre de documents, ce qui donne de bonnes performances lors des analyses d'index. L'index unique est un exemple d'index de cardinalité élevé, qui garantit que les prédicats d'égalité retournent au plus un seul document. L'index sur un champ booléen et l'index sur le jour de la semaine sont des exemples de faible cardinalité. En raison de leurs performances médiocres, il est peu probable que les index de cardinalité soient choisis par l'optimiseur de requête de la base de données. Dans le même temps, les index de cardinalité faibles continuent de consommer des ressources telles que l'espace disque et les E/S. En règle générale, vous devez cibler les index sur les champs dont la fréquence de valeur type est inférieure ou égale à 1 % de la taille totale de la collection.

En outre, il est recommandé de créer uniquement des index sur les champs qui sont couramment utilisés comme filtre et de rechercher régulièrement des index inutilisés. Pour de plus amples informations, veuillez consulter Comment analyser l'utilisation des index et identifier les index inutilisés ?.

Impact des index sur l'écriture des données

Bien que les index puissent améliorer les performances des requêtes en évitant le besoin de numériser tous les documents d'une collection, cette amélioration implique un compromis. Pour chaque index d'une collection, chaque fois qu'un document est inséré, mis à jour ou supprimé, la base de données doit mettre à jour la collection et écrire les champs dans chacun des index de la collection. Par exemple, si une collection comporte neuf index, la base de données doit effectuer dix écritures avant d'accuser réception de l'opération au client. Ainsi, chaque index supplémentaire entraîne une latence d'écriture supplémentaire, des E/S et une augmentation de l'ensemble du stockage utilisé.

Les instances de cluster doivent être dimensionnées de manière appropriée afin de conserver toute la mémoire de l'ensemble de travail. Cela évite de devoir lire en continu les pages d'index à partir du volume de stockage, ce qui a un impact négatif sur les performances et génère des coûts d'E/S plus élevés. Pour de plus amples informations, veuillez consulter Dimensionnement des instances.

Pour de meilleures performances, réduisez le nombre d'index dans vos collections, en ajoutant uniquement les index nécessaires pour améliorer les performances des requêtes courantes. Bien que les charges de travail varient, une bonne recommandation consiste à maintenir le nombre d'index par collection à cinq ou moins.

Identification des index manquants

L'identification des index manquants est une bonne pratique que nous recommandons d'appliquer régulièrement. Pour plus d'informations, consultez Comment identifier les index manquants ?.

Identification des index inutilisés

L'identification et la suppression des index inutilisés est une bonne pratique que nous recommandons d'effectuer régulièrement. Pour plus d'informations, consultez Comment analyser l'utilisation des index et identifier les index inutilisés ?.

Bonnes pratiques de sécurité

Pour respecter les meilleures pratiques en matière de sécurité, vous devez utiliser des comptes AWS Identity and Access Management (IAM) pour contrôler l'accès aux API opérations Amazon DocumentDB, en particulier aux opérations qui créent, modifient ou suppriment des ressources Amazon DocumentDB. Les ressources de ce type incluent les clusters, les groupes de sécurité et les groupes de paramètres. Vous devez également l'utiliser IAM pour contrôler les actions qui exécutent des actions administratives courantes, telles que la sauvegarde et la restauration de clusters. Lorsque vous créez IAM des rôles, appliquez le principe du moindre privilège.

Optimisation des coûts

Les meilleures pratiques suivantes peuvent vous aider à gérer et à minimiser vos coûts lorsque vous utilisez Amazon DocumentDB. Pour obtenir des informations sur les tarifs, consultez les tarifs Amazon DocumentDB (avec compatibilité MongoDB) et Amazon DocumentDB (avec compatibilité MongoDB). FAQs

Utilisation des métriques pour identifier les problèmes de performances

Pour identifier les problèmes de performances dus à des ressources insuffisantes ou à d'autres blocages courants, vous pouvez surveiller les métriques disponibles pour votre cluster Amazon DocumentDB.

Consultation des métriques de performances

Vous devez régulièrement surveiller les métriques de performances pour observer les valeurs moyennes, maximales et minimales à différents intervalles de temps. Cela vous aide à déterminer quand les performances se dégradent. Vous pouvez également définir des CloudWatch alarmes Amazon pour des seuils métriques spécifiques afin d'être alerté s'ils sont atteints.

Pour résoudre les problèmes de performances, il est important de comprendre les performances de base du système. Lorsque vous configurez un nouveau cluster et l'exécutez avec une charge de travail typique, capturez les valeurs moyennes, maximum et minimum de toutes les métriques de performances à différents intervalles (par exemple, une heure, 24 heures, une semaine, deux semaines). Cela vous permet de vous faire une idée de ce qui est normal. Cela permet de comparer l'activité pendant les heures pleines et les heures creuses. Vous pouvez ensuite utiliser ces informations pour identifier quand les performances chutent sous les niveaux standard.

Vous pouvez consulter les indicateurs de performance à l'aide du AWS Management Console ou AWS CLI. Pour de plus amples informations, veuillez consulter Visualisation CloudWatch des données.

Régler une CloudWatch alarme

Pour configurer une CloudWatch alarme, consultez la section Utilisation d'Amazon CloudWatch Alarms dans le guide de CloudWatch l'utilisateur Amazon.

Évaluation des métriques de performances

Une instance possède différentes catégories de métriques. La façon de déterminer les valeurs acceptables dépend de la métrique.

En général, les valeurs acceptables pour les métriques de performances dépendent de vos données de référence et de l'activité de votre application. Enquêtez sur les écarts cohérents ou tendanciels de vos données de référence.

Voici quelques recommandations et conseils sur les types spécifiques de métriques :

Si vos requêtes sont réglées et que le problème persiste, envisagez de mettre à niveau votre classe d'instance Amazon DocumentDB vers une classe disposant d'une plus grande partie des ressources (CPURAM,, espace disque, bande passante réseau, capacité d'E/S) associées au problème que vous rencontrez.

Évaluation de l'utilisation de l'instance Amazon DocumentDB à l'aide de métriques CloudWatch

Vous pouvez utiliser CloudWatch des métriques pour surveiller le débit de votre instance et découvrir si votre classe d'instance fournit des ressources suffisantes pour vos applications. Pour plus d'informations sur les limites de votre classe d'instance, consultez Limites d’instance et localisez les spécifications de votre classe d'instance afin de connaître les performances de votre réseau.

Si l'utilisation de votre instance est proche de la limite de classe d'instance, les performances peuvent commencer à ralentir. Les CloudWatch métriques peuvent confirmer cette situation afin que vous puissiez planifier une mise à l'échelle manuelle vers une classe d'instance plus importante.

Combinez les valeurs de CloudWatch métriques suivantes pour savoir si vous approchez de la limite de classe d'instance :

Ajoutez le NetworkThroughputà pour connaître le StorageNetworkThroughputdébit réseau reçu et envoyé au volume de stockage du cluster Amazon DocumentDB par chaque instance de votre cluster Amazon DocumentDB. La limite de classe d'instance pour votre instance doit être supérieure à la somme de ces deux métriques combinées.

Vous pouvez utiliser les métriques suivantes pour consulter des informations supplémentaires sur le trafic réseau provenant de vos applications clientes lors de l'envoi et de la réception :

Ajoutez toutes ces métriques pour évaluer l'utilisation de votre réseau par rapport à la limite de classe d'instance. La limite de classe d'instance doit être supérieure à la somme de ces métriques combinées.

Les limites du réseau et CPU l'utilisation par une instance sont mutuelles. Lorsque le débit du réseau augmente, l'CPUutilisation augmente également. La surveillance de l'utilisation du réseau CPU et de son utilisation fournit des informations sur comment et pourquoi les ressources sont épuisées.

Pour minimiser l'utilisation du réseau, vous pouvez envisager ce qui suit :

Réglage des requêtes

L'un des meilleurs moyens d'améliorer les performances d'un cluster consiste à régler les requêtes les plus communément utilisées et exigeantes en ressources pour les rendre moins onéreuses à exécuter.

Vous pouvez utiliser le profileur (voir Profilage des opérations Amazon DocumentDB) pour enregistrer l'heure d'exécution et les détails des opérations qui ont été effectuées sur votre cluster. Le profileur est utile pour surveiller les opérations les plus lentes sur votre cluster afin de vous aider à améliorer les performances des requêtes individuelles et les performances globales du cluster.

Vous pouvez également utiliser la commande explain pour apprendre à analyser un plan de requête pour une requête particulière. Vous pouvez utiliser ces informations pour modifier une requête ou collection sous-jacente afin d'améliorer les performances de vos requêtes (par exemple, en ajoutant un index).

TTLet charges de travail liées aux séries chronologiques

La suppression de documents à la suite de TTL l'expiration de l'index est le meilleur effort possible. Il n’est pas certain que les documents soient supprimés dans un délai spécifique. Des facteurs tels que la taille de l'instance, l'utilisation des ressources de l'instance, la taille du document, le débit global, le nombre d'index et la capacité de mémoire des index et de l'ensemble de travail peuvent avoir une incidence sur le moment où les documents expirés sont supprimés par le processus. TTL

Lorsque le TTL moniteur supprime vos documents, chaque suppression entraîne des coûts d'E/S, ce qui augmente votre facture. Si le débit et les taux de TTL suppression augmentent, vous devez vous attendre à une facture plus élevée en raison de l'utilisation accrue des E/S. Toutefois, si vous ne créez pas d'TTLindex pour supprimer des documents, mais que vous segmentez les documents en collections en fonction du temps et que vous supprimez simplement ces collections lorsqu'elles ne sont plus nécessaires, vous n'aurez aucun coût d'E/S à payer. Cela peut être nettement plus rentable que l'utilisation d'un TTL indice.

Pour les charges de travail basées sur des séries chronologiques, vous pouvez envisager de créer des collections progressives au lieu d'un TTL index, car les collections progressives peuvent être un meilleur moyen de supprimer des données et de réduire la consommation d'E/S. Si vous avez de grandes collections (en particulier des collections de plus de 1 To) ou si les coûts d'E/S de TTL suppression vous préoccupent, nous vous recommandons de partitionner les documents en collections en fonction du temps et de supprimer les collections lorsque les documents ne sont plus nécessaires. Vous pouvez créer une collection par jour ou une par semaine, en fonction de votre taux d'ingestion de données. Bien que les exigences varient en fonction de votre application, une bonne règle consiste à avoir davantage de petites collections plutôt que quelques grandes collections. La suppression de ces collections n'entraîne aucun coût d'E/S et peut s'avérer plus rapide et plus rentable que l'utilisation d'un TTL index.

Migrations

En tant que bonne pratique, nous vous recommandons, lors de la migration de données vers Amazon DocumentDB, de créer d'abord vos index dans Amazon DocumentDB avant de migrer les données. La création d'index d'abord peut réduire le temps global et augmenter la vitesse de la migration. Pour ce faire, vous pouvez utiliser l'outil d'indexation Amazon DocumentDB. Pour plus d'informations sur les migrations, consultez le guide de migration Amazon DocumentDB.

Avant de migrer votre base de données de production, nous vous recommandons également de tester entièrement votre application sur Amazon DocumentDB, en tenant compte des fonctionnalités, des performances, des opérations et des coûts.

Utilisation de groupes de paramètres de cluster

Nous vous recommandons de tester les modifications apportées aux groupes de paramètres de cluster sur un cluster test avant d'appliquer ces modifications à vos clusters de production. Pour de plus amples informations sur la sauvegarde de votre cluster, veuillez consulter Sauvegarde et restauration dans Amazon DocumentDB.

Requêtes de pipeline d'agrégation

Lors de la création d'une requête de pipeline d'agrégation avec plusieurs étapes et de l'évaluation d'un sous-ensemble de données dans la requête, utilisez l’étape $match comme première étape ou au début du pipeline. L'utilisation de $match en premier permet de réduire le nombre de documents que les étapes suivantes de la requête de pipeline d'agrégation devront traiter. Les performances de votre requête en seront améliorées.

batchInsert et batchUpdate

Lorsque vous effectuez un taux élevé de simultanéité batchInsert et/ou d'batchUpdateopérations et que le montant de FreeableMemory (CloudWatch métrique) passe à zéro sur votre instance principale, vous pouvez soit réduire la simultanéité de l'insertion par lots, soit mettre à jour la charge de travail, soit, si la simultanéité de la charge de travail ne peut pas être réduite, augmenter la taille de l'instance pour augmenter la quantité de. FreeableMemory