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 de performance du SSDStockage magnétique (ancien, non recommandé)Volume de journal dédié (DLV)Surveillance des performances des bases de donnéesFacteurs influant sur les performances des bases de données

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.

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

Les instances de base de données pour Amazon RDS pour 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 de plus amples informations, veuillez consulter Facteurs influant sur les performances des bases de données.

Pour de plus amples informations sur la tarification du stockage d'instance, veuillez consulter Tarification Amazon RDS.

Types de stockage Amazon RDS

Amazon RDS propose trois types de stockage : un SSD IOPS provisionné (également appelé io1 et io2 Block Express), un SSD à usage général (également appelé gp2 et gp3) et un SSD 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 DB2, MySQL, MariaDB, Oracle, SQL Server et PostgreSQL RDS avec un maximum de 64 tebioctets (TiB) de stockage. RDS pour 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 d'IOPS provisionnés : le stockage d'IOPS provisionnés 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 d'IOPS par seconde 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és pour tout nouveau besoin de stockage. La quantité maximale de stockage autorisée pour les instances de base de données sur le stockage magnétique est de 3 TiB. Pour de plus amples informations, veuillez consulter Stockage magnétique (ancien, non recommandé).

Stockage SSD d'IOPS par seconde 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és : 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, nous vous recommandons d'utiliser le stockage IOPS SSD io2 Block Express provisionné pour 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 allouée par volume et de la taille des opérations d'E/S exécutées.

Tous les volumes RDS io2 basés sur le système AWS Nitro 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 AWS Nitro sont des volumes io2.

Le tableau suivant indique la plage d'IOPS provisionnées et le débit maximal pour chaque moteur de base de données et plage de tailles de stockage.

Moteur de base de données Plage de tailles de stockage Plage des IOPS provisionnées Débit maximal
DB2, MariaDB, MySQL et PostgreSQL 100 à 65 536 GiB 1 000–256 000 IOPS 16 000 Mbits/s
Oracle 100 à 199 GiB 1 000 À 19 000 IOPS 4 000 Mio/s
Oracle 200—65 536 GiB 1 000–256 000 IOPS 16 000 Mbits/s
SQL Server 20 à 65 536 GiB 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 le nombre d'IOPS et le stockage alloué (en GiB) doit être compris entre 0,5 et 1 000. Pour les instances de base de données non basées sur le système AWS Nitro, 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 AWS Nitro, le nombre maximal d'IOPS est atteint à 512 GiB (500 IOPS x 512 GiB = 256 000 IOPS).

  • Le débit augmente proportionnellement jusqu'à une taille de MiB/s per provisioned IOPS. Maximum throughput of 4,000 MiB/s can be achieved at 256,000 IOPS with a 16-KiB I/O size and 16,000 IOPS or higher with a 256-KiB I/O 0,256. Pour les instances de base de données non basées sur le système AWS Nitro, débit maximal de 2 000MiB/s can be achieved at 128,000 IOPS with a 16-KiB I/O.

  • Si vous utilisez la scalabilité 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 scalabilité automatique du stockage, consultez Gestion automatique de la capacité avec le dimensionnement automatique du stockage Amazon RDS.

Les volumes Amazon RDS io2 Block Express sont disponibles dans les formats suivants : Régions AWS

  • Asie-Pacifique (Hong Kong)

  • Asie-Pacifique (Mumbai)

  • Asie-Pacifique (Séoul)

  • Asie-Pacifique (Singapour)

  • Asie-Pacifique (Sydney)

  • Asie-Pacifique (Tokyo)

  • Canada (Centre)

  • Europe (Francfort)

  • Europe (Irlande)

  • Europe (Londres)

  • Europe (Stockholm)

  • Moyen-Orient (Bahreïn)

  • USA Est (Ohio)

  • USA Est (Virginie du Nord)

  • USA Ouest (Californie du Nord)

  • US West (Oregon)

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

Pour les charges de travail gourmandes en I/O, vous pouvez utiliser le stockage SSD io1 IOPS provisionnés 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 allouée par volume et de la taille des opérations d'E/S exécutées. Nous vous recommandons d'utiliser le stockage io2 Block Express lorsqu'il est disponible.

