Stockage d'instance de base de données Amazon RDS - Amazon Relational Database Service
Types de stockageStockage sur volumes IOPS provisionnésStockage à usage généralCaractéristiques des performances SSDStockage magnétique (obsolète)Volume dédié aux journaux (DLV)Surveillance des performances de base de donnéesFacteurs ayant un impact sur les performances de base de données

Stockage d'instance de base de données Amazon RDS

Les instances de base de données pour Amazon RDS for Db2, MariaDB, MySQL, PostgreSQL, Oracle et Microsoft SQL Server utilisent les volumes Amazon Elastic Block Store (Amazon EBS) pour le stockage des bases de données et des journaux.

Dans certains cas, la charge de travail de votre base de données ne sera peut-être pas capable d'atteindre 100 % des IOPS que vous avez provisionnés. Pour plus d’informations, consultez Facteurs ayant un impact sur les performances de base de données.

Pour plus d’informations sur la tarification du stockage d’instance, consultez Tarification d’Amazon RDS.

Types de stockage Amazon RDS

Amazon RDS propose trois types de stockage : SSD à IOPS provisionnées (également appelé io1 et io2 Block Express), SSD à usage général (également gp2 et gp3) et magnétique (également appelé standard). Ils se distinguent par leurs caractéristiques de performance et leur tarif, ce qui signifie que vous avez la possibilité d'adapter vos performances de stockage et vos coûts à vos besoins en matière de charge de travail de base de données. Vous pouvez créer des instances de base de données RDS Db2, MySQL, MariaDB, Oracle, SQL Server et PostgreSQL avec un maximum de 64 tébioctets (Tio) de stockage. RDS for Db2 ne prend pas en charge les types de stockage gp2 et magnétique.

La liste suivante décrit rapidement les trois types de stockage :

  • SSD à IOPS provisionnées : le stockage à IOPS provisionnées est conçu pour satisfaire les besoins des charges de travail gourmandes en E/S, notamment les charges de travail de base de données qui requièrent une faible latence des E/S et un débit d’E/S homogène. Le stockage d'IOPS provisionnés convient le mieux aux environnements de production.

    Pour plus d'informations sur le stockage d'IOPS provisionnés, y compris les plages de tailles de stockage, consultez Stockage SSD à IOPS provisionnées.

  • SSD à usage général : les volumes SSD à usage général offrent un stockage économique, idéal pour un large éventail de charges de travail exécutées sur des instances de base de données de taille moyenne. Le stockage à usage général convient le mieux aux environnements de développement et de test.

    Pour plus d'informations sur le stockage SSD à usage général, y compris les plages de tailles de stockage, consultez Stockage SSD à usage général.

  • Magnétique – Amazon RDS prend également en charge le stockage magnétique pour assurer la rétrocompatibilité. Nous vous recommandons d’utiliser le stockage SSD à usage général ou à IOPS provisionnées pour tout nouveau besoin de stockage. La capacité maximale de stockage autorisée pour les instances de base de données sur le stockage magnétique est de 3 Tio. Pour plus d’informations, consultez Stockage magnétique (obsolète).

Stockage SSD à IOPS provisionnées

Pour une application de production nécessitant des performances d'E/S rapides et cohérentes, nous recommandons d'utiliser le stockage des IOPS provisionnés. Le stockage des IOPS provisionnés est un type de stockage qui offre des performances de débit prévisibles et une faible latence homogène. Le stockage IOPS provisionnées est optimisé pour les charges de travail de traitement transactionnel en ligne (OLTP) ayant des exigences de performances régulières. Les IOPS provisionnés aident à ajuster ces charges de travail.

Amazon RDS propose deux types de stockage SSD à IOPS provisionnées : io2 et io1. Lorsque vous créez une instance de bases de données, vous spécifiez le taux d'IOPS et la taille du volume. Amazon RDS fournit ce taux d'IOPS pour l'instance de base de données jusqu'à ce que vous le changiez.

Stockage io2 Block Express (recommandé)

Pour les charges de travail gourmandes en E/S et sensibles à la latence, vous pouvez utiliser le stockage SSD à IOPS provisionnées io2 Block Express et réaliser jusqu’à 256 000 opérations d’E/S par seconde (IOPS). Le débit des volumes io2 Block Express varie en fonction de la quantité d’IOPS provisionnées par volume et de la taille des opérations d’E/S en cours d’exécution.

Tous les volumes RDS io2 basés sur le système Nitro AWS sont des volumes io2 Block Express et offrent une latence moyenne inférieure à la milliseconde. Les instances de base de données non basées sur le système Nitro AWS sont des volumes io2.

La table suivante affiche la plage des IOPS provisionnées et le débit maximal pour chaque plage du moteur de base de données et de taille de stockage.

