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 Amazon RDS DB
Les instances de base de données RDS pour Amazon pour Db2, MariaDB, SQL My, SQL Postgre, Oracle et Microsoft SQL Server utilisent les volumes Amazon Elastic Block Store (EBSAmazon) pour le stockage des bases de données et des journaux.
Dans certains cas, la charge de travail de votre base de données peut ne pas être en mesure d'atteindre 100 % de la charge IOPS que vous avez provisionnée. Pour de plus amples informations, veuillez consulter Facteurs influant sur les performances des bases de données.
Pour plus d'informations sur la tarification du stockage d'instance, consultez RDSles tarifs Amazon
Rubriques
- Types RDS de stockage Amazon
- Stockage provisionné IOPS SSD
- SSDStockage à usage général
- Comparaison des types de stockage sur disque SSD (SSD)
- Stockage magnétique (ancien, non recommandé)
- Volume de journal dédié (DLV)
- Surveillance des performances des bases de données
- Facteurs influant sur les performances des bases de données
Types RDS de stockage Amazon
Amazon RDS propose trois types de stockage : provisionné IOPS SSD (également appelé io1 et io2 Block Express), à usage général SSD (également appelé 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 DB2SQL, My, MariaDB, OracleSQL, Server et SQL RDS Postgre avec un maximum de 64 tebioctets (TiB) de stockage. RDScar 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 :
-
Provisionné IOPS SSD : le IOPS stockage provisionné est conçu pour répondre aux besoins des charges de travail intensives en E/S, en particulier les charges de travail des bases de données, qui nécessitent une faible latence d'E/S et un débit d'E/S constant. Le IOPS stockage provisionné convient parfaitement aux environnements de production.
Pour plus d'informations sur le IOPS stockage provisionné, y compris les plages de tailles de stockage, consultezStockage provisionné IOPS SSD.
-
Usage général SSD : les SSD volumes à usage général offrent un stockage rentable, 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 SSD stockage à usage général, notamment sur les plages de tailles de stockage, consultezSSDStockage à usage général.
-
Magnétique — Amazon prend RDS également en charge le stockage magnétique pour des raisons de rétrocompatibilité. Nous vous recommandons d'utiliser General Purpose SSD ou Provisioned IOPS SSD 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é).
Lorsque vous sélectionnez General Purpose SSD ou Provisioned IOPSSSD, 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 RDS de stockage Amazon | Nombre de volumes provisionnés |
|---|---|---|
| Db2 | Moins de 400 Gio | 1 |
| Db2 | 400—65 536 GiB | 4 |
| MariaDB, My et Postgrer SQL SQL | Moins de 400 Gio | 1 |
| MariaDB, My et Postgrer SQL SQL | 400—65 536 GiB | 4 |
| Oracle | Moins de 200 Gio | 1 |
| Oracle | 200—65 536 GiB | 4 |
| SQLserveur | N’importe quel compte | 1 |
Lorsque vous modifiez un IOPS SSD volume à usage général SSD ou provisionné, il passe par une séquence d'é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.
Important
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 approvisionne plutôt de nouveaux volumes et déplace de manière transparente les données de l'ancien volume vers les nouveaux volumes. Cette opération consomme une quantité IOPS et un débit importants 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é de donnéesIOPS, augmenter considérablement le temps de latence des E/S et prendre plusieurs heures, alors que l'RDSinstance reste dans son Modifying état.
Stockage provisionné IOPS SSD
Pour une application de production nécessitant des performances d'E/S rapides et constantes, nous recommandons le stockage provisionnéIOPS. Le IOPS stockage provisionné est un type de stockage qui fournit des performances prévisibles et une faible latence constante. Le IOPS stockage provisionné est optimisé pour les charges de travail de traitement des transactions en ligne (OLTP) qui nécessitent des performances constantes. Provisioned IOPS permet d'optimiser les performances de ces charges de travail.
Lorsque vous créez une instance de base de données, vous spécifiez le IOPS débit et la taille du volume. Amazon RDS fournit ce IOPS taux pour l'instance de base de données jusqu'à ce que vous le modifiiez.
Amazon RDS propose deux types de IOPS SSD stockage provisionné : Stockage io2 Block Express (recommandé) etstockage io1 (génération précédente).
Stockage io2 Block Express (recommandé)
Pour les charges de travail gourmandes en E/S et sensibles à la latence, vous pouvez 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é IOPS provisionné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 de débit provisionné IOPS 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 | Gamme de produits provisionnés IOPS | Débit maximal |
|---|---|---|---|
| DB2, MariaDB, My et Postgrer SQL SQL | 100 à 65 536 GiB | 1 000 à 256 000 IOPS | 16 000 Mbits/s |
| Oracle | 100 à 199 GiB | 1 000 à 199 000 IOPS | 16 000 Mbits/s |
| Oracle | 200—65 536 GiB | 1 000 à 256 000 IOPS | 16 000 Mbits/s |
| SQLserveur | 20 à 65 536 GiB | 1 000 à 256 000 IOPS | 16 000 Mbits/s |
Les plages de tailles de stockage IOPS et de stockage présentent les contraintes suivantes :
-
Le ratio entre le IOPS stockage alloué (en GiB) ne doit pas être supérieur à 1000:1. Pour les instances de base de données non basées sur le système AWS Nitro, le ratio est de 500:1.
-
Le maximum IOPS peut être provisionné avec des volumes de 256 Go ou plus (IOPS1 000 × 256 GiB = 256 000). IOPS Pour les instances de base de données non basées sur le système AWS Nitro, le maximum IOPS est atteint à 512 GiB (IOPS500 x 512 GiB = 256 000). IOPS
-
Le débit augmente proportionnellement jusqu'à 0,256 Mbits/s par provisionnement. IOPS Le débit maximal de 4 000 Mbits/s peut être atteint à 256 000 IOPS avec une taille d'E/S de 16 Ko et à 16 000 IOPS ou plus avec une taille d'E/S de 256 Ko. Pour les instances de base de données non basées sur le système AWS Nitro, un débit maximal de 2 000 Mbits/s peut être atteint à 128 000 IOPS avec une taille d'E/S de 16 Ko.
-
Si vous utilisez le dimensionnement automatique du stockage, les mêmes ratios entre le seuil de stockage maximal (en GiB) IOPS et le seuil de stockage maximal s'appliquent également. Pour plus d'informations sur la scalabilité automatique du stockage, consultez Gestion automatique de la capacité avec Amazon RDS Storage AutoScaling.
Les volumes Amazon RDS io2 Block Express sont disponibles dans les versions suivantes : 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 intensives en E/S, vous pouvez utiliser le stockage IOPS SSD io1 provisionné et réaliser jusqu'à 256 000 opérations d'E/S par seconde (). IOPS Le débit des volumes io1 varie en fonction de la quantité IOPS provisionné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 de débit provisionné IOPS 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 | Gamme de produits provisionnés IOPS | Débit maximal |
|---|---|---|---|
| DB2, MariaDB, My et Postgrer SQL SQL | 100 à 399 GiB | 1 000 à 19 950 IOPS | 500 Mio/s |
| DB2, MariaDB, My et Postgrer SQL SQL | 400—65 536 GiB | 1 000 à 256 000 IOPS | 4 000 Mio/s |
| Oracle | 100 à 199 GiB | 1 000 à 9 950 IOPS | 500 Mio/s |
| Oracle | 200—65 536 GiB | 1 000 à 256 000 ¹ IOPS | 4 000 Mio/s |
| SQLserveur | 20 à 16 384 GiB | 1 000 à 64 000 m² IOPS | 1,000 Mio/s |
Note
¹ Pour Oracle, vous pouvez provisionner le maximum de 256 000 IOPS uniquement pour le type d'instance r5b.
² Pour le SQL serveur, le maximum de 64 000 IOPS est garanti uniquement sur les instances Nitro de type m5*, m6i, r5*, r6i et z1d. Les autres types d'instances garantissent des performances allant jusqu'à 32 000IOPS.
Les plages de tailles de stockage IOPS et de stockage présentent les contraintes suivantes :
-
Le ratio entre le stockage alloué (en GiB) doit être compris entre 1 et 50 pour le SQL serveur et entre 0,5 et 50 RDS pour les autres moteurs de base de données. IOPS RDS
-
Si vous utilisez le dimensionnement automatique du stockage, les mêmes ratios entre le seuil de stockage maximal (en GiB) IOPS et le seuil de stockage maximal s'appliquent également.
Pour plus d'informations sur la scalabilité automatique du stockage, consultez Gestion automatique de la capacité avec Amazon RDS Storage AutoScaling.
Combinaison du IOPS stockage provisionné avec des déploiements multi-AZ ou des répliques de lecture
Pour les cas OLTP d'utilisation en production, nous vous recommandons d'utiliser des déploiements multi-AZ pour une meilleure tolérance aux pannes avec un IOPS stockage provisionné pour des performances rapides et prévisibles.
Vous pouvez également utiliser le IOPS stockage provisionné avec des répliques de lecture pour My, SQL MariaDB ou Postgre. SQL 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 General Purpose SSD pour lire des répliques avec une instance de base de données principale qui utilise le IOPS SSD stockage provisionné 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 provisionnéIOPS.
Coûts du IOPS stockage provisionné
Avec le IOPS stockage provisionné, les ressources allouées vous sont facturées, que vous les utilisiez ou non au cours d'un mois donné.
Pour plus d'informations sur les tarifs, consultez les RDStarifs Amazon
Tirer le meilleur parti du stockage RDS provisionné par IOPS Amazon
Si votre charge de travail est limitée en E/S, l'utilisation du IOPS stockage 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 IOPS stockage provisionné permet de réserver la capacité d'E/S en spécifiant. 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 du réseauCPU, la mémoire ou les ressources internes de la base de données.
SSDStockage à 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 IOPS stockage 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 provisionné IOPS SSD.
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 sont la combinaison des opérations d'E/S par seconde (IOPS) et de la rapidité avec laquelle le volume de stockage peut effectuer des lectures et des écritures (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 Mbits/s.
Pour tous les RDS moteurs de base de données, à l'exception RDS SQL du serveur, 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. RDSfor SQL Server ne prend pas en charge le découpage des volumes et ne possède donc pas de valeur 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 RDS de base de données Amazon, y compris le seuil, sont indiquées dans le tableau suivant.
| Moteur de base de données | Taille de stockage | Performances de stockage de base | Gamme de produits provisionnés IOPS | Plage de débits de stockage provisionnés |
|---|---|---|---|---|
| DB2, MariaDB, My et Postgrer SQL SQL | 20 à 399 GiB | 3 000 IOPS /125 Mbits/s | N/A | N/A |
| DB2, MariaDB, My et Postgrer SQL SQL | 400—65 536 GiB | 12 IOPS 000/500 Mbits/s | 12 000 à 64 000 IOPS | Entre 500 et 4 000 Mio/s |
| Oracle | 20 à 199 GiB | 3 000 IOPS /125 Mbits/s | N/A | N/A |
| Oracle | 200—65 536 GiB | 12 IOPS 000/500 Mbits/s | 12 000 à 64 000 IOPS | Entre 500 et 4 000 Mio/s |
| SQLserveur | 20 à 16 384 GiB | 3 000 IOPS /125 Mbits/s | 3 000 à 16 000 IOPS | Entre 125 et 1 000 Mio/s |
Pour chaque moteur de base de données, à l'exception RDS SQL du serveur, vous pouvez fournir un débit de stockage supplémentaire IOPS lorsque la taille de stockage est égale ou supérieure à la valeur seuil. RDSPour le SQL serveur, vous pouvez fournir un débit de stockage supplémentaire IOPS et un débit de stockage 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 les RDStarifs Amazon
Bien que le débit provisionné IOPS et le débit de stockage ajoutés ne dépendent pas de la taille du stockage, ils sont liés les uns aux autres. Lorsque vous augmentez les 32 000 IOPS ci-dessus pour MariaDB et SQL My, la valeur du débit de stockage passe automatiquement de 500. MiBps Par exemple, lorsque vous activez la valeur 40 000 IOPS 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, OracleSQL, Postgre et SQL Server.
Pour les clusters de bases de données multi-AZ, Amazon définit RDS automatiquement la valeur du débit en fonction de IOPS ce que vous fournissez. Vous ne pouvez pas modifier la valeur du débit.
Les valeurs de performance de stockage pour les volumes gp3 RDS sont soumises aux contraintes suivantes :
-
Le rapport entre le débit de stockage et le débit maximal IOPS est de 0,25 pour tous les moteurs de base de données pris en charge.
-
Le ratio minimum entre le stockage alloué (en GiB) est de 0,5 activé RDS pour SQL le serveur. IOPS Il n'y a pas de rapport minimal pour les autres moteurs de base de données pris en charge.
-
Le ratio maximum entre le stockage alloué est de IOPS 500 pour tous les moteurs de base de données pris en charge.
-
Si vous utilisez le dimensionnement automatique du stockage, les mêmes ratios entre le seuil de stockage maximal (en GiB) IOPS et le seuil de stockage maximal s'appliquent également.
Pour plus d'informations sur la scalabilité automatique du stockage, consultez Gestion automatique de la capacité avec Amazon RDS Storage AutoScaling.
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 GP2 à usage général. Les performances d'E/S de base pour le stockage gp2 sont de 3 IOPS pour chaque GiB, 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 Go sont de 300. IOPS Les performances de référence pour un volume de 1 000 GiB sont de 3 000. IOPS
Les volumes gp2 individuels d'une taille inférieure à 1 000 GiB peuvent également atteindre IOPS 3 000 Go pendant de longues périodes. 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
De nombreuses charges de travail n'épuisent jamais le solde de rafale. Cependant, certaines charges de travail peuvent épuiser le solde de 3 000 crédits de stockage en IOPS rafale. Vous devez donc planifier 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, la rafale n'est pas pertinente car les performances de base sont meilleures que les performances de 3 000 IOPS rafales. Toutefois, pour les instances de base de données de certains moteurs et de certaines tailles, le stockage est réparti sur quatre volumes, fournissant un débit quatre fois supérieur au débit de base et quatre fois le débit en rafale IOPS d'un volume unique.
Les performances de stockage des volumes gp2 de différentes tailles de stockage sur les moteurs de RDS base de données Amazon sont présentées dans le tableau suivant.
| Moteur de base de données | RDStaille de stockage | Plage de valeurs de référence IOPS | Plage de débit de base | Éclater IOPS |
|---|---|---|---|---|
| MariaDB, My et Postgrer SQL SQL | 5 à 399 GiB¹ | 100-1197 IOPS | Entre 128 et 250 Mio/s | 3 000 |
| MariaDB, My et Postgrer SQL SQL | 400—1 335 GiB | 1 200 à 4 005 IOPS | 512 à 1 000 Mbits/s | 12 000 |
| MariaDB, My et Postgrer SQL SQL | 1 336 à 3 999 GiB | 4008-11 997 IOPS | 1,000 Mio/s | 12 000 |
| MariaDB, My et Postgrer SQL SQL | 4 000 à 65 536 GiB | 12 000 à 64 000 IOPS | 1,000 Mio/s | N/A² |
| Oracle | 20 à 199 GiB | 100-597 IOPS | Entre 128 et 250 Mio/s | 3 000 |
| Oracle | 200—1 335 GiB | 600 à 4 005 IOPS | Entre 500 et 1 000 Mio/s | 12 000 |
| Oracle | 1 336 à 3 999 GiB | 4008-11 997 IOPS | 1,000 Mio/s | 12 000 |
| Oracle | 4 000 à 65 536 GiB | 12 000 à 64 000 IOPS | 1,000 Mio/s | N/A² |
| SQLserveur | 20 à 333 GiB | 100-999 IOPS | Entre 128 et 250 Mio/s | 3 000 |
| SQLserveur | 334 à 999 GiB | 1 002 à 2 997 IOPS | 250 Mio/s | 3 000 |
| SQLserveur | 1 000 à 16 384 GiB | 3 000 à 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 au AWS CLI et RDSAPI.
² Les performances de base du volume dépassent les performances de rafale maximales.
Comparaison des types de stockage sur disque SSD (SSD)
Le tableau suivant présente les cas d'utilisation et les caractéristiques de performance des volumes SSD de stockage utilisés par AmazonRDS.
| Caractéristiques | Provisionné IOPS (io2 Block Express) | Provisionné IOPS (io1) | Usage général (gp3) | Usage général (gp2) |
|---|---|---|---|---|
| Description |
Les meilleures performances du portefeuille de RDS stockage (débitIOPS, latence) Conçu pour les charges de travail transactionnelles sensibles à la latence |
Performances de stockage constantes (débitIOPS, latence) Conçu pour les charges de travail transactionnelles sensibles à la latence |
Flexibilité dans le provisionnementIOPS, le stockage et le débit de manière indépendante Équilibre les performances de prix pour un large éventail de charges de travail transactionnelles |
Fournit une capacité d'éclatement IOPS É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 soutenues allant jusqu'à 256 000 IOPS IOPS |
Charges de travail transactionnelles nécessitant des IOPS performances 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 le serveur) RDS SQL |
20 à 65 536 GiB (16 384 GiB sur le serveur) RDS SQL |
20 à 65 536 GiB (16 384 GiB sur le serveur) RDS SQL |
| Maximum IOPS |
256 000 |
256 000 (64 000 sur le serveurRDS) SQL |
64 000 (16 000 sur le serveurRDS) SQL |
64 000 (16 000 sur le serveurRDS) SQL NoteVous ne pouvez pas le provisionner IOPS directement sur le stockage gp2. IOPSvarie en fonction de la taille de stockage allouée. |
| Débit maximal |
Échelle basée sur le provisionnement IOPS allant jusqu'à 4 000 Mo/s Le débit augmente proportionnellement jusqu'à 0,256 Mbits/s par provisionnement. IOPS Le débit maximal de 4 000 Mbits/s peut être atteint à 256 000 IOPS avec une taille d'E/S de 16 Ko et à 16 000 IOPS ou plus avec une taille d'E/S de 256 Ko. Pour les instances non basées sur le système AWS Nitro, un débit maximal de 2 000 Mbits/s peut être atteint à 128 000 IOPS avec une taille d'E/S de 16 Ko. |
Échelle basée sur le provisionnement IOPS allant jusqu'à 4 000 Mo/s |
Fournir un débit supplémentaire allant jusqu'à 4 000 Mo/s (1 000 Mo/s sur RDS le SQL serveur) |
1 000 Mo/s (250 Mo/s sur RDS le SQL serveur) |
| AWS CLI et RDS API nom | io2 | io1 | gp3 | gp2 |
Stockage magnétique (ancien, non recommandé)
Amazon prend RDS également en charge le stockage magnétique pour des raisons de rétrocompatibilité. Nous vous recommandons d'utiliser General Purpose SSD ou Provisioned IOPS SSD pour tout nouveau besoin de stockage. Voici quelques limitations pour le stockage magnétique :
Ne vous permet pas de dimensionner le stockage lorsque vous utilisez le moteur de base de données du SQL serveur.
-
Ne vous permet pas de passer à un autre type de stockage lorsque vous utilisez le moteur de base de données du SQL serveur.
-
Ne prend pas en charge le dimensionnement automatique du stockage.
Ne prend pas en charge les volumes élastiques.
Limité à une taille maximum de 3 Tio.
Limité à un maximum de 1 000IOPS.
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 Provisioned IOPS (PIOPS) à l'aide de la RDS console Amazon ou d'Amazon RDSAPI. AWS CLI A DLV déplace les journaux de transactions SQL de la base de données Postgre, les journaux redo SQL My/MariaDB et les journaux binaires vers un volume de stockage distinct du volume contenant les tables de base de données. A DLV rend la journalisation des écritures de transactions plus efficace et cohérente. DLVssont idéaux pour les bases de données nécessitant 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.
DLVssont pris en charge pour le PIOPS stockage (io1 et io2 Block Express) et sont créés avec une taille fixe de 1 000 GiB et 3 000 provisionnés. IOPS
Note
DLVsne sont pas pris en charge pour le stockage à usage général (gp2 et gp3).
Amazon RDS prend DLVs en charge Régions AWS en tout les versions suivantes :
MariaDB 10.6.7 et versions 10 ultérieures
Mes versions SQL 8.0.28 et supérieures (8)
Postgre SQL 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
RDSprend en charge DLVs les déploiements multi-AZ. Lorsque vous modifiez ou créez une instance Multi-AZ, A DLV est créé à la fois pour l'instance principale et pour l'instance secondaire.
RDSprend en charge DLVs les répliques de lecture. Si l'instance de base de données principale est DLV activée, toutes les répliques de lecture créées après l'activation DLV auront également unDLV. Toutes les répliques de lecture créées avant le passage à ne DLV seront pas activées, sauf si elles sont explicitement modifiées à cet effet. Nous recommandons que toutes les répliques de lecture attachées à une instance principale avant DLV son activation soient également modifiées manuellement pour avoir la valeur A. DLV
Après avoir modifié le DLV paramètre d'une instance de base de données, celle-ci doit être redémarrée.
Pour plus d'informations sur l'activation d'unDLV, consultezUtilisation d'un volume de log dédié (DLV).
Surveillance des performances des bases de données
Amazon RDS fournit plusieurs métriques que vous pouvez utiliser pour déterminer les performances de votre instance de base de données. Vous pouvez consulter les statistiques sur la page de résumé de votre instance dans 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 RDS base de données. 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.
-
ReadIOPSetWriteIOPS— Le nombre d'opérations d'E/S effectuées chaque seconde. Cette métrique est indiquée sous forme de moyenne IOPS pour un intervalle de temps donné. RDSLes rapports Amazon sont lus et écrits IOPS séparément à intervalles d'une minute.TotalIOPSest la somme de la lecture et de l'écritureIOPS. Les valeurs typiques IOPS vont de zéro à des dizaines de milliers par seconde.Si vos
TotalIOPSvaleurs se rapprochent régulièrement de la IOPS valeur provisionnée que vous avez définie pour votre instance de base de données, envisagez d'augmenter la valeur provisionnée IOPS (types de stockage io1, io2 Block Express et gp3).Les IOPS valeurs mesurées sont indépendantes de la taille de chaque opération d'E/S. 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.
-
ReadLatencyetWriteLatency— 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 indique les temps de latence de lecture et d'écriture séparément à intervalles d'une minute. Les valeurs de latence sont généralement exprimées en millisecondes (ms). -
ReadThroughputetWriteThroughput— 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
Pour tirer le meilleur parti des performances de votre instance Amazon RDS DB, choisissez un type d'instance de génération actuelle avec suffisamment de bande passante pour prendre en charge votre type de stockage. Par exemple, vous pouvez choisir des instances EBS optimisées pour Amazon et des instances dotées d'une connectivité réseau de 10 gigabits.
Important
Selon la classe d'instance que vous utilisez, les IOPS performances peuvent être inférieures au maximum que vous pouvez provisionnerRDS. Pour des informations spécifiques sur les IOPS performances des classes d'instances de base de données, consultez les instances EBS optimisées pour Amazon dans le guide de EC2 l'utilisateur Amazon. Nous vous recommandons de déterminer le maximum IOPS pour la classe d'instance avant de définir une IOPS valeur provisionnée 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
-
Mai SQL — 64 TiB
-
Oracle : 64 Tio
-
Poster SQL — 64 TiB
Le tableau suivant présente quelques exceptions pour le stockage maximum (en Tio). Toutes RDS les instances de base de données 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 SQL pour Server.
| Classe d'instance | Db2 | MariaDB | Mon SQL | Oracle | Poster SQL |
|---|---|---|---|---|---|
| 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