Le tableau suivant indique la plage d'IOPS provisionnées et le débit maximal pour chaque moteur de base de données et plage de tailles de stockage.

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

¹ Pour Oracle, vous pouvez fournir le maximum de 256 000 IOPS uniquement sur le type d'instance r5b.

² Pour SQL Server, le maximum de 64 000 IOPS est garanti uniquement sur les instances basées sur Nitro appartenant aux 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 scalabilité 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 scalabilité 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 IOPS provisionné avec des répliques de 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 d'IOPS provisionnés afin de réduire les coûts. Toutefois, les performances de votre réplique de lecture dans ce cas peuvent différer de celles d'une configuration dans laquelle l'instance de base de données principale et les répliques de lecture utilisent le stockage IOPS provisionné.

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, veuillez consulter Tarification Amazon RDS.

Tirer le meilleur parti du stockage IOPS provisionné d'Amazon RDS

Si votre charge de travail est limitée en E/S, l'utilisation du stockage IOPS provisionné peut augmenter le nombre de demandes d'E/S que le système peut traiter simultanément. 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 IOPS provisionné 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 rentable qui convient à 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 le stockage à usage général peuvent connaître une latence beaucoup plus longue que les instances qui utilisent le stockage IOPS provisionné. 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 d'IOPS par seconde provisionnées.

Amazon RDS propose deux types de stockage à usage général : Stockage GP3 (recommandé) etstockage GP2 (génération précédente).

Stockage GP3 (recommandé)

En utilisant les 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 tous les moteurs de base de données RDS, à l'exception de RDS pour SQL Server, lorsque 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. Pour les volumes répartis par bandes, Amazon RDS fournit des performances de stockage de base de 12 000 IOPS et 500 Mbits/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 des IOPS provisionnées Plage de débits de stockage provisionnés
DB2, MariaDB, MySQL et PostgreSQL 20 à 399 GiB 3 000 IOPS/125 Mio/s N/A N/A
DB2, MariaDB, MySQL et PostgreSQL 400—65 536 GiB 12 000 IOPS/500 Mio/s 12 000–64 000 IOPS Entre 500 et 4 000 Mio/s
Oracle 20 à 199 GiB 3 000 IOPS/125 Mio/s N/A N/A
Oracle 200—65 536 GiB 12 000 IOPS/500 Mio/s 12 000–64 000 IOPS Entre 500 et 4 000 Mio/s
SQL Server 20 à 16 384 GiB 3 000 IOPS/125 Mio/s 3 000–16 000 IOPS Entre 125 et 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 le nombre d'IOPS au-dessus de 32 000 pour MariaDB et MySQL, la valeur du débit de stockage passe automatiquement de 500. MiBps Par exemple, lorsque vous définissez les IOPS sur 40 000 sur RDS pour MySQL, le débit de stockage doit être d'au moins 625. MiBps 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 scalabilité 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 scalabilité 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 GiB 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 une description plus détaillée de l'impact des performances de référence et du solde créditeur d'E/S sur les performances, consultez le billet Comprendre les performances en rafale par rapport aux performances de référence avec Amazon RDS et gp2 sur le AWS blog de base de données.

De nombreuses charges de travail n'épuisent jamais le solde de rafale. Cependant, certaines charges de travail peuvent épuiser le solde créditeur de stockage maximal de 3 000 IOPS. Planifiez donc votre capacité de stockage en fonction des besoins de vos charges de travail.

