Amélioration des performances des requêtes pour RDS for MySQL avec Amazon RDS Optimized Reads

Vous pouvez accélérer le traitement des requêtes pour RDS for MySQL avec Amazon RDS Optimized Reads. Une instance de base de données ou un cluster de bases de données multi-AZ RDS for MySQL qui utilise l'option RDS Optimized Reads peut traiter les requêtes jusqu'à 2 fois plus rapidement qu'une instance de base de données ou un cluster de bases de données qui ne l'utilise pas.

Présentation de RDS Optimized Reads

Lorsque vous utilisez une instance de base de données ou un cluster de bases de données multi-AZ RDS for MySQL avec l'option RDS Optimized Reads activée, les performances de requête sont plus rapides grâce à l'utilisation d'un stockage d'instances. Un stockage d'instances fournit un stockage temporaire de niveau bloc pour votre instance de base de données ou votre cluster de bases de données multi-AZ. Le stockage repose sur des disques SSD (Solid State Drive) NVMe (Non-Volatile Memory Express) qui sont physiquement attachés au serveur hôte. Ce stockage est optimisé pour une faible latence, de hautes performances d'E/S aléatoires et un haut débit de lecture séquentielle.

RDS Optimized Reads est activé par défaut lorsqu'une instance de base de données ou un cluster de bases de données multi-AZ utilise une classe d'instances de base de données avec un stockage d'instances, tel que db.m5d ou db.m6gd. Avec RDS Optimized Reads, certains objets temporaires sont stockés dans le stockage d'instances. Ces objets temporaires incluent des fichiers temporaires internes, des tables temporaires internes sur disque, des fichiers de mappage de mémoire et des fichiers de cache de journal binaire (binlog). Pour plus d'informations sur le stockage d'instances, consultez Stockage d'instances Amazon EC2 dans le Guide de l'utilisateur Amazon Elastic Compute Cloud pour les instances Linux.

Les charges de travail qui génèrent des objets temporaires dans MySQL pour le traitement des requêtes peuvent tirer parti du stockage d'instances pour accélérer le traitement des requêtes. Ce type de charge de travail inclut les requêtes impliquant des tris, des agrégations de hachage, des jointures à charge élevée, des expressions de table communes (CTE) et des requêtes sur des colonnes non indexées. Ces volumes de stockage d'instances fournissent des IOPS et des performances supérieures, quelles que soient les configurations de stockage utilisées pour le stockage Amazon EBS persistant. Étant donné que RDS Optimized Reads décharge les opérations sur les objets temporaires dans le stockage d'instances, les opérations d'entrée/sortie par seconde (IOPS) ou le débit du stockage persistant (Amazon EBS) peuvent désormais être utilisés pour les opérations sur les objets persistants. Ces opérations incluent des lectures et des écritures régulières de fichiers de données, ainsi que des opérations de moteur en arrière-plan, telles que le vidage et la fusion de mémoires tampon par insertion.

Note

Les instantanés RDS manuels et automatisés ne contiennent que des fichiers de moteur pour les objets persistants. Les objets temporaires créés dans le stockage d'instances ne sont pas inclus dans les instantanés RDS.

Cas d'utilisation pour RDS Optimized Reads

Si vous avez des charges de travail qui dépendent fortement d'objets temporaires, tels que des tables ou des fichiers internes, pour l'exécution de leurs requêtes, vous pouvez tirer parti de l'activation de RDS Optimized Reads. Les cas d'utilisation suivants sont propices à RDS Optimized Reads :

• Applications exécutant des requêtes analytiques avec des expressions de table communes (CTE), des tables dérivées et des opérations de regroupement complexes

• Réplicas en lecture qui traitent un trafic de lecture important avec des requêtes non optimisées

• Applications exécutant des requêtes de création de rapport à la demande ou dynamiques impliquant des opérations complexes, telles que des requêtes avec des clauses GROUP BY et ORDER BY

• Charges de travail utilisant des tables temporaires internes pour le traitement des requêtes

  Vous pouvez surveiller la variable de statut du moteur created_tmp_disk_tables pour déterminer le nombre de tables temporaires sur disque créées sur votre instance de base de données.

• Applications qui créent de grandes tables temporaires, directement ou dans le cadre de procédures, pour stocker des résultats intermédiaires

• Requêtes de base de données qui regroupent ou trient des colonnes non indexées

Bonnes pratiques relatives à RDS Optimized Reads

Utilisez les bonnes pratiques suivantes pour RDS Optimized Reads :

• Ajoutez une logique de nouvelle tentative pour les requêtes en lecture seule au cas où elles échoueraient en raison d'un stockage d'instances complet pendant l'exécution.

• Surveillez l'espace de stockage disponible sur le stockage d'instances à l'aide de la métrique CloudWatch FreeLocalStorage. Si le stockage d'instances atteint sa limite en raison de la charge de travail sur l'instance de base de données, modifiez l'instance de base de données pour utiliser une classe d'instances de base de données plus grande.

