Amazon Relational Database Service
Guide de l'utilisateur

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

Les instances de base de données pour Amazon RDS pour MySQL, MariaDB, 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. En fonction du volume de stockage demandé, Amazon RDS ajuste automatiquement sur plusieurs volumes Amazon EBS pour améliorer la performance.

Types de stockage Amazon RDS

Amazon RDS propose trois types de stockage : le stockage SSD à usage général (également connu sous le nom de gp2), le stockage d'I/O par seconde provisionnées (également connu sous le nom d'io1) et le stockage magnétique. 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 bases de données MySQL, MariaDB et PostgreSQL RDS avec jusqu'à 64 Tio de stockage. Vous pouvez créer des instances de base de données Oracle RDS avec un maximum de 64 Tio de stockage. Vous pouvez créer des instances de base de données SQL Server RDS avec jusqu'à 16 Tio de stockage. Pour ce volume de stockage, utilisez les types de stockage SSD d'I/O par seconde provisionnées et à usage général.

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

  • Usage général SSD – Les volumes à usage général SSD, également appelés volumes gp2, offrent un stockage économique idéal pour un large éventail de charges de travail. Ces volumes fournissent des latences inférieures à 10 millisecondes, avec la capacité d'émettre en rafale jusqu'à 3 000 E/S par seconde pendant de longues périodes de temps. Les performances de base de ces volumes sont déterminées par leur taille.

    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.

  • IOPS provisionnés – Le stockage d'IOPS provisionnés est conçu pour satisfaire les besoins des charges de travail gourmandes en I/O, notamment les charges de travail de base de données qui requièrent une faible latence des I/O et un débit d'I/O homogène.

    Pour plus d'informations sur le stockage IOPS provisionnées, y compris les plages de tailles de stockage, consultez Stockage SSD d'I/O par seconde provisionnées.

  • 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 d'I/O par seconde provisionnées pour tout nouveau besoin de stockage. La capacité maximale de stockage autorisée pour les instances de bases de données sur le stockage magnétique est inférieure à celle des autres types de stockage. Pour plus d'informations, consultez Stockage magnétique.

Plusieurs facteurs peuvent affecter les performances des volumes Amazon EBS, tels que la configuration d'instance, les caractéristiques d'I/O et la demande en matière de charge de travail. Pour plus d'informations sur la façon d'exploiter au mieux vos volumes IOPS provisionnés, consultez Performances des volumes Amazon EBS.

Stockage SSD à usage général

Le stockage SSD à usage général offre un stockage économique qui est approprié pour la plupart des charges de travail de bases de données. Les plages de tailles de stockage pour les instances de bases de données à usage général SSD sont les suivantes :

  • Instances de base de données MariaDB, MySQL et PostgreSQL : 20 Gio–64 Tio

  • Éditions SQL Server Enterprise, Standard, Web et Express : 20 Gio–16 Tio

  • Instances Oracle : 20 Gio- 64 Tio

Les performances d'E/S de base pour le stockage SSD à usage général sont de 3 E/S par seconde pour chaque Gio. 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 I/O par seconde. Les performances de base pour un volume de 1 Tio sont de 3 000 E/S par seconde. Les performances de base pour un volume de 5,34 Tio sont de 16 000 E/S par seconde.

Les volumes inférieurs à 1 Tio peuvent également atteindre 3 000 E/S par seconde pendant des périodes de temps étendues . Le mode rafale n'est pas pertinent pour les volumes supérieurs à 1 Tio. Le solde de crédit des E/S de l'instance détermine les performances de la rafale. Pour plus d'informations sur les crédits d'I/O d'instance, consultez Crédits E/S et performances en rafale.

De nombreuses charges de travail n'épuisent jamais le solde de la rafale, c'est pourquoi le stockage SSD à usage général est une solution idéale pour la plupart d'entre elles. Toutefois, certaines charges de travail peuvent épuiser le solde de crédit d'I/O de rafale de 3 000 I/O par seconde. En conséquence, prévoyez votre capacité de stockage de sorte qu'elle corresponde aux besoins de vos charges de travail.

Crédits E/S et performances en rafale

Les performances du stockage SSD à usage général sont régies par la taille du volume, qui dicte le niveau de performance de base du volume, ainsi que la vitesse à laquelle il accumule des crédits d'I/O. Les volumes les plus gros ont un niveau de performance de base plus élevé et accumulent des crédits I/O plus vite. Les crédits I/O représentent la bande passante disponible que votre stockage SSD à usage général peut utiliser pour émettre en rafale de grandes quantités d'I/O lorsqu'il est nécessaire de dépasser le niveau de performance de base. Plus votre stockage dispose de crédits pour les I/O, plus il peut émettre en rafale au-delà de son niveau de performances de base, et plus il est performant quand votre charge de travail en a besoin.