Moteur de base de données Plage de tailles de stockage Plage d’IOPS provisionnées Débit maximal
Db2, MariaDB, MySQL et PostgreSQL 100 à 65 536 Gio 1 000 à 256 000 IOPS 16 000 Mio/s
Oracle 100 à 199 Gio 1 000 à 199 000 IOPS 4 000 Mio/s
Oracle 200 à 65 536 Gio 1 000 à 256 000 IOPS 16 000 Mio/s
SQL Server 20 à 65 536 Gio 1 000 à 256 000 IOPS 4 000 Mio/s

Les plages d’IOPS et de taille de stockage obéissent aux contraintes suivantes :

  • Le rapport entre les IOPS et le stockage alloué (en Gio) doit être compris entre 0,5 et 1 000. Pour les instances de base de données non basées sur le système Nitro AWS, le ratio doit être compris entre 0,5 et 500.

  • Les IOPS maximaux peuvent être provisionnés avec des volumes de 256 Gio et plus (1 000 IOPS × 256 Gio = 256 000 IOPS). Pour les instances de base de données non basées sur le système Nitro AWS, le nombre maximal d’IOPS est atteint à 512 Gio (500 IOPS x 512 Gio = 256 000 IOPS).

  • Le débit évolue de manière proportionnelle jusqu’à 0,256 Mio/s par IOPS provisionnées. Un débit maximal de 4 000 Mio/s peut être atteint à 256 000 IOPS avec une taille d’E/S de 16 Kio et de 16 000 IOPS ou plus avec une taille d’E/S de 256 Kio. Pour les instances de base de données non basées sur le système Nitro AWS, un débit maximal de 2 000 Mio/s peut être atteint à 128 000 IOPS avec une taille d’E/S de 16 Kio.

  • Si vous utilisez la mise à l’échelle automatique du stockage, les mêmes rapports entre les IOPS et le seuil de stockage maximum (en Go) s’appliquent également. Pour plus d’informations sur la mise à l’échelle automatique du stockage, consultez Gestion automatique de la capacité avec le dimensionnement automatique du stockage Amazon RDS.

Les volumes io2 Block Express Amazon RDS sont disponibles dans toutes les régions AWS commerciales et dans la région GovCloud AWS (USA). Ces volumes ne sont pas disponibles dans la région Chine.

Stockage io1 (génération précédente)

Pour les charges de travail gourmandes en I/O, vous pouvez utiliser le stockage SSD à IOPS provisionnées io1 et réaliser jusqu’à 256 000 opérations d’I/O par seconde (IOPS). Le débit des volumes io1 varie en fonction de la quantité d’IOPS provisionnées par volume et de la taille des opérations d’E/S en cours d’exécution. Nous vous recommandons d’utiliser le stockage io2 Block Express lorsqu’il est disponible.

La table suivante affiche la plage des IOPS provisionnées et le débit maximal pour chaque plage du moteur de base de données et de taille de stockage.

Moteur de base de données Plage de tailles de stockage Plage d’IOPS provisionnées Débit maximal
Db2, MariaDB, MySQL et PostgreSQL 100 à 399 Gio 1 000 à 19 950 IOPS 500 Mio/s
Db2, MariaDB, MySQL et PostgreSQL 400 à 65 536 Gio 1 000 à 256 000 IOPS 4 000 Mio/s
Oracle 100 à 199 Gio 1 000 à 9 950 IOPS 500 Mio/s
Oracle 200 à 65 536 Gio 1 000 à 256 000 IOPS¹ 4 000 Mio/s
SQL Server 20 à 16 384 Gio 1 000 à 64 000 IOPS² 1 000 Mio/s
Note

¹ Pour Oracle, vous pouvez allouer le nombre maximal de 256 000 IOPS uniquement sur le type d’instance r5b.

² Pour SQL Server, le nombre maximal de 64 000 IOPS est garanti uniquement sur les instances basées sur Nitro qui se trouvent sur les types d’instance m5*, m6i, r5*, r6i et z1d. D'autres types d'instances garantissent des performances allant jusqu'à 32 000 IOPS.

Les plages d’IOPS et de taille de stockage obéissent aux contraintes suivantes :

  • Le rapport entre les IOPS et le stockage alloué (en Gio) doit être de 1 à 50 sur RDS for SQL Server et de 0,5 à 50 sur les autres moteurs de base de données RDS.

  • Si vous utilisez la mise à l’échelle automatique du stockage, les mêmes rapports entre les IOPS et le seuil de stockage maximum (en Go) s’appliquent également.

    Pour plus d’informations sur la mise à l’échelle automatique du stockage, consultez Gestion automatique de la capacité avec le dimensionnement automatique du stockage Amazon RDS.

