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.
Amélioration des performances des requêtes pour RDS for MariaDB avec Amazon RDS Optimized Reads
Vous pouvez accélérer le traitement des requêtes pour RDS for MariaDB avec Amazon RDS Optimized Reads. Une instance de base de données RDS for MariaDB qui utilise RDS Optimized Reads peut traiter les requêtes jusqu'à 2 fois plus rapidement qu'une instance de base de données qui ne l'utilise pas.
Rubriques
Présentation de RDS Optimized Reads
Lorsque vous utilisez une instance de base de données RDS for MariaDB sur laquelle RDS Optimized Reads est activé, votre instance de base de données présente des performances de requête plus rapides grâce à l'utilisation d'un stockage d'instances. Un stockage d'instance fournit un stockage temporaire de niveau bloc pour votre instance de base de données. 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 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 MariaDB 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
etORDER 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 magasin d'instances à l'aide de la CloudWatch métrique
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 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
pourbinlog_format
. En fonction de la taille des transactions, le réglage debinlog_format
surROW
peut entraîner la création de fichiers de cache binlog volumineux 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.
Utilisation de RDS Optimized Reads
Lorsque vous provisionnez une instance de base de données RDS for MariaDB 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, 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 RDS for MariaDB en utilisant l'une de ces classes d'instances de base de données. Pour plus d’informations, consultez Création d'une RDS instance de base de données Amazon.
-
Modifiez une instance de base de données RDS for MariaDB afin d'utiliser l'une de ces classes d'instances de base de données. Pour plus d’informations, consultez Modification d'une RDS instance de base de données Amazon.
Les lectures optimisées RDS sont disponibles partout Régions AWS où une ou plusieurs 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'instances de base de données diffère pour Régions AWS. Pour déterminer si une classe d'instance de base de données est prise en charge dans une classe spécifique Région AWS, consultezDé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 afin qu'elle n'utilise pas 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 des lectures optimisées RDS avec les CloudWatch métriques 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 Métriques 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 les versions RDS for MariaDB suivantes :
-
10.11.4 et versions 10.11 ultérieures
-
Versions 10.6.7 et 10.6 ultérieures
-
Versions 10.5.16 et 10.5 ultérieures
-
Versions 10.4.25 et 10.4 ultérieures
Pour obtenir des informations sur les versions de RDS for MariaDB, consultez Versions de MariaDB 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 MariaDB, 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.