• Lorsque votre instance de base de données ou votre cluster de bases de données multi-AZ dispose de suffisamment de mémoire mais atteint toujours la limite de stockage sur le stockage d'instances, augmentez la valeur binlog_cache_size pour conserver en mémoire les entrées binlog spécifiques à la session. Cette configuration empêche l'écriture des entrées binlog dans les fichiers de cache binlog temporaires sur le disque.

  Le paramètre binlog_cache_size est spécifique à la session. Vous pouvez modifier cette valeur pour chaque nouvelle session. Le réglage de ce paramètre peut augmenter l'utilisation de la mémoire sur l'instance de base de données pendant les pics de charge de travail. Par conséquent, envisagez d'augmenter la valeur du paramètre en fonction du modèle de charge de travail de votre application et de la mémoire disponible sur l'instance de base de données.

• Utilisez la valeur par défaut MIXED pour binlog_format. En fonction de la taille des transactions, le réglage de binlog_format sur ROW peut entraîner la création de fichiers de cache binlog volumineux sur le stockage d'instances.

• Définissez le paramètre internal_tmp_mem_storage_engine sur TempTable et définissez le paramètre temptable_max_mmap pour qu'il corresponde à la taille du stockage disponible sur le stockage d'instances.

• Évitez d'effectuer des modifications en bloc dans une transaction unique. Ces types de transactions peuvent générer de gros fichiers de cache binlog sur le stockage d'instances et peuvent provoquer des problèmes lorsque le stockage d'instances est plein. Envisagez de diviser les écritures en plusieurs petites transactions afin de réduire au maximum l'utilisation de l'espace de stockage pour les fichiers de cache binlog.

• Utilisez la valeur par défaut de ABORT_SERVER pour le paramètre binlog_error_action. Cela évite les problèmes liés à la journalisation binaire sur les instances de base de données lorsque les sauvegardes sont activées.

Utilisation de RDS Optimized Reads

Lorsque vous provisionnez une instance de base de données RDS for MySQL avec l'une des classes d'instances de base de données suivantes dans le cadre d'un déploiement d'instance de base de données mono-AZ ou multi-AZ, ou d'un déploiement de cluster de bases de données multi-AZ, l'instance de base de données utilise automatiquement les lectures optimisées pour RDS.

Pour activer RDS Optimized Reads, effectuez l'une des actions suivantes :

• Créez une instance de base de données ou un cluster de bases de données multi-AZ RDS for MySQL en utilisant l'une de ces classes d'instances de base de données. Pour de plus amples informations, veuillez consulter Création d'une instance de base de données Amazon RDS.

• Modifiez une instance de base de données ou un cluster de bases de données multi-AZ RDS for MySQL existant afin d'utiliser l'une de ces classes d'instances de base de données. Pour de plus amples informations, veuillez consulter Modification d'une instance de base de données Amazon RDS.

La fonctionnalité Lectures optimisées pour RDS est disponible dans toutes les Régions AWS RDS où une ou plusieurs des classes d'instances de base de données avec stockage SSD NVMe local sont prises en charge. Pour plus d'informations sur les classes d'instances de base de données, consultez Classes d'instances de base de données .

La disponibilité des classes d'instance de base de données varie pour les Régions AWS. Pour déterminer si une classe d'instance de base de données est prise en charge dans une Région AWS spécifique, consultez Déterminer le support des classes d'instance de base de données dans Régions AWS.

Si vous ne souhaitez pas utiliser RDS Optimized Reads, modifiez votre instance de base de données ou votre cluster de bases de données multi-AZ, afin de ne pas utiliser une classe d'instances de base de données prenant en charge cette fonctionnalité.

Surveillance des instances de base de données qui utilisent RDS Optimized Reads

Vous pouvez surveiller les instances de base de données qui utilisent RDS Optimized Reads à l'aide des métriques CloudWatch suivantes :

• FreeLocalStorage

• ReadIOPSLocalStorage

• ReadLatencyLocalStorage

• ReadThroughputLocalStorage

• WriteIOPSLocalStorage

• WriteLatencyLocalStorage

• WriteThroughputLocalStorage

Ces métriques fournissent des données sur le stockage disponible dans le stockage d'instances, les IOPS et le débit. Pour plus d'informations sur ces métriques, consultez Mesures au CloudWatch niveau de l'instance Amazon pour Amazon RDS.

Limites pour RDS Optimized Reads

Les limites suivantes s'appliquent à RDS Optimized Reads :

• RDS Optimized Reads est pris en charge pour RDS for MySQL versions 8.0.28 et ultérieures. Pour obtenir des informations sur les versions de RDS for MySQL, consultez Versions de MySQL sur Amazon RDS.

• Vous ne pouvez pas remplacer l'emplacement des objets temporaires par un stockage persistant (Amazon EBS) dans les classes d'instances de base de données qui prennent en charge RDS Optimized Reads.

• Lorsque la journalisation binaire est activée sur une instance de base de données, la taille maximale des transactions est limitée par la taille du stockage d'instances. Pour MySQL, toute session qui nécessite plus de stockage que la valeur de binlog_cache_size écrit les modifications des transactions dans les fichiers de cache de journaux binaires temporaires, qui sont créés dans le stockage d'instances.

• Les transactions peuvent échouer lorsque le stockage d'instances est plein.