Combinaison du stockage des IOPS provisionnés aux déploiements multi-AZ ou aux réplicas en lecture

Pour les cas d'utilisation de traitement de transaction en ligne (OLTP) de production, nous vous recommandons d'utiliser des déploiements multi-AZ, pour profiter d'une meilleure tolérance aux pannes et d'un meilleur stockage des IOPS provisionnés, et ainsi bénéficier de performances rapides et prévisibles.

Vous pouvez également utiliser le stockage des IOPS provisionnées avec les réplicas en lecture pour MySQL, MariaDB ou PostgreSQL. Le type de stockage pour un réplica en lecture est indépendant de celui de l'instance de base de données principale. Par exemple, vous pouvez utiliser le stockage SSD à usage général pour les réplicas en lecture avec une instance de base de données principale qui utilise le stockage SSD à IOPS provisionnées afin de réduire les coûts. Dans ce cas toutefois, les performances de vos réplicas en lecture peuvent différer de ceux d’une configuration où l’instance de base de données principale et les réplicas en lecture utilisent tous deux le stockage d’IOPS provisionnées.

Coûts du stockage IOPS provisionnées

Avec le stockage d'IOPS provisionnés, vous devez payer pour les ressources provisionnées, que vous les utilisiez ou non au cours d'un mois donné.

Pour plus d’informations sur la tarification, consultez Tarification d’Amazon RDS.

Optimisation des performances du stockage des IOPS provisionnées Amazon RDS

Si votre charge de travail est limitée en E/S, l’utilisation du stockage d’IOPS provisionnées peut augmenter le nombre de demandes d’E/S pouvant être traitées simultanément par le système. L'augmentation de la simultanéité permet de réduire la latence, étant donné que les demandes I/O passent moins de temps en file d'attente. La réduction de la latence permet des validations de base de données plus rapides, ce qui améliore le temps de réponse et augmente le débit de la base de données.

Le stockage d’IOPS provisionnées permet de réserver la capacité d’E/S en spécifiant les IOPS. Toutefois, comme avec tout autre attribut de capacité système, le débit maximal sous charge sera limité par la ressource qui sera utilisée en premier. Cette ressource peut être la bande passante réseau, l'UC, la mémoire ou les ressources internes de la base de données.

Stockage SSD à usage général

Le stockage à usage général offre un stockage économique qui est approprié pour la plupart des charges de travail de base de données qui ne sont pas sensibles à la latence ou aux performances.

Note

Les instances de base de données qui utilisent un stockage à usage général peuvent connaître une latence beaucoup plus longue que les instances qui utilisent un stockage d’IOPS provisionnées. Si vous avez besoin d'une instance de base de données avec une latence minimale après ces opérations, nous vous recommandons d'utiliser Stockage SSD à IOPS provisionnées.

Amazon RDS propose deux types de stockage à usage général : Stockage gp3 (recommandé) et Stockage gp2 (génération précédente).

Stockage gp3 (recommandé)

En utilisant des volumes de stockage gp3 à usage général, vous pouvez personnaliser les performances de stockage indépendamment de la capacité de stockage. Les performances de stockage correspondent à la combinaison des opérations d'entrée/sortie par seconde (IOPS) et de la rapidité avec laquelle le volume de stockage peut effectuer des opérations de lecture et d'écriture (débit de stockage). Sur les volumes de stockage gp3, Amazon RDS fournit des performances de stockage de base de 3 000 IOPS et 125 Mio/s.

Pour chaque moteur de base de données RDS, à l’exception de RDS for SQL Server, quand la taille de stockage des volumes gp3 atteint un certain seuil, les performances de stockage de base augmentent. Cela est dû à la répartition en bandes des volumes, selon laquelle le stockage utilise quatre volumes à la place d'un seul. RDS for SQL Server ne prend pas en charge la répartition en bandes des volumes et n'a donc pas de valeur de seuil. Sur les volumes agrégés par bandes, Amazon RDS fournit des performances de stockage de base de 12 000 IOPS et 500 Mio/s.

Les performances de stockage des volumes gp3 sur les moteurs de base de données Amazon RDS, y compris le seuil, sont présentées dans le tableau suivant.

Moteur de base de données Taille de stockage Performances de stockage de base Plage d’IOPS provisionnées Plage de débits de stockage provisionnés
Db2, MariaDB, MySQL et PostgreSQL 20 à 399 Gio 3 000 IOPS/125 Mio/s N/A N/A
Db2, MariaDB, MySQL et PostgreSQL 400 à 65 536 Gio 12 000 IOPS/500 Mio/s 12 000 à 64 000 IOPS 500 à 4 000 Mio/s
Oracle 20 à 199 Gio 3 000 IOPS/125 Mio/s N/A N/A
Oracle 200 à 65 536 Gio 12 000 IOPS/500 Mio/s 12 000 à 64 000 IOPS 500 à 4 000 Mio/s
SQL Server 20 à 16 384 Gio 3 000 IOPS/125 Mio/s 3 000 à 16 000 IOPS 125 à 1 000 Mio/s