Lors de l'utilisation du stockage SSD à usage général, votre instance de base de données reçoit un solde de crédit d'I/O de 5,4 millions. Ce solde de crédit initial est suffisant pour soutenir les performances en rafale de 3 000 I/O par seconde pour 30 minutes. Ce solde est conçu de façon à fournir un cycle de démarrage initial rapide pour les volumes de démarrage, ainsi qu'une bonne expérience d'action d'amorçage (bootstrap) pour les autres applications. Les volumes gagnent des crédits d'I/O, au rythme de performances de base de 3 I/O par seconde pour chaque Gio de taille du volume. Par exemple, un volume SSD de 100 Gio a une performance de base de 300 I/O par seconde.

Lorsque votre stockage a besoin d'un niveau de performances d'I/O plus élevé que le niveau de base, il utilise les crédits d'I/O du solde de crédits pour émettre en rafale, jusqu'au niveau de performances requis. Ce type de rafale peut atteindre un maximum de 3 000 I/O par seconde. Les stockages supérieurs à 1 000 Gio ont une performance de base égale ou supérieure à la performance rafale maximum. Lorsque votre stockage utilise moins de crédits I/O qu'il n'en gagne en une seconde, les crédits I/O inutilisés sont ajoutés au solde de crédits I/O. Le solde de crédits d'I/O maximum pour une instance de base de données utilisant un stockage SSD à usage général est égal au solde de crédits d'I/O initial (5,4 millions de crédits I/O).

Supposons que votre stockage utilise tout son solde de crédit d'I/O. Ses performances maximales ne dépasseront pas le niveau de base jusqu'à ce que la demande en I/O passe en-dessous du niveau de base et que les crédits non utilisés soient ajoutés au solde de crédits d'I/O. (Le niveau de performance de base est le rythme auquel votre stockage gagne des crédits I/O.) Plus le stockage est important, plus la performance de base est grande et plus la vitesse à laquelle le volume réapprovisionne son solde de crédits I/O est grande.

Note

Les conversions entre le stockage magnétique et le stockage SSD à usage général sont susceptibles d'épuiser votre solde de crédit d'I/O, et d'entraîner ainsi des temps de conversion plus longs. Pour plus d'informations sur le dimensionnement du stockage, consultez Utilisation du stockage pour les instances de base de données Amazon RDS. .

Le tableau suivant répertorie plusieurs tailles de stockage. Pour chaque taille de stockage, il répertorie les performances de base associées du stockage, qui correspondent également au rythme auquel celui-ci accumule des crédits I/O. Ce tableau répertorie également la durée d'émission en rafales au débit maximum de 3 000 IOPS, en commençant avec un solde de crédits I/O plein. En outre, le tableau répertorie la durée en secondes nécessaire au stockage pour remplir un solde de crédits E/S vide.

Note

La figure E/S par seconde atteint sa valeur maximale à la taille de stockage de 5 334 Gio.

Taille de stockage (Gio) Performances de base (IOPS) Durée maximum de performances en rafale à 3 000 IOPS (en secondes) Secondes nécessaires pour remplir un solde de crédits I/O vide
1 100 1,862 54 000
100 300 2 000 18 000
250 750 2 400 7 200
500 1 500 3 600 3 600
750 2 250 7 200 2 400
1 000 3 000 Infini S/O
5 334 16 000 S/O S/O

La durée des performances en rafale de votre stockage dépend de sa taille, des IOPS en rafale nécessaires et du solde de crédits I/O au début de la rafale. Cette relation est représentée dans l'équation suivante.

(Credit balance) Burst duration =  ------------------------------------ (Burst IOPS) - 3(Storage size in GiB)

Vous constaterez peut-être que la performance de votre stockage est fréquemment limitée au niveau de base en raison d'un solde de crédits d'I/O nul. Le cas échéant, envisagez d'allouer davantage de stockage SSD à usage général avec un niveau de performance de base plus élevé. Vous pouvez également passer à un stockage des IOPS provisionnées pour les charges de travail nécessitant des performances IOPS soutenues.

Pour les charges de travail dont les exigences en termes d'I/O sont stables, mettre en service un stockage SSD à usage général inférieur à 100 Gio peut entraîner des latences plus importantes si vous épuisez votre solde de crédits d'I/O.

Note

En général, la plupart des charges de travail ne dépassent jamais le solde de crédits I/O.

Pour obtenir une description plus complète de l'impact des performances de base et du solde de crédits d'I/O sur les performances, consultez Comprendre les performances de rafale et de base avec Amazon RDS et GP2.

Stockage SSD d'I/O par seconde provisionnées

Pour toutes les applications de production nécessitant des performances d'I/O rapides et cohérentes, nous recommandons d'utiliser le stockage des I/O par seconde provisionnées. Le stockage des I/O par seconde provisionnées 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 I/O par seconde provisionnées aident à ajuster ces charges de travail.