Pour les volumes gp2 supérieurs à 4 000 GiB, 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 pour les volumes gp2 de différentes tailles de stockage 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 d'IOPS de base Plage de débit de base IOPS en rafale
MariaDB, MySQL et PostgreSQL 5 à 399 GiB¹ Entre 100 et 1 197 IOPS Entre 128 et 250 Mio/s 3 000
MariaDB, MySQL et PostgreSQL 400 à 1 335 GiB Entre 1 200 et 4 005 IOPS 512 à 1 000 Mbits/s 12 000
MariaDB, MySQL et PostgreSQL 1 336 à 3 999 GiB Entre 4 008 et 11 997 IOPS 1,000 Mio/s 12 000
MariaDB, MySQL et PostgreSQL 4 000 à 65 536 GiB Entre 12 000 et 64 000 IOPS 1,000 Mio/s N/A²
Oracle 20 à 199 GiB Entre 100 et 597 IOPS Entre 128 et 250 Mio/s 3 000
Oracle 200—1 335 GiB Entre 600 et 4 005 IOPS 512 à 1 000 Mbits/s 12 000
Oracle 1 336 à 3 999 GiB Entre 4 008 et 11 997 IOPS 1,000 Mio/s 12 000
Oracle 4 000 à 65 536 GiB Entre 12 000 et 64 000 IOPS 1,000 Mio/s N/A²
SQL Server 20 à 333 GiB Entre 100 et 999 IOPS Entre 128 et 250 Mio/s 3 000
SQL Server 334 à 999 GiB Entre 1 002 et 2 997 IOPS 250 Mio/s 3 000
SQL Server 1 000 à 16 384 GiB Entre 3 000 et 16 000 IOPS 250 Mio/s N/A²
Note

¹ À l'aide du AWS Management Console, vous pouvez créer des instances de base de données avec une taille de stockage minimale de 5 GiB dans le niveau gratuit pour les classes d'instances de base de données db.t3.micro et db.t4g.micro. Dans le cas contraire, la taille de stockage minimale est de 20 GiB. Cette limitation ne s'applique pas à l'API AWS CLI et RDS.

² Les performances de base du volume dépassent les performances de rafale maximales.

Caractéristiques de performance des types de stockage SSD

Le tableau suivant présente les cas d'utilisation et les caractéristiques de performances des volumes de stockage SSD utilisés par Amazon RDS.

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

Les meilleures performances 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 IOPS soutenues pouvant atteindre 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érieur à une milliseconde, fourni régulièrement 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 GiB

100 à 65 536 GiB (20 à 16 384 GiB sur RDS pour SQL Server)

20 à 65 536 GiB (16 384 GiB sur RDS pour SQL Server)