Pour chaque moteur de base de données, à l'exception de RDS for SQL Server, vous pouvez allouer des IOPS et un débit de stockage supplémentaires lorsque la taille de stockage est égale ou supérieure à la valeur seuil. Pour RDS for SQL Server, vous pouvez allouer des IOPS et un débit de stockage supplémentaires pour n'importe quelle taille de stockage disponible. Pour tous les moteurs de base de données, vous ne payez que pour les performances de stockage provisionnées supplémentaires. Pour plus d'informations, consultez Tarification d'Amazon RDS.

Bien que les IOPS provisionnés et le débit de stockage ajoutés ne dépendent pas de la taille de stockage, ils sont liés les uns aux autres. Lorsque vous augmentez les IOPS au-dessus de 32 000 pour MariaDB et MySQL, la valeur du débit de stockage augmente automatiquement à partir de 500 Mio/s. Par exemple, lorsque vous définissez les IOPS à 40 000 sur RDS for MySQL, le débit de stockage doit être d'au moins 625 Mio/s. L’augmentation automatique ne se produit pas pour les instances de base de données Db2, Oracle, PostgreSQL et SQL Server.

Pour les clusters de bases de données multi-AZ, Amazon RDS définit automatiquement la valeur du débit en fonction des IOPS que vous fournissez. Vous ne pouvez pas modifier la valeur du débit.

Les valeurs de performances de stockage pour les volumes gp3 sur RDS sont soumises aux contraintes suivantes :

  • Le rapport maximal entre le débit de stockage et les IOPS est de 0,25 pour tous les moteurs de base de données pris en charge.

  • Le rapport minimal entre les IOPS et le stockage alloué (en Gio) est de 0,5 sur RDS for SQL Server. Il n'y a pas de rapport minimal pour les autres moteurs de base de données pris en charge.

  • Le rapport maximal entre les IOPS et le stockage alloué est de 500 pour tous les moteurs de base de données pris en charge.

  • Si vous utilisez la mise à l’échelle automatique du stockage, les mêmes rapports entre les IOPS et le seuil de stockage maximum (en Go) s’appliquent également.

    Pour plus d’informations sur la mise à l’échelle automatique du stockage, consultez Gestion automatique de la capacité avec le dimensionnement automatique du stockage Amazon RDS.

Stockage gp2 (génération précédente)

Lorsque vos applications n'ont pas besoin de performances de stockage élevées, vous pouvez utiliser le stockage SSD à usage général gp2. Les performances d'E/S de base pour le stockage gp2 sont de 3 IOPS pour chaque Gio, avec un minimum de 100 IOPS. Cette relation signifie que des volumes plus importants obtiennent de meilleures performances. Par exemple, les performances de base pour un volume de 100 Gio sont de 300 IOPS. Les performances de base pour un volume de 1 000 Gio sont de 3 000 IOPS.

Les volumes gp2 individuels inférieurs à 1 000 Gio peuvent également atteindre 3 000 IOPS pendant des périodes de temps étendues. Le solde de crédit des E/S du volume détermine les performances de la rafale. Pour obtenir une description plus complète de l'impact des performances de base et du solde de crédits d'E/S sur les performances, consultez le billet de blog Understanding Burst vs. Baseline Performance with Amazon RDS and GP2 (Comprendre les performances de rafale et de base avec Amazon RDS et GP2) dans le blog AWS Database.

De nombreuses charges de travail n'épuisent jamais le solde de rafale. Toutefois, certaines charges de travail peuvent épuiser le solde de crédit d’E/S de rafale de 3 000 IOPS. En conséquence, prévoyez votre capacité de stockage de sorte qu’elle corresponde aux besoins de vos charges de travail.

Pour les volumes gp2 d’une taille supérieure à 4 000 Gio, les performances de base sont supérieures aux performances en rafale. Pour de tels volumes, le mode rafale est sans intérêt dans la mesure où les performances de références dépassent les performances en rafale (3 000 IOPS). Toutefois, pour les instances de base de données de certains moteurs et de certaines tailles, le stockage est réparti sur quatre volumes, ce qui fournit quatre fois le débit de base et quatre fois le débit d'IOPS en rafale d'un seul volume.

Les performances de stockage des volumes gp2 de tailles de stockage différentes sur les moteurs de base de données Amazon RDS, sont présentées dans le tableau suivant.

