Meilleures pratiques pour Amazon DocumentDB

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

Directives opérationnelles de base

Vous trouverez ci-dessous des directives opérationnelles de base que tout le monde doit suivre lorsqu'il travaille avec Amazon DocumentDB. Le contrat de niveau de service Amazon DocumentDB exige que vous suiviez ces directives.

• Déployez un cluster composé de deux instances Amazon DocumentDB ou plus dans deux zones de AWS disponibilité. Pour les charges de travail de production, déployez un cluster composé de trois instances Amazon DocumentDB ou plus dans trois zones de disponibilité.

• Utilisez le service dans les limites de service préconisées. Pour de plus amples informations, veuillez consulter Quotas Amazon DocumentDB.

• Surveillez votre mémoire, votre processeur, vos connexions et votre utilisation du stockage. Pour vous aider à maintenir les performances et la disponibilité du système, configurez Amazon CloudWatch pour qu'il vous avertisse lorsque les habitudes d'utilisation changent ou lorsque vous approchez de la capacité de votre déploiement.

• Augmentez la capacité de votre instance lorsque vous atteignez la limite de stockage. Vos instances doivent être provisionnées avec suffisamment de ressources de calcul (RAM, UC) pour répondre aux augmentations imprévues de la demande de vos applications.

• Définissez la période de conservation des sauvegardes en fonction de votre objectif de point de récupération.

• Testez le basculement pour votre cluster afin de connaître la durée du processus pour votre cas d'utilisation. Pour de plus amples informations, veuillez consulter Basculement d'Amazon DocumentDB.

• Connectez-vous à votre cluster Amazon DocumentDB via le point de terminaison du cluster (voirPoints de terminaison Amazon DocumentDB) et en mode jeu de répliques (voirConnexion à Amazon DocumentDB en tant que jeu de répliques) pour minimiser l'impact d'un basculement sur votre application.

• Choisissez un mode de préférence de lecture de pilote qui optimise la disponibilité en lecture tout en répondant à vos exigences de cohérence en lecture de votre application. La préférence de secondaryPreferred lecture active les lectures de réplica et libère l'instance principale pour effectuer plus de travail. Pour de plus amples informations, veuillez consulter Options de préférence de lecture.

• Concevez votre application pour qu'elle soit résiliente en cas d'erreurs réseau et de base de données. Utilisez le mécanisme d'erreur de votre pilote pour opérer une distinction entre les erreurs transitoires et les erreurs persistantes. Dans le cas d'erreurs transitoires, faites de nouvelles tentatives à l'aide d'un mécanisme de backoff exponentiel, le cas échéant. Assurez-vous que votre application prend en compte la cohérence des données lors de l'implémentation d'une logique de nouvelle tentative.

• Activez la protection contre la suppression de cluster pour tous les clusters de production ou pour tout cluster contenant des données importantes. Avant de supprimer un cluster Amazon DocumentDB, prenez une capture d'écran finale. Si vous déployez des ressources avec CloudFormation, activez la protection contre la résiliation. Pour de plus amples informations, veuillez consulter Protection contre la résiliation et protection contre la suppression.

• Lors de la création d'un cluster Amazon DocumentDB, --engine-version il s'agit d'un paramètre facultatif dont la valeur par défaut est la dernière version du moteur majeur. La version actuelle du moteur par défaut est 5.0.0 (remarque : Amazon DocumentDB 8.0 est disponible mais doit être explicitement spécifiée). Lorsque de nouvelles versions de moteurs majeurs sont publiées, la version du moteur par défaut pour --engine-version sera mise à jour pour refléter la dernière version du moteur majeur. Par conséquent, pour les charges de travail de production, et en particulier celles qui dépendent de scripts, d'automatisation ou de CloudFormation modèles, spécifiez explicitement la --engine-version version majeure prévue.

Dimensionnement de l'instance

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