20 à 65 536 GiB (16 384 GiB sur RDS pour 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és jusqu'à 4 000 Mo/s

Le débit augmente proportionnellement jusqu'à une taille de MiB/s per provisioned IOPS. Maximum throughput of 4,000 MiB/s can be achieved at 256,000 IOPS with a 16-KiB I/O size and 16,000 IOPS or higher with a 256-KiB I/O 0,256.

Pour les instances non basées sur le système AWS Nitro, débit maximal de 2 000MiB/s can be achieved at 128,000 IOPS with a 16-KiB I/O.

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

Fournir un débit supplémentaire (jusqu'à 4 000 MB/s (1000 MB/s sur RDS pour SQL Server)

1000 MB/s (250 MB/s sur RDS (pour SQL Server)
AWS CLI et nom de l'API RDS io2 io1 gp3 gp2

Redécoupage automatique entre les volumes SSD

Lorsque vous sélectionnez un SSD à usage général ou un SSD à IOPS provisionnés, 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 GiB 4
MariaDB, MySQL et PostgreSQL Moins de 400 Gio 1
MariaDB, MySQL et PostgreSQL 400—65 536 GiB 4
Oracle Moins de 200 Gio 1
Oracle 200—65 536 GiB 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és, il passe par différents états. Lorsque le volume est dans optimizing cet état, ses performances se situent entre les spécifications de configuration source et cible. Les performances de volume de transition ne seront pas inférieures à la plus faible des deux spécifications.

Lorsque vous modifiez le stockage d'une instance afin qu'il passe d'un volume à 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 charge de travail de base de données présente lors de la modification, cette opération peut consommer une grande quantité d'IOPS, augmenter considérablement le temps de latence des E/S et prendre plusieurs heures, alors que l'instance RDS reste dans son état. Modifying

Taux d'IOPS de référence et maximum 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 spécifique à chaque type d' EC2 instance, consultez la section Types d'instances pris en charge dans le Guide de EC2 l'utilisateur Amazon pour les instances Linux.

Stockage magnétique (ancien, non recommandé)

Amazon RDS prend également en charge le stockage magnétique, pour assurer la compatibilité descendante. Nous vous recommandons d'utiliser le stockage SSD à usage général ou à IOPS provisionnés pour tout nouveau besoin de stockage. Voici quelques limitations pour le stockage magnétique :

  • Ne vous permet pas de dimensionner le stockage lors de l'utilisation d'un moteur de base de données SQL Server.

  • Ne vous permet pas de passer à un autre type de stockage lorsque vous utilisez le moteur de base de données SQL Server.

  • Ne prend pas en charge le dimensionnement automatique du stockage.

  • Ne prend pas en charge les intégrations sans ETL avec Amazon Redshift.

  • Ne prend pas en charge les volumes élastiques.

  • Limité à une taille maximum de 3 Tio.

  • Limité à un maximum de 1 000 IOPS.

Volume de journal dédié (DLV)

Vous pouvez utiliser un volume de journal dédié (DLV) pour une instance de base de données qui utilise le stockage PIOPS (Provisioned IOPS) à l'aide de la console Amazon RDS AWS CLI ou de l'API Amazon RDS. Un DLV déplace les journaux de transactions des bases de données PostgreSQL MySQL/MariaDB redo logs and binary logs to a storage volume that's separate from the volume containing the database tables. A DLV makes transaction write logging more efficient and consistent. DLVs are ideal for databases with large allocated storage, high I/O et les exigences par seconde (IOPS), ou les charges de travail sensibles à la latence.

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

Note

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

Amazon RDS prend DLVs en charge toutes Régions AWS les versions suivantes :

  • MariaDB 10.6.7 et versions 10 ultérieures

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

  • PostgreSQL 13.10 et supérieur 13 versions, 14.7 et supérieur 14 versions, 15.2 et supérieur 15 versions, et 16.1 et supérieur 16 versions

RDS prend en charge les DLVs 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 DLVs répliques 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 plus d'informations sur l'activation d'un DLV, consultezUtilisation d'un volume de log dédié (DLV).

Surveillance des performances des bases 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 surveiller ces statistiques. Pour de plus amples informations, veuillez consulter Afficher les métriques dans la RDS console Amazon. 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— Le 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 indique la profondeur de la file d'attente à intervalles d'une minute. Les valeurs habituelles pour la longueur de file d'attente vont de zéro à plusieurs centaines.

  • EBSByteBalance%— Le pourcentage de crédits de débit restant dans le bucket burst 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 de plus amples informations, veuillez consulter Classe d'instances de base de données.

  • ReadIOPSet WriteIOPS — Le nombre d'opérations d'E/S effectuées chaque seconde. Cette métrique est rapportée comme étant le nombre moyen d'IOPS pour un intervalle de temps donné. Amazon RDS rapporte les IOPS en lecture et en écriture séparément à intervalles d'une minute. TotalIOPSest la somme des IOPS en lecture et en écriture. Les valeurs habituelles pour les IOPS vont de zéro à des dizaines de milliers par seconde.

    Si vos TotalIOPS valeurs 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.

  • ReadLatencyet WriteLatency — Le temps écoulé entre la soumission d'une demande d'E/S et son achèvement. 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).

  • ReadThroughputet WriteThroughput — Le nombre d'octets transférés chaque seconde vers ou depuis le disque. Cette métrique est rapportée comme étant le débit moyen pour un intervalle de temps donné. Amazon RDS indique le débit de lecture et d'écriture séparément à intervalles d'une minute en unités d'octets par seconde (B/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 influant sur les performances des bases de données

Les activités du système, la charge de travail de base de données et la classe d'instance de base de données peuvent affecter les performances des bases de données.

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'instances 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 obtenir des informations spécifiques sur les performances IOPS pour les classes d'instances de base de données, consultez la section 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 AWS CLI commande describe-valid-db-instance-modifications.

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 TiB

  • MariaDB : 64 Tio

  • Microsoft SQL Server — 64 TiB

  • 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 pour Microsoft SQL Server, à l'exception du stockage io2 Block Express, ont une capacité de stockage maximale de 16 TiB, il n'y a donc aucune entrée pour SQL Server.

Classe d'instance Db2 MariaDB MySQL Oracle PostgreSQL
db.m3 – Classes d'instance standard
db.t4g : classes d'instance de performance à capacité extensible
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 de performance à capacité extensible
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 de performance à capacité extensible

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.