Moteur de base de données Taille de stockage RDS Plage des IOPS de base Plage du débit de base IOPS en rafale
MariaDB, MySQL et PostgreSQL 5 à 399 Gio 100 à 1 197 IOPS 128 à 250 Mio/s 3 000
MariaDB, MySQL et PostgreSQL 400 à 1 335 Gio 1 200 à 4 005 IOPS 512 à 1 000 Mio/s 12 000
MariaDB, MySQL et PostgreSQL 1 336 à 3 999 Gio 4 008 à 11 997 IOPS 1 000 Mio/s 12 000
MariaDB, MySQL et PostgreSQL 4 000 à 65 536 Gio 12 000 à 64 000 IOPS 1 000 Mio/s S/O¹
Oracle 20 à 199 Gio 100 à 597 IOPS 128 à 250 Mio/s 3 000
Oracle 200 à 1 335 Gio 600 à 4 005 IOPS 512 à 1 000 Mio/s 12 000
Oracle 1 336 à 3 999 Gio 4 008 à 11 997 IOPS 1 000 Mio/s 12 000
Oracle 4 000 à 65 536 Gio 12 000 à 64 000 IOPS 1 000 Mio/s S/O¹
SQL Server 20 à 333 Gio 100 à 999 IOPS 128 à 250 Mio/s 3 000
SQL Server 334 à 999 Gio 1 002 à 2 997 IOPS 250 Mio/s 3 000
SQL Server 1 000 à 16 384 Gio 3 000 à 16 000 IOPS 250 Mio/s S/O¹

¹ Les performances de base du volume dépassent celles en rafale maximales.

Caractéristiques de performance des types de stockage SSD (Solid State Drive)

Le tableau suivant décrit les cas d’utilisation et les caractéristiques de performances par volume de stockage SSD utilisés par Amazon RDS.

Caractéristiques IOPS provisionnées (io2 Block Express) IOPS provisionnées (io1) Usage général (gp3) Usage général (gp2)
Description

Performances les plus élevées du portefeuille de stockage RDS (IOPS, débit, latence)

Conçu pour les charges de travail transactionnelles sensibles à la latence

Performances de stockage constantes (IOPS, débit, latence)

Conçu pour les charges de travail transactionnelles sensibles à la latence

Flexibilité d'allocation indépendante du stockage, des IOPS et du débit

Équilibre les performances de prix pour un large éventail de charges de travail transactionnelles

Fournit des IOPS pouvant être émis en rafale

Équilibre les performances de prix pour un large éventail de charges de travail transactionnelles
Cas d’utilisation

Charges de travail transactionnelles critiques nécessitant une latence inférieure à la milliseconde et des performances d’IOPS soutenues allant jusqu’à 256 000 IOPS

Charges de travail de travail transactionnelles nécessitant des performances d'IOPS soutenues allant jusqu'à 256 000 IOPS

Large plage de charges de travail exécutées sur des bases de données relationnelles de taille moyenne dans des environnements de développement/test

Large plage de charges de travail exécutées sur des bases de données relationnelles de taille moyenne dans des environnements de développement/test
Latence

Inférieure à la milliseconde, fournie de manière constante 99,9 % du temps

Moins de 10 millisecondes, fournies de manière constante 99,9 % du temps

Moins de 10 millisecondes, fournies de manière constante 99 % du temps

Moins de 10 millisecondes, fournies de manière constante 99 % du temps
Taille du volume

100 à 65 536 Gio

100 à 65 536 Gio (20 à 16 384 Gio sur RDS for SQL Server)

20 à 65 536 Gio (16 384 Gio sur RDS for SQL Server)

20 à 65 536 Gio (16 384 Gio sur RDS for SQL Server)
Nombre maximal d’IOPS

256 000

256 000 (64 000 sur RDS for SQL Server)

64 000 (16 000 sur RDS for SQL Server)

64 000 (16 000 sur RDS for SQL Server)

Note

Vous ne pouvez pas allouer les IOPS directement sur le stockage gp2. Le nombre d'IOPS varie en fonction de la taille de stockage allouée.
Débit maximal

Évolue en fonction des IOPS provisionnées jusqu’à 4 000 Mo/s

Le débit évolue de manière proportionnelle jusqu’à 0,256 Mio/s par IOPS provisionnées. Un débit maximal de 4 000 Mio/s peut être atteint à 256 000 IOPS avec une taille d’E/S de 16 Kio et de 16 000 IOPS ou plus avec une taille d’E/S de 256 Kio.

Pour les instances non basées sur le système Nitro AWS, un débit maximal de 2 000 Mio/s peut être atteint à 128 000 IOPS avec une taille d’E/S de 16 Kio.

