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.

• Déployez un cluster composé d'au moins deux instances Amazon DocumentDB dans deux zones de AWS disponibilité. Pour les charges de travail de production, nous recommandons de déployer un cluster composé d'au moins trois instances Amazon DocumentDB dans trois zones de disponibilité.

• Utilisez le service dans les limites de service préconisées. Pour plus d’informations, consultez Quotas et limites 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 plus d’informations, consultez Basculement Amazon DocumentDB.

• Connectez-vous à votre cluster Amazon DocumentDB avec le point de terminaison du cluster (voirPoints de terminaison Amazon DocumentDB) et en mode Replica Set (voirConnexion à Amazon DocumentDB en tant qu'ensemble de réplicas) afin de 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 plus d’informations, consultez 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 un dernier instantané. Si vous déployez des ressources avec AWS CloudFormation, activez la protection contre le licenciement. Pour plus d’informations, consultez Protection contre la résiliation et la suppression.

• Lors de la création d'un cluster Amazon DocumentDB, le paramètre --engine-version est un paramètre facultatif qui utilise par défaut la dernière version majeure du moteur. La version majeure actuelle du moteur est 4.0.0. Lorsque de nouvelles versions majeures du moteur sont publiées, la version par défaut du moteur pour --engine-version sera mise à jour pour refléter la dernière version du moteur principal. Par conséquent, pour les charges de travail de production, et en particulier celles qui dépendent de scripts, d'automatisation ou de AWS CloudFormation modèles, nous vous recommandons de spécifier explicitement --engine-version par rapport à la version majeure prévue.

Dimensionnement d'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. Il est donc recommandé d'Amazon DocumentDB de choisir un type d'instance disposant de suffisamment de RAM pour adapter 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 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 du disque entraîne des coûts d'E/S supplémentaires et n'est pas aussi performante 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. 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é de l'index

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 plus d’informations, consultez Comment analyser l'utilisation des index et identifier les index inutilisés ?.

Incidence des index sur la rédaction de 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 plus d’informations, consultez Dimensionnement d'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.

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 opérations de l'API 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 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 des rôles IAM, appliquez le principe du moindre privilège.

• Appliquez le principe du moindre privilège avec le contrôle d'accès basé sur les rôles.

• Attribuez un compte IAM individuel à chaque personne qui gère les ressources Amazon DocumentDB. N'utilisez pas l'utilisateur Compte AWS root pour gérer les ressources Amazon DocumentDB. Créez un utilisateur IAM pour chaque personne, y compris vous-même.

• Accordez à chaque utilisateur IAM les autorisations minimales requises pour accomplir ses tâches.

• Utilisez des groupes IAM pour gérer efficacement des autorisations pour plusieurs utilisateurs. Pour de plus amples informations sur IAM, veuillez consulter le Guide de l'utilisateur IAM. Pour de plus amples informations sur les bonnes pratiques IAM, veuillez consulter Bonnes pratiques IAM.

• Effectuez une rotation régulière des informations d'identification IAM.

• Configurez AWS Secrets Manager pour qu'il fasse automatiquement pivoter les secrets pour Amazon DocumentDB. Pour plus d'informations, consultez Rotating Your AWS Secrets Manager secrets et Rotating Secrets for Amazon DocumentDB dans le guide de l'utilisateur de AWS Secrets Manager.

• Accordez à chaque utilisateur Amazon DocumentDB les autorisations minimales requises pour effectuer ses tâches. Pour plus d’informations, consultez Accès à la base de données à l'aide du contrôle d'accès basé sur les rôles.

• Utilisez le protocole TLS (Transport Layer Security) pour chiffrer vos données en transit et AWS KMS pour chiffrer vos données au repos.

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 FAQ relatives à la tarification d'Amazon DocumentDB (avec compatibilité MongoDB) et les FAQ relatives à 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 très 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 plus d’informations, consultez Arrêt et démarrage d'un cluster Amazon DocumentDB.

• Les flux TTL et les flux de modification entraînent des E/S lorsque les données sont écrites, lues et supprimé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

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 plus d’informations, consultez Visualisation CloudWatch Données.

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

Evaluation 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 disponible : quantité de RAM disponible sur l'instance.

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

Opérations d'entrée/sortie

• IOPS en lecture, IOPS en écriture : nombre moyen d'opérations de lecture ou d'écriture sur le 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 du disque : nombre d'opérations d'E/S 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 : débit du 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 client 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 élevée du processeur : des valeurs élevées de consommation du processeur peuvent être appropriées, à condition qu'elles soient conformes aux objectifs de 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 indicateur tombe fréquemment en dessous de 10 % de la mémoire totale de l'instance, pensez à augmenter le volume de vos instances. Pour plus d'informations sur ce qui se passe lorsque votre instance DocumentDB est confrontée à une charge de mémoire élevée, consultez Amazon DocumentDB Resource Governance.

• Utilisation des swaps — 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 : pour le trafic réseau, contactez votre administrateur système afin de connaître le débit attendu pour le réseau de votre domaine et votre connexion Internet. Enquêtez sur le trafic réseau si le débit est constamment inférieur à vos attentes.

• Connexions aux bases de données — Envisagez de restreindre les connexions aux bases de données si vous constatez un nombre élevé de connexions utilisateur ainsi qu'une baisse des performances des instances 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 réglées et que le problème persiste, envisagez de mettre à niveau votre classe d'instance Amazon DocumentDB vers une classe contenant davantage de ressources (processeur, RAM, espace disque, bande passante réseau, capacité d'E/S) associées au problème que vous rencontrez.

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 en 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 coûts d'E/S, ce qui augmente le montant de votre facture. Si le débit et les taux de suppression TTL 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'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 à payer. Cela peut être nettement plus rentable que l'utilisation d'un indice TTL.

Pour les charges de travail en séries chronologiques, vous pouvez envisager de créer des collections continues au lieu d'un index TTL, car les collections continues peuvent constituer un moyen plus performant de supprimer des données tout en étant moins gourmand en E/S. Si vous avez des collections volumineuses (en particulier des collections supérieures à 1 To) ou si les coûts d'E/S de suppression de TTL sont élevés, nous vous recommandons de partitionner les documents dans des 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 pas de coûts d'E/S et peut s'avérer plus rapide et plus rentable que l’utilisation d’un index TTL.

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 des 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