Pour déterminer si l'ensemble de travail de votre application tient dans la mémoire, surveillez l'BufferCacheHitRatioutilisation d'Amazon CloudWatch pour chaque instance d'un cluster en cours de 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 conserver une valeur la plus élevée possible pour BufferCacheHitRatio, il est recommandé que les instances de votre cluster soient provisionnées avec suffisamment de RAM de manière à conserver vos index et vos données de travail en mémoire.

Si vos index ne tiennent pas en mémoire, BufferCacheHitRatio aura une valeur moins élevée. La lecture continue à partir d'un disque entraîne des I/O coûts supplémentaires et n'est pas meilleure que la lecture à partir de la mémoire. Si votre rapport BufferCacheHitRatio est moins élevé que prévu, mettez à l'échelle la taille d'instance de votre cluster afin de fournir plus de RAM pour adapter les données de jeu 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. Testez vos charges de travail dans un environnement de pré-production avec une charge de travail de production représentative, d'abord pour comprendre les caractéristiques de performance 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

Indices des bâtiments

Lorsque vous importez des données dans Amazon DocumentDB, vous devez créer vos index avant d'importer des jeux 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 et mise à niveau d'Amazon DocumentDB.

Sélectivité de l'indice

Limitez la création d'index aux champs où le nombre de valeurs dupliquées 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 indices de faible cardinalité continuent de consommer des ressources telles que l'espace disque et. I/Os 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 non utilisé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 et une augmentation du stockage global utilisé. I/O

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 d'avoir à lire en permanence les pages d'index du volume de stockage, ce qui a un impact négatif sur les performances et génère des I/O coûts plus élevés. Pour de plus amples informations, veuillez consulter Dimensionnement de l'instance.

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.

Identifier les index manquants

Il est recommandé d'identifier régulièrement les index manquants. Pour de plus amples informations, veuillez consulter Comment identifier les index manquants ?.

Identification des index non utilisés

Il est recommandé d'identifier et de supprimer régulièrement les index non utilisés. Pour de plus amples informations, veuillez consulter Comment analyser l'utilisation des index et identifier les index non utilisés ?.

Bonnes pratiques de sécurité

Pour connaître les meilleures pratiques en matière de sécurité pour Amazon DocumentDB, consultezMeilleures pratiques de sécurité pour Amazon DocumentDB.

Optimisation des coûts

Les bonnes pratiques suivantes peuvent vous aider à gérer et à minimiser vos coûts lors de l'utilisation d'Amazon DocumentDB. Pour plus d'informations sur les tarifs, consultez la tarification d'Amazon DocumentDB (avec compatibilité MongoDB) et les FAQ d'Amazon DocumentDB (avec compatibilité MongoDB).

• Créez des alertes de facturation à des seuils de 50 % et 75 % de votre facture prévue pour le mois. Pour plus d'informations sur la création d'alertes de facturation, consultez Création d'une alerte de facturation.

• L'architecture d'Amazon DocumentDB sépare le stockage et le calcul, de sorte que même un cluster à instance unique est extrêmement durable. Le volume de stockage de cluster réplique les données six fois sur trois zones de disponibilité, offrant ainsi une durabilité extrêmement élevée, quel que soit le nombre d'instances du cluster. Un cluster de production classique possède trois instances ou plus pour fournir une haute disponibilité. Cependant, vous pouvez optimiser les coûts en utilisant un cluster de développement d'instance unique lorsque la haute disponibilité n'est pas requise.

• Pour les scénarios de développement et de test, arrêtez un cluster lorsqu'il n'est plus nécessaire et démarrez-le lorsque le développement reprend. Pour de plus amples informations, veuillez consulter Arrêt et démarrage d'un cluster Amazon DocumentDB.

• Les flux TTL et de modification se produisent lors I/O de l'écriture, de la lecture et de la suppression des données. Si vous avez activé ces fonctionnalités mais que vous ne les utilisez pas dans votre application, vous pouvez les désactiver pour réduire les coûts.

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

Rubriques

• Consultation des métriques de performances

• Réglage d'une CloudWatch alarme