Évolue en fonction des IOPS provisionnées jusqu’à 4 000 Mo/s

Allocation d’un débit supplémentaire pouvant atteindre 4 000 Mo/s (1000 Mo/s sur RDS for SQL Server)

1 000 Mo/s (250 Mo/s sur RDS for SQL Server)
Nom AWS CLI et d'API RDS io2 io1 gp3 gp2

Répartition automatique entre les volumes SSD

Lorsque vous sélectionnez un SSD à usage général ou un SSD à IOPS provisionnées, en fonction du moteur sélectionné et de la quantité de stockage demandée, Amazon RDS répartit automatiquement plusieurs volumes pour améliorer les performances, comme indiqué dans le tableau suivant.

Moteur de base de données Taille de stockage Amazon RDS Nombre de volumes provisionnés
Db2 Moins de 400 Gio 1
Db2 400 à 65 536 Gio 4
MariaDB, MySQL et PostgreSQL Moins de 400 Gio 1
MariaDB, MySQL et PostgreSQL 400 à 65 536 Gio 4
Oracle Moins de 200 Gio 1
Oracle 200 à 65 536 Gio 4
SQL Server N’importe quel compte 1

Impact sur les performances lorsque vous modifiez un volume SSD

Lorsque vous modifiez un volume SSD à usage général ou SSD à IOPS provisionnées, il passe par différents états. Lorsque le volume a l’état optimizing, ses performances se situent entre les spécifications de configuration source et les spécifications de configuration cible. Les performances de volume transitoires ne sont jamais inférieures à la spécification la plus basse des deux.

Lorsque vous modifiez le stockage d’une instance pour qu’’il passe d’un à quatre volumes, ou lorsque vous modifiez une instance à l’aide du stockage magnétique, Amazon RDS n’utilise pas la fonctionnalité Elastic Volumes. Amazon RDS provisionne plutôt de nouveaux volumes et déplace de manière transparente les données de l'ancien volume vers les nouveaux. Cette opération consomme une quantité importante d'IOPS et de débit des anciens et des nouveaux volumes. En fonction de la taille du volume et de la quantité de charge de travail de la base de données présente lors de la modification, cette opération peut consommer un grand nombre d’IOPS, augmenter considérablement la latence des E/S et prendre plusieurs heures, alors que l’instance RDS reste à l’état Modifying.

Taux d’IOPS de base et taux d’IOPS maximal pour les instances optimisées pour EBS

Les instances optimisées pour EBS ont un taux d’IOPS de base et un taux d’IOPS maximal. Le taux maximal d’IOPS est appliqué au niveau de l’instance de base de données. Un ensemble de volumes EBS dont la combinaison donne un taux d’IOPS supérieur au maximum ne peut pas dépasser le seuil au niveau de l’instance. Par exemple, si le nombre maximal d’IOPS pour une classe d’instance de base de données précise est de 40 000 et que vous attachez quatre volumes EBS de 64 000 IOPS, le nombre maximal d’IOPS est de 40 000 au lieu de 256 000. Pour connaître le nombre maximal d’IOPS propre à chaque type d’instance EC2, consultez Types d’instance pris en charge dans le Guide de l’utilisateur Amazon EC2 pour les instances Linux.

Stockage magnétique (obsolète)

Amazon RDS ne prend plus en charge le stockage magnétique. Nous vous recommandons d’utiliser le stockage SSD à usage général ou à IOPS provisionnées pour votre besoin de stockage.

Volume dédié aux journaux (DLV)

Vous pouvez utiliser un volume dédié aux journaux (DLV) pour une instance de base de données qui utilise le stockage IOPS provisionnés (PIOPS) en utilisant la console Amazon RDS, l’AWS CLI ou l’API Amazon RDS. Un DLV déplace les journaux de transactions de base de données, les journaux de rétablissement MySQL/MariaDB et les journaux binaires vers un volume de stockage distinct du volume contenant les tables de base de données. Un DLV rend l’enregistrement des écritures de transactions plus efficace et plus cohérent. Les DLV sont idéaux pour les bases de données présentant un stockage alloué important, des exigences élevées en matière d’E/S par seconde (IOPS) ou des charges de travail sensibles à la latence.

Les DLV sont pris en charge pour le stockage PIOPS (io1 et io2 Block Express) et sont créés avec une taille fixe de 1 024 Gio et 3 000 IOPS provisionnées.

Note

Les DLV ne sont pas pris en charge pour le stockage à usage général (gp2 et gp3).

Amazon RDS prend en charge les DLV dans toutes les Régions AWS pour les versions suivantes :

  • MariaDB 10.6.7 et versions 10 ultérieures

  • MySQL 8.0.28 et versions 8.0 ultérieures, MySQL 8.4.3 et versions 8.4 ultérieures

  • PostgreSQL 13.10 et versions 13 ultérieures, 14.7 et versions 14 ultérieures, 15.2 et versions 15 ultérieures, et 16.1 et versions 16 ultérieures