Lorsque vous créez une instance de base de données, vous spécifiez un taux IOPS et la taille du volume. Amazon RDS fournit ce taux IOPS pour l'instance de base de données jusqu'à ce que vous le changez.

Note

La charge de travail de votre base de données ne sera peut-être pas capable d'atteindre 100% des I/O par seconde que vous avez provisionnées.

Le tableau suivant contient la plage des I/O par seconde provisionnées et la plage de la taille de stockage pour chaque moteur de base de données.

Moteur de base de données Plage des IOPS provisionnées Plage de stockage

MariaDB

1 000–80 000 E/S par seconde 100 Gio–64 Tio
Editions SQL Server, Enterprise et Standard 1 000–64 000 IOPS* 20 Gio–16 Tio
Editions SQL Server Web et Express 1 000–64 000 IOPS* 100 Gio–16 Tio
MySQL 1 000–80 000 E/S par seconde 100 Gio–64 Tio
Oracle 1 000–80 000 E/S par seconde 100 Gio– 64 Tio
PostgreSQL 1 000–80 000 E/S par seconde 100 Gio–64 Tio

* Le nombre maximal d'IOPS de 64 000 est garanti uniquement sur les instances basées sur Nitro qui sont sur des types d'instances m5. Les autres familles d'instances garantissent des performances jusqu'à 32 000 IOPS.

Combinaison du stockage des I/O par seconde provisionnées 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 I/O par seconde provisionnées, et ainsi bénéficier de performances rapides et prévisibles.

Vous pouvez aussi utiliser le stockage SSD des I/O par seconde 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 bases 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'I/O par seconde provisionnées afin de réduire les coûts. Toutefois, dans ce cas, les performances de vos réplicas en lecture peuvent différer considérablement de celles d'une configuration où l'instance de bases de données principale et les réplicas en lecture utilisent tous deux un stockage d'I/O par seconde provisionnées.

Coûts du stockage IOPS provisionnées

Avec le stockage d'I/O par seconde provisionnées, 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 Amazon RDS Tarification.

Optimisation du stockage SSD des I/O par seconde provisionnées Amazon RDS

Si votre charge de travail est limitée en I/O, l'utilisation du stockage SSD d'I/O provisionnées peut augmenter le nombre de demandes d'I/O 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 SSD d'I/O par seconde provisionnées permet de réserver la capacité d'I/O en spécifiant les I/O par seconde. 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 magnétique

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 à I/O par seconde provisionnées 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 prend pas en charge les volumes élastiques.

  • Limité à une taille maximum de 3 Tio.

  • Limité à un maximum de 1 000 I/O par seconde.

Surveillance des performances de stockage

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 d'instances de base de données. La surveillance améliorée offre des métriques d'I/O plus détaillées. Pour plus d'informations, consultez Surveillance améliorée.

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

  • IOPS – Nombre d'opérations d'I/O terminées par seconde. Cette métrique est considérée comme l'IOPS moyen pour un intervalle donné. Amazon RDS signale séparément l'IOPS de lecture et d'écriture à des intervalles d'1 minute. L'IOPS total 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.

  • Latence – Temps écoulé entre l'envoi d'une requête d'I/O et sa fin. Cette métrique est considérée comme la latence moyenne pour un intervalle donné. Amazon RDS signale séparément la latence de lecture et d'écriture à des intervalles d'1 minute, en unités de secondes. Les valeurs habituelles pour la latence sont de l'ordre des millisecondes (ms). Par exemple, Amazon RDS indique 2 ms sous la forme de 0,002 seconds.

  • Débit – Nombre d'octets transférés chaque seconde depuis et vers le disque. Cette métrique est considérée comme le débit moyen pour un intervalle donné. Amazon RDS signale séparément le débit de lecture et d'écriture à des intervalles d'1 minute, en unités de mégaoctets par seconde (Mo/s). Les valeurs habituelles pour le débit vont de zéro à la taille maximale de la bande passante du canal d'I/O.

  • Longueur de la file d'attente – Nombre de demandes d'I/O 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 considérée comme la longueur de file d'attente moyenne pour un intervalle donné. Amazon RDS signale séparément la longueur de file d'attente à des intervalles d'1 minute. Les valeurs habituelles pour la longueur de file d'attente vont de zéro à plusieurs centaines.

Les valeurs d'I/O par seconde 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'I/O, vous devez observer le débit de l'instance et pas simplement le nombre d'opérations d'I/O.

Autres facteurs ayant un impact sur les performances de stockage

Les activités du système et la charge de travail de la 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 dans plusieurs zones de disponibilité

  • 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 à 4 car votre application n'a pas suffisamment d'opérations d'I/O.

  • 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.