• Évaluation des métriques de performances

• Évaluation de l'utilisation des instances Amazon DocumentDB à l'aide de métriques CloudWatch

• Réglage des requêtes

Pour identifier les problèmes de performances dus à des ressources insuffisantes et à d'autres goulots d'étranglement courants, vous pouvez surveiller les mesures 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 CloudWatch des alarmes Amazon pour des seuils de mesure 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 mesures de performance à l'aide de la Console de gestion AWS touche ou AWS CLI. Pour de plus amples informations, veuillez consulter Affichage des CloudWatch données.

Réglage d'une CloudWatch alarme

Pour définir 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.

CPU

• Utilisation du processeur  : pourcentage de la capacité de traitement de l'ordinateur utilisée.

Mémoire

• Mémoire libérable  : quantité de RAM disponible sur l'instance.

• Utilisation du swap  : quantité d'espace de swap utilisée par l'instance, en mégaoctets.

Input/output opérations

• IOPS en lecture, IOPS en écriture  : nombre moyen d'opérations de lecture ou d'écriture sur disque par seconde.

• Latence de lecture, latence d'écriture  : durée moyenne d'une opération de lecture ou d'écriture en millisecondes.

• Débit de lecture, débit d'écriture  : nombre moyen de mégaoctets lus ou écrits sur le disque par seconde.

• Profondeur de la file d'attente de disque  : nombre d' I/Oopérations en attente d'écriture ou de lecture sur le disque.

Trafic réseau

• Débit de réception réseau, débit de transmission réseau  : taux de trafic réseau à destination et en provenance de l'instance en mégaoctets par seconde.

Connexions de la base de données

• Connexions à la base de données  : nombre de sessions clientes connectées à l'instance.

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 :

• Consommation de processeur élevée  : des valeurs élevées de consommation de processeur peuvent être appropriées, à condition qu'elles soient conformes à vos objectifs pour votre application (tels que le débit ou la simultanéité) et qu'elles soient attendues. Si votre consommation d'UC est constamment supérieure à 80 %, pensez à augmenter la capacité de vos instances.

• Consommation de RAM élevée  : si votre FreeableMemory métrique descend fréquemment en dessous de 10 % de la mémoire totale de l'instance, envisagez de faire évoluer vos instances. Pour plus d'informations sur ce qui se passe lorsque votre instance DocumentDB est confrontée à une pression de mémoire élevée, consultez Amazon DocumentDB Resource Governance.

• Utilisation du swap  : cette métrique doit rester égale ou proche de zéro. Si votre utilisation de l'échange est importante, envisagez de dimensionner vos instances.

• Trafic réseau — En ce qui concerne le trafic réseau, adressez-vous à votre administrateur système pour connaître le débit attendu pour votre réseau de domaine et votre connexion Internet. Enquêtez sur le trafic réseau si le débit est constamment inférieur à vos attentes.

• Connexions à la base de données  : envisagez de limiter les connexions à la base de données si vous constatez un nombre élevé de connexions utilisateur ainsi qu'une diminution des performances de l'instance et du temps de réponse. Le bon nombre de connexions utilisateur pour votre instance de base de données dépend de votre classe d'instance et de la complexité des opérations exécutées. Si vous rencontrez des problèmes avec les métriques de performances, l'une des premières choses à faire pour améliorer les choses est de régler les requêtes les plus utilisées et onéreuses pour réduire la pression exercée sur les ressources système.

Si vos requêtes sont optimisées et qu'un problème persiste, envisagez de mettre à niveau votre classe d'instance Amazon DocumentDB vers une classe utilisant davantage de ressources (CPU, RAM, espace disque, bande passante réseau, I/O capacité) liées au problème que vous rencontrez.

Évaluation de l'utilisation des instances 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 suffisamment de ressources pour vos applications. Pour plus d'informations sur vos quotas de classes d'instance, consultez Quotas d'instances et localisez les spécifications de votre classe d'instance pour 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 statistiques peuvent confirmer cette situation. Vous pouvez donc planifier une mise à l'échelle manuelle vers une classe d'instances plus importante.