RDS prend en charge les DLV avec déploiements multi-AZ. Lorsque vous modifiez ou créez une instance multi-AZ, un DLV est créé à la fois pour l'instance principale et pour l'instance secondaire.

RDS prend en charge les DLV avec réplicas en lecture. Si un DLV est activé sur l'instance de base de données principale, tous les réplicas en lecture créés après l'activation du DLV auront également un DLV. Il ne sera pas activé sur les réplicas en lecture créés avant le passage au DLV, sauf s'il est explicitement modifié à cet effet. Nous recommandons que tous les réplicas en lecture attachés à une instance principale avant l'activation du DLV soient également modifiés manuellement pour avoir un DLV.

Après la modification du paramètre DLV d'une instance de base de données, l'instance doit être redémarrée.

Pour en savoir plus sur l’activation d’un DLV, consultez Utilisation d’un volume dédié aux journaux (DLV).

Surveillance des performances de base de données

Amazon RDS propose différentes métriques pour déterminer les performances de votre instance de bases de données. Vous pouvez consulter les métriques sur la page de résumé de votre instance sur l'Amazon RDS Management Console. Vous pouvez également utiliser Amazon CloudWatch pour contrôler ces métriques. Pour plus d’informations, consultez Affichage des métriques dans la console Amazon RDS. La surveillance améliorée offre des métriques d'I/O plus détaillées. Pour plus d'informations, consultez Surveillance des métriques du système d'exploitation à l'aide de la Surveillance améliorée.

Les métriques suivantes sont utiles pour surveiller les performances de votre instance de base de données :

  • DiskQueueDepth : nombre de demandes d’E/S dans la file d’attente en attente de traitement. Ces demandes d'I/O ont été envoyées par l'application, mais n'ont pas été envoyées à l'appareil, car ce dernier est occupé à traiter d'autres demandes d'I/O. Le temps passé dans une file d'attente est un élément de la latence et du temps de service (non disponible en tant que métrique). Cette métrique est rapportée comme étant la profondeur de file d'attente moyenne pour un intervalle de temps donné. Amazon RDS fait état de la profondeur de file d’attente par intervalles d’une minute. Les valeurs habituelles pour la longueur de file d'attente vont de zéro à plusieurs centaines.

  • EBSByteBalance% : pourcentage de crédits de débit restant dans le compartiment en rafales de votre base de données RDS. Cette métrique est disponible uniquement pour la surveillance basique. La valeur de la métrique est basée sur le débit de tous les volumes, y compris le volume racine, plutôt que sur les seuls volumes contenant des fichiers de base de données.

    Lorsque cette métrique approche zéro, cela signifie que la capacité de calcul de votre instance de base de données est épuisée. Si cela se produit régulièrement, envisagez de passer à une taille de classe d’instance plus grande, par exemple de db.r6g.large à db.r6g.xlarge. Pour plus d’informations, consultez Classe d’instance de base de données.

  • ReadIOPS et WriteIOPS : nombre d’opérations d’E/S terminées par seconde. Cette métrique est rapportée comme étant le nombre moyen d'IOPS pour un intervalle de temps donné. Amazon RDS fait état des IOPS de lecture et d’écriture séparément et par intervalles d’une minute. TotalIOPS est la somme des IOPS de lecture et d’écriture. Les valeurs habituelles pour les IOPS vont de zéro à des dizaines de milliers par seconde.

    Si vos valeurs TotalIOPS se rapprochent régulièrement de la valeur d’IOPS provisionnées que vous avez définie pour votre instance de base de données, envisagez d’augmenter les IOPS provisionnées (types de stockage io1, io2 Block Express et gp3).

    Les valeurs d'IOPS mesurées sont indépendantes de la taille de l'opération d'I/O individuelle. Cela signifie que lorsque vous mesurez les performances d'E/S, vous devez examiner le débit de l'instance, et pas simplement le nombre d'opérations d'E/S.

  • ReadLatency et WriteLatency : temps écoulé entre l’envoi d’une demande d’E/S et sa fin. Cette métrique est rapportée comme étant la latence moyenne pour un intervalle de temps donné. Amazon RDS fait état de la latence de lecture et d'écriture séparément par intervalles d'une minute. Les valeurs de latence sont généralement exprimées en millisecondes (ms).

  • ReadThroughput et WriteThroughput : nombre d’octets transférés chaque seconde depuis et vers le disque. Cette métrique est rapportée comme étant le débit moyen pour un intervalle de temps donné. Amazon RDS fait état du débit de lecture et d’écriture séparément par intervalles d’une minute en utilisant des unités d’octets par seconde (O/s). Les valeurs habituelles pour le débit vont de zéro à la taille maximale de la bande passante du canal d'I/O.

    Si vos valeurs de débit approchent régulièrement le débit maximal de votre instance de base de données, envisagez de fournir un débit de stockage supérieur si vous utilisez le type de stockage gp3.