Si aucune ressource du système n'a atteint la limite et qu'aucune n'en est proche, et que l'ajout de threads n'augmente pas la vitesse de transaction de la base de données, le conflit est probablement dû au goulot d'étranglement. Les formes les plus courantes sont les conflits des verrous de ligne et des verrous des pages d'index, mais il existe bien d'autres possibilités. Si vous vous trouvez dans cette situation, consultez une personne spécialisée dans le réglage des performances des 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 EBS et des instances avec une connectivité réseau de 10 gigabits.

Pour obtenir la liste complète des types d'instance Amazon EC2 qui prennent en charge l'optimisation EBS, consultez Types d'instance qui prennent en charge l'optimisation EBS.

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 ont une limite de stockage d'instance plus faible. Le tableau suivant montre le stockage maximum que chaque classe d'instance de base de données peut atteindre pour chaque moteur de base de données. Toutes les valeurs sont exprimées en tebioctets (Tio).

Classe d'instance MariaDB Microsoft SQL Server MySQL Oracle PostgreSQL
db.m5 – Classes d'instances standard de dernière génération
db.m5.24xlarge 64 16 64 64 64
db.m5.12xlarge 64 16 64 64 64
db.m5.4xlarge 64 16 64 64 64
db.m5.2xlarge 64 16 64 64 64
db.m5.xlarge 64 16 64 64 64
db.m5.large 64 16 64 64 64
db.m4 – Classes d'instances standard de génération actuelle
db.m4.16xlarge 64 16 64 64 64
db.m4.10xlarge 64 16 64 64 64
db.m4.4xlarge 64 16 64 64 64
db.m4.2xlarge 64 16 64 64 64
db.m4.xlarge 64 16 64 64 64
db.m4.large 64 16 64 64 64
db.m3 – Classes d'instances standard de la génération précédente
db.m3.2xlarge 6 16 6 6 6
db.m3.xlarge 6 16 6 6 6
db.m3.large 6 16 6 6 6
db.m3.medium 32 16 32 32 32
Instance Class MariaDB Microsoft SQL Server MySQL Oracle PostgreSQL
db.r5 – Classes d'instances à mémoire optimisée de dernière génération
db.r5.24xlarge 16 16 64 64
db.r5.12xlarge 16 16 64 64
db.r5.4xlarge 16 16 64 64
db.r5.2xlarge 16 16 64 64
db.r5.xlarge 16 16 64 64
db.r5.large 16 16 64 64
db.r4 – Classes d'instances à mémoire optimisée de génération actuelle
db.r4.16xlarge 64 16 64 64 64
db.r4.8xlarge 64 16 64 64 64
db.r4.4xlarge 64 16 64 64 64
db.r4.2xlarge 64 16 64 64 64
db.r4.xlarge 64 16 64 64 64
db.r4.large 64 16 64 64 64
db.r3 – Classes d'instances à mémoire optimisée de génération précédente
db.r3.8xlarge 64 16 64 64 64
db.r3.4xlarge 64 16 64 64 64
db.r3.2xlarge 64 16 64 64 64
db.r3.xlarge 64 16 64 64 64
db.r3.large 64 16 64 64 64
Instance Class MariaDB Microsoft SQL Server MySQL Oracle PostgreSQL
db.t3 – Classes d'instances à capacité extensible de génération actuelle
db.t3.2xlarge 16 16 64 64
db.t3.xlarge 16 16 64 64
db.t3.large 16 16 64 64
db.t3.medium 16 16 32 32
db.t3.small 16 16 32 16
db.t3.micro 16 16 32 16
db.t2 – Classes d'instances à capacité extensible de génération actuelle
db.t2.2xlarge 64 16 64 64 64
db.t2.xlarge 64 16 64 64 64
db.t2.large 64 16 64 64 64
db.t2.medium 32 16 32 32 32
db.t2.small 16 16 16 16 16
db.t2.micro 16 16 16 16 16
Instance Class MariaDB Microsoft SQL Server MySQL Oracle PostgreSQL
db.x1e – Classes d'instances à mémoire optimisée de dernière génération
db.x1e.32xlarge 16 64
db.x1e.16xlarge 16 64
db.x1e.8xlarge 16 64
db.x1e.4xlarge 16 64
db.x1e.2xlarge 16 64
db.x1e.xlarge 16 64
db.x1 – Classes d'instances à mémoire optimisée de génération actuelle
db.x1.32xlarge 16 64
db.x1.16xlarge 16 64

Pour Oracle, l'augmentation jusqu'à 80 000 E/S par seconde est uniquement prise en charge sur les classes d'instances suivantes :

  • db.m5.24xlarge

  • db.r5.24xlarge

  • db.x1.32xlarge

  • db.x1e.32xlarge

Pour de plus amples informations sur les classes d'instances prises en charge, veuillez consulter Instances de bases de données de la génération précédente.