Choisir la bonne classe d'instance de base de données

La bonne classe d'instance dépend de la façon dont vos requêtes de table étrangère utilisent la mémoire, le stockage et le processeur. Pour plus de détails sur chacune de ces ressources, consultezGestion des ressources.

• Mémoire : une requête de table étrangère conserve ses données de travail (tris, agrégations et tables de hachage pour les jointures) en mémoire, délimitées par le aurora_analytics.query_mem paramètre (query_memen abrégé). La valeur par défaut varie en query_mem fonction de la taille de l'instance, de sorte qu'une instance plus grande donne automatiquement plus de mémoire à chaque requête. Lorsqu'une requête dépassequery_mem, elle est redirigée vers le stockage local, qui est plus lent. Pour plus d’informations, consultez Adapter query_mem à votre charge de travail.

• Simultanéité : chaque requête de table étrangère simultanée alloue de la mémoire jusqu'àquery_mem, mais l'utilisation réelle dépend de la requête, et les requêtes simples peuvent en utiliser beaucoup moins. Lorsque vous optez pour la simultanéité, budgétisez en fonction de la mémoire maximale plutôt que de supposer que chaque requête utilise la totalité query_mem de la mémoire. Pour plus d’informations, consultez Dimensionnement de la simultanéité.

• Mise en cache et diffusion : le cache sur disque pour les données Amazon S3 et les fichiers temporaires que les requêtes renvoient utilisent tous deux le stockage local de l'instance. Le NVMe local (disponible sur les instances de type d telles quedb.r8gd) est plus rapide qu'Amazon EBS dans les deux cas. Choisissez donc une classe avec un stockage NVMe local pour les charges de travail de production qui interrogent des tables étrangères.

• Isolation de la charge de travail : les requêtes de table étrangères sont en concurrence avec le reste du trafic de l'instance pour le processeur et la mémoire. Pour les charges de travail qui interrogent de manière intensive les tables étrangères, exécutez-les plutôt sur un lecteur dédié. Pour plus d’informations, consultez Utilisation d'une instance de lecteur dédiée pour les analyses.

Commencez par un cours adapté à votre charge de travail et adaptez-vous à partir de là en utilisant ces signaux.

• L'augmentation AuroraAnalyticsMemoryUsage signifie que la pression globale de la mémoire augmente. Passez à une classe d'instance plus grande ou à une classe inférieure query_mem pour laisser de la place à la simultanéité.

• L'augmentation AuroraAnalyticsDiskSpillSize signifie que le nombre de requêtes individuelles dépasse query_mem et se répercute sur le stockage local. Augmentez ou augmentez query_mem pour donner plus de place à chaque requête.

• Une chute AuroraAnalyticsCacheHitRatio signifie qu'une plus grande partie de vos données de travail est relue depuis Amazon S3. Une classe d'instance plus importante en met en cache une plus grande partie localement.

• Un processeur élevé lors de l'interrogation de tables étrangères signifie que les requêtes nécessitent davantage de vCPU.

Pour gérer un plus grand nombre de requêtes simultanées, augmentez la capacité de mémoire ou ajoutez un lecteur pour répartir la charge.

Pour connaître ces indicateurs et savoir comment les surveiller, consultezSurveillance et résolution des problèmes.

Quand utiliser les EBS-only instances

Les instances sans stockage NVMe local (tel que db.r8g etdb.r8i) utilisent Amazon EBS pour la mise en cache. Utilisez-les pour ce qui suit.

• Charges de travail plus sensibles aux coûts qu'aux performances.

• Requêtes de table étrangère légères ou ad hoc.

• Environnements de développement et de test.