Facteurs ayant un impact sur les performances de base de données

Les activités du système, la charge de travail de la base de données et l’instance de base de données peuvent affecter les performances de stockage.

Activités du système

Les activités suivantes liées au système utilisent de la capacité d'I/O et peuvent réduire les performances de l'instance de bases de données lorsqu'elles s'exécutent :

  • Création de veille Multi-AZ

  • Création d'un réplica en lecture

  • Modification des types de stockage

Charge de travail d'une base de données

Dans certains cas, la conception de votre base de données ou application entraîne des problèmes de simultanéité, des verrouillages ou d'autres formes de conflit de base de données. Vous pouvez alors rencontrer des difficultés pour utiliser toute la bande passante provisionnée directement. De plus, vous pouvez rencontrer les situations suivantes liées aux charges de travail :

  • La limite de débit du type d'instance sous-jacent a été atteinte.

  • La longueur de la file d'attente est constamment inférieure à 1 car votre application ne traite pas suffisamment d'opérations d'E/S.

  • Vous rencontrez un conflit de requête dans la base de données même si une partie de la capacité d'I/O n'est pas utilisée.

Dans certains cas, aucune ressource du système n'a atteint la limite ou n'en est proche, et l'ajout de threads n'augmente pas le taux de transaction de la base de données. Dans de tels cas, le goulot d'étranglement s'apparente très probablement à un conflit dans la base de données. Les formes les plus courantes sont des conflits de verrous de ligne et de verrous de page d'index, mais il existe bien d'autres possibilités. Si vous vous trouvez dans cette situation, demandez conseil à une personne experte en réglage des performances de bases de données.

Classe d’instance de base de données

Afin d'optimiser les performances de votre instance de base de données Amazon RDS, choisissez un type d'instance de la génération actuelle avec suffisamment de bande passante pour prendre en charge votre type de stockage. Par exemple, vous pouvez choisir des instances optimisées Amazon EBS et des instances avec une connectivité réseau de 10 gigabits.

Important

Selon la classe d'instance que vous utilisez, la performance des IOPS pourrait être inférieure au maximum que RDS vous permet d'allouer. Pour plus d'informations sur les performances IOPS pour les classes d'instances de base de données, consultez Instances optimisées pour Amazon EBS dans le Guide de l'utilisateur Amazon EC2. Nous vous recommandons de déterminer le nombre maximal d'IOPS pour la classe d'instance avant de définir une valeur d'IOPS provisionnés pour votre instance de base de données.

Pour obtenir des performances optimales, nous vous encourageons à utiliser la dernière génération d'instances. Les instances de base de données de la génération précédente peuvent avoir une limite de stockage d'instance plus faible.

Sur certains systèmes de fichiers 32 bits anciens, les capacités de stockage peuvent être inférieures. Pour déterminer la capacité de stockage de votre instance de base de données, vous pouvez utiliser la commande describe-valid-db-instance-modifications d'AWS CLI.

La liste suivante montre le stockage maximum que la plupart des classes d'instance de base de données peuvent mettre à l'échelle pour chaque moteur de base de données :

  • Db2 : 64 Tio

  • MariaDB : 64 Tio

  • Microsoft SQL Server : 64 Tio

  • MySQL : 64 Tio

  • Oracle : 64 Tio

  • PostgreSQL : 64 Tio

Le tableau suivant présente quelques exceptions pour le stockage maximum (en Tio). Toutes les instances de base de données RDS for Microsoft SQL Server, à l’exception du stockage io2 Block Express, ont un stockage maximal de 16 Tio ; il n’y a donc pas d’entrées pour SQL Server.

Classe d’instance Db2 MariaDB MySQL Oracle PostgreSQL
db.m3 – Classes d'instance standard
db.t4g : classes d’instance à performances extensibles
db.t4g.medium N/A 16 16 N/A 32
db.t4g.small N/A 16 16 N/A 16
db.t4g.micro N/A 6 6 N/A 6
db.t3 : classes d’instance à performances extensibles
db.t3.medium 32 16 16 32 32
db.t3.small 32 16 16 32 16
db.t3.micro N/A 6 6 32 6
db.t2 : classes d’instance à performances extensibles

Pour de plus amples détails sur les classes d'instances prises en charge, consultez Instances de base de données de la génération précédente.