Combinez les valeurs de CloudWatch métriques suivantes pour déterminer si vous êtes proche de la limite de classe d'instance :

• NetworkThroughput—La quantité de débit réseau reçue et transmise par les clients pour chaque instance du cluster Amazon DocumentDB. Cette valeur de débit n'inclut pas le trafic réseau entre les instances du cluster et le volume de stockage du cluster.

• StorageNetworkThroughput—La quantité de débit réseau reçue et envoyée au volume de stockage du cluster Amazon DocumentDB par chaque instance du cluster Amazon DocumentDB.

Ajoutez le NetworkThroughput à pour trouver le StorageNetworkThroughput débit réseau reçu et envoyé vers le 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 :

• NetworkReceiveThroughput—La quantité de débit réseau reçue des clients par chaque instance du cluster Amazon DocumentDB. Ce débit n'inclut pas le trafic réseau entre les instances du cluster et le volume de stockage du cluster.

• NetworkTransmitThroughput—La quantité de débit réseau envoyée aux clients par chaque instance du cluster Amazon DocumentDB. Ce débit n'inclut pas le trafic réseau entre les instances du cluster et le volume de stockage du cluster.

• StorageNetworkReceiveThroughput—La quantité de débit réseau reçue du volume de stockage du cluster Amazon DocumentDB par chaque instance du cluster.

• StorageNetworkTransmitThroughput—La quantité de débit réseau envoyée au volume de stockage du cluster Amazon DocumentDB par chaque instance du cluster.

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 l'utilisation du processeur par une instance sont mutuelles. Lorsque le débit réseau augmente, l’utilisation du processeur augmente également. La surveillance de l’utilisation du processeur et du réseau 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 :

• Utiliser une classe d’instance supérieure.

• Diviser les demandes d’écriture par lots afin de réduire le nombre total de transactions.

• Rediriger la charge de travail en lecture seule vers une instance en lecture seule.

• Supprimer tous les index inutilisés.

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).

Charges de travail TTL et séries chronologiques

La suppression de documents résultant de l'expiration de l'index TTL est un processus qui demande un effort maximal. 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 l'adéquation des index et du jeu de travail dans la mémoire peuvent tous avoir une incidence sur le moment où les documents expirés sont supprimés par le processus TTL.

Lorsque le moniteur TTL supprime vos documents, chaque suppression entraîne des I/O frais, ce qui augmente votre facture. Si le débit et les taux de suppression TTL augmentent, vous devez vous attendre à une facture plus élevée en raison d'une I/O utilisation accrue. Toutefois, si vous ne créez pas d'index TTL 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. Cela peut s'avérer nettement plus rentable que l'utilisation d'un indice TTL.

Pour les charges de travail chronologiques, vous pouvez envisager de créer des collections évolutives au lieu d'un index TTL, car les collections progressives peuvent être un meilleur moyen de supprimer des données et sont moins gourmands. I/O Si vous possédez de grandes collections (en particulier des collections de plus de 1 To) ou si I/O les coûts de suppression TTL sont préoccupants, partitionnez les documents en collections en fonction du temps et supprimez 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 I/O coût et peut s'avérer plus rapide et plus rentable que l'utilisation d'un indice TTL.

Migrations

Pour migrer des données vers Amazon DocumentDB, il est recommandé de créer d'abord vos index dans Amazon DocumentDB, puis de migrer vos 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 leMigration et mise à niveau d'Amazon DocumentDB.

Nous vous recommandons également, avant de migrer votre base de données de production, 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

Testez les modifications des groupes de paramètres de cluster sur un cluster de test avant d'appliquer les 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 du 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.

Insertion par lots et mise à jour par lots

Lorsque vous effectuez un taux élevé d'batchInsert and/orbatchUpdateopérations simultanées et que la quantité de FreeableMemory (CloudWatch Metric) 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