Die vorliegende Übersetzung wurde maschinell erstellt. Im Falle eines Konflikts oder eines Widerspruchs zwischen dieser übersetzten Fassung und der englischen Fassung (einschließlich infolge von Verzögerungen bei der Übersetzung) ist die englische Fassung maßgeblich.
DB-Instances für Amazon RDS for Db2, MariaDB, MySQL, PostgreSQL, Oracle und Microsoft SQL Server verwenden Amazon Elastic Block Store (Amazon EBS) -Volumes für die Datenbank- und Protokollspeicherung.
Ihre Datenbank-Workload kann die bereitgestellten IOPS möglicherweise nicht zu 100 Prozent erreichen. Weitere Informationen finden Sie unter Faktoren, die die Datenbankleistung beeinflussen.
Weitere Informationen zu Preisen für Instance-Speicher erhalten Sie unter Amazon RDS-Preise
Themen
Amazon RDS-Speichertypen
Amazon RDS bietet drei Speichertypen: Bereitgestellte IOPS-SSD (auch bekannt als io1 und io2 Block Express), Allzweck-SSD (auch bekannt als gp2 und gp3) und magnetisch (auch bekannt als Standard). Diese unterscheiden sich bei den Leistungsmerkmalen und im Preis, das bedeutet, dass Sie die Speicherleistung und -kosten an die Anforderungen der Datenbank-Workload anpassen können. Sie können Db2-, MySQL-, MariaDB-, Oracle-, SQL Server- und PostgreSQL RDS-DB-Instances mit bis zu 64 Tebibyte (TiB) Speicher erstellen. RDS für Db2 unterstützt die Speichertypen GP2 und Magnetic nicht.
In der folgenden Liste werden die drei Speichertypen beschrieben:
-
Bereitgestellte IOPS-SSD – Bereitgestellter IOPS-Speicher ist darauf ausgelegt, die Anforderungen I/O-intensiver Workloads zu erfüllen, insbesondere von Datenbank-Workloads, bei denen eine geringe I/O-Latenz und ein konstanter I/O-Durchsatz erforderlich sind. Bereitgestellter IOPS-Speicher eignet sich am besten für Produktionsumgebungen.
Weitere Informationen über bereitgestellten IOPS-Speicher einschließlich der Speichergrößenbereiche finden Sie unter Bereitgestellter IOPS SSD-Speicher.
-
Allzweck-SSD – Diese Volumes bieten kosteneffizienten Speicher, der für ein breites Spektrum an Workloads, die auf mittelgroßen DB-Instances ausgeführt werden, geeignet ist. Allzweck-Speicher eignet sich am besten für Entwicklungs- und Testumgebungen.
Weitere Informationen über Allzweck-SSD einschließlich der Speichergrößenbereiche finden Sie unter Allzweck-SSD-Speicher.
-
Magnetspeicher – Amazon RDS unterstützt auch magnetische Speicherung für die Abwärtskompatibilität. Wir empfehlen generell die Nutzung von Allzweck-SSD-Speicher oder SSD-Speicher mit bereitgestellten IOPS. Die maximal zulässige Speichermenge für DB-Instances auf Magnetspeichern beträgt 3 TiB. Weitere Informationen finden Sie unter Magnetischer Speicher (veraltet, nicht empfohlen).
Bereitgestellter IOPS SSD-Speicher
Wir empfehlen für eine Produktionsanwendung, die eine schnelle und konsistente E/A-Leistung erfordert, Speicher mit bereitgestellten IOPS. Ein Speicher mit bereitgestellten IOPS liefert voraussagbare Leistung und konsistente niedrige Latenz. Speicher mit bereitgestellten IOPS ist für Workloads bei der Online-Transaktionsverarbeitung (OLTP) optimiert, die konsistente Performance erfordern. Speicher mit bereitgestellten IOPS trägt zur Optimierung dieser Workloads bei.
Amazon RDS bietet zwei Arten von bereitgestelltem IOPS-SSD-Speicher: io2 und io1. Wenn Sie eine DB-Instance erstellen, geben Sie die IOPS-Rate und die Größe des Volumes an. Amazon RDS stellt diese IOPS-Leistung für die DB-Instance bereit, bis Sie diese ändern.
Themen
io2 Block Express-Speicher (empfohlen)
Für I/O-intensive und latenzempfindliche Workloads empfehlen wir die Verwendung von Provisioned IOPS SSD io2 Block Express-Speicher, um bis zu 256.000 I/O-Operationen pro Sekunde (IOPS) zu erreichen. Der Durchsatz von io2 Block Express-Volumes hängt von der Anzahl der pro Volume bereitgestellten IOPS und der Größe der ausgeführten I/O-Operationen ab.
Alle RDS-io2-Volumes, die auf dem AWS Nitro-System basieren, sind io2 Block Express-Volumes und bieten eine durchschnittliche Latenz von unter einer Millisekunde. DB-Instances, die nicht auf dem Nitro-System basieren, sind io2-Volumes. AWS
Die folgende Tabelle zeigt den Bereich der bereitgestellten IOPS und den maximalen Durchsatz für jede Datenbank-Engine und jeden Speichergrößenbereich.
| Datenbank-Engine | Speicherplatzbereich | Bereitgestellte IOPS-Leistung | Maximaler Durchsatz |
|---|---|---|---|
| Db2, MariaDB, MySQL und PostgreSQL | 100—65.536 GiB | 1.000–256.000 IOPS | 16.000 MiB/s |
| Oracle | 100—199 GiB | 1.000—199.000 IOPS | 4 000 MiB/s |
| Oracle | 200—65.536 GiB | 1.000–256.000 IOPS | 16.000 MiB/s |
| SQL Server | 20—65.536 GiB | 1.000–256.000 IOPS | 4 000 MiB/s |
Für die IOPS- und Speichergrößenbereiche gelten die folgenden Einschränkungen:
-
Das Verhältnis von IOPS zu zugewiesenem Speicher (in GiB) muss zwischen 0,5 und 1.000 liegen. Für DB-Instances, die nicht auf dem AWS Nitro-System basieren, muss das Verhältnis zwischen 0,5 und 500 liegen.
-
Maximale IOPS können mit Volumes ab einer Größe von 256 GiB (1 000 IOPS × 256 GiB = 256 000 IOPS) bereitgestellt werden. Für DB-Instances, die nicht auf dem AWS Nitro System basieren, werden maximale IOPS bei 512 GiB erreicht (500 IOPS x 512 GiB = 256.000 IOPS).
-
Der Durchsatz wird proportional auf eine Größe von bis zu 0,256 skaliert. 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 Für DB-Instances, die nicht auf dem AWS Nitro-System basieren, beträgt der maximale Durchsatz eine Größe von 2.000. MiB/s can be achieved at 128,000 IOPS with a 16-KiB I/O
-
Wenn Sie die automatische Speicherskalierung verwenden, gelten auch die gleichen Verhältnisse zwischen IOPS und maximalem Speicherschwellenwert (in GiB). Weitere Informationen zur automatischen Speicherskalierung finden Sie unter Automatische Kapazitätsverwaltung mit automatischer Amazon RDS-Speicherskalierung.
Amazon RDS io2 Block Express-Volumes sind in den folgenden AWS-Regionen Formaten verfügbar:
-
Asien-Pazifik (Hongkong)
-
Asien-Pazifik (Mumbai)
-
Asia Pacific (Seoul)
-
Asien-Pazifik (Singapur)
-
Asien-Pazifik (Sydney)
-
Asien-Pazifik (Tokio)
-
Canada (Central)
-
Europe (Frankfurt)
-
Europa (Irland)
-
Europe (London)
-
Europe (Stockholm)
-
Middle East (Bahrain)
-
US East (Ohio)
-
USA Ost (Nord-Virginia)
-
USA West (Nordkalifornien)
-
USA West (Oregon)
io1-Speicher (vorherige Generation)
Für I/O-intensive Workloads können Sie bereitgestellten IOPS-SSD-io1-Speicher verwenden und bis zu 256 000 I/O-Vorgänge pro Sekunde (IOPS) erreichen. Der Durchsatz von io1-Volumes hängt von der Anzahl der pro Volume bereitgestellten IOPS und der Größe der ausgeführten I/O-Operationen ab. Wir empfehlen, io2 Block Express-Speicher zu verwenden, sofern er verfügbar ist.
Die folgende Tabelle zeigt den Bereich der bereitgestellten IOPS und den maximalen Durchsatz für jede Datenbank-Engine und jeden Speichergrößenbereich.
| Datenbank-Engine | Speicherplatzbereich | Bereitgestellte IOPS-Leistung | Maximaler Durchsatz |
|---|---|---|---|
| Db2, MariaDB, MySQL und PostgreSQL | 100—399 GiB | 1 000–19 950 IOPS | 500 MiB/s |
| Db2, MariaDB, MySQL und PostgreSQL | 400—65.536 GiB | 1.000–256.000 IOPS | 4 000 MiB/s |
| Oracle | 100—199 GiB | 1 000–9 950 IOPS | 500 MiB/s |
| Oracle | 200—65.536 GiB | 1.000—256.000 IOPS¹ | 4 000 MiB/s |
| SQL Server | 20—16.384 GiB | 1.000—64.000 IOPS² | 1 000 MiB/s |
Anmerkung
¹ Für Oracle können Sie die maximalen 256.000 IOPS nur für den Instance-Typ r5b bereitstellen.
² Für SQL Server ist die maximale Anzahl von 64.000 IOPS nur für Nitro-basierte Instances garantiert, die sich auf den Instance-Typen m5*, m6i, r5*, r6i und z1d befinden. Andere Instance-Typen garantieren eine Leistung von bis zu 32.000 IOPS.
Für die IOPS- und Speichergrößenbereiche gelten die folgenden Einschränkungen:
-
Das Verhältnis von IOPS zu zugewiesenem Speicher (in GiB) muss bei RDS für SQL Server zwischen 1-50 und bei anderen RDS-DB-Engines zwischen 0,5 und 50 liegen.
-
Wenn Sie die automatische Speicherskalierung verwenden, gelten auch die gleichen Verhältnisse zwischen IOPS und maximalem Speicherschwellenwert (in GiB).
Weitere Informationen zur automatischen Speicherskalierung finden Sie unter Automatische Kapazitätsverwaltung mit automatischer Amazon RDS-Speicherskalierung.
Kombinieren von bereitgestelltem IOPS-Speicher mit Multi-AZ-Bereitstellungen oder Lesereplikaten
Für OLTP-Anwendungsfälle in Produktionsumgebungen empfehlen wir die Verwendung von Multi-AZ-Bereitstellungen, da diese bei Speicher mit bereitgestellten IOPS, der schnelle und voraussagbare Leistung bereitstellt, eine erweiterte Fehlertoleranz bieten.
Sie können auch bereitgestellten IOPS-Speicher mit Read Replicas für MySQL, MariaDB oder PostgreSQL verwenden. Der Speichertyp für ein Read Replica ist von der Speicherart der primärem DB-Instance unabhängig. Beispielsweise verwenden Sie ggf. eine Allzweck-SSD für Read Replicas mit einer primären DB-Instance, die SSD-Speicher mit bereitgestellten IOPS nutzt, um Kosten zu sparen. Die Leistung Ihrer Read Replica kann sich in diesem Fall jedoch von der einer Konfiguration unterscheiden, bei der sowohl die primäre DB-Instance als auch die Read Replicas bereitgestellten IOPS-Speicher verwenden.
Kosten für bereitgestellten IOPS-Speicher
Bei Speicher mit bereitgestellten IOPS werden Ihnen die bereitgestellten Ressourcen berechnet, auch wenn Sie diese während des jeweiligen Monats nicht genutzt haben.
Weitere Informationen zu Preisen finden Sie unter Amazon RDS-Preise
Optimale Leistung aus dem von Amazon RDS bereitgestellten IOPS-Speicher herausholen
Wenn Ihre Arbeitslast I/O-Beschränkungen unterliegt, kann die Verwendung von bereitgestelltem IOPS-Speicher die Anzahl der I/O-Anfragen erhöhen, die das System gleichzeitig verarbeiten kann. Dadurch verringert sich die Latenz, da I/O-Anfragen weniger Zeit in der Warteschlange verbringen. Dadurch wiederum werden Datenbank-Commits beschleunigt, was die Reaktionszeit und den Datenbankdurchsatz verbessert.
Bereitgestellter IOPS-Speicher bietet eine Möglichkeit, I/O-Kapazität durch Angabe von IOPS zu reservieren. Der Maximaldurchsatz unter Last wird allerdings, wie alle anderen Systemkapazitätsattribute auch, durch diejenige Ressource begrenzt, die zuerst verbraucht wird. Dies kann entweder Netzwerkbandbreite, CPU, Arbeitsspeicher oder eine datenbankinterne Ressource sein.
Allzweck-SSD-Speicher
Allzweckspeicher bietet kostengünstigen Speicher, der für die meisten Datenbank-Workloads akzeptabel ist, die nicht latenz- oder leistungssensitiv sind.
Anmerkung
Bei DB-Instances, die Allzweckspeicher verwenden, kann es zu einer wesentlich längeren Latenz kommen als bei Instances, die bereitgestellten IOPS-Speicher verwenden. Wenn Sie nach diesen Vorgängen eine DB-Instance mit minimaler Latenz benötigen, empfehlen wir die Verwendung von Bereitgestellter IOPS SSD-Speicher.
Amazon RDS bietet zwei Arten von Allzweckspeicher: GP3-Speicher (empfohlen) undGP2-Speicher (vorherige Generation).
GP3-Speicher (empfohlen)
Durch die Verwendung von GP3-Allzweck-Speichervolumes können Sie die Speicherleistung unabhängig von der Speicherkapazität anpassen. Die Speicherleistung ist die Kombination aus I/O-Vorgängen pro Sekunde (IOPS) und der Schnelligkeit, mit der das Speichervolume Lese- und Schreibvorgänge ausführen kann (Speicherdurchsatz). Auf gp3-Speichervolumes bietet Amazon RDS eine Basisspeicherleistung von 3 000 IOPS und 125 MiB/s.
Bei jeder RDS-DB-Engine außer RDS für SQL Server steigt die Basisspeicherleistung, wenn die Speichergröße für GP3-Volumes einen bestimmten Schwellenwert erreicht. Dies ist auf das Volume-Striping zurückzuführen, bei dem der Speicher vier Volumes anstelle von einem verwendet. RDS für SQL Server unterstützt kein Volume-Striping und hat daher keinen Schwellenwert. Für Striped-Volumes bietet Amazon RDS eine Basisspeicherleistung von 12.000 IOPS und 500 MIB/s.
Die Speicherleistung für gp3-Volumes auf DB-Engines von Amazon RDS, einschließlich des Schwellenwerts, ist in der folgenden Tabelle dargestellt.
| DB-Engine | Speichergröße | Basisspeicherleistung | Bereitgestellte IOPS-Leistung | Bereich des bereitgestellten Speicherdurchsatzes |
|---|---|---|---|---|
| Db2, MariaDB, MySQL und PostgreSQL | 20—399 GiB | 3 000 IOPS/125 MiB/s | N/A | N/A |
| Db2, MariaDB, MySQL und PostgreSQL | 400—65.536 GiB | 12 000 IOPS/500 MiB/s | 12 000–64 000 IOPS | 500-4 000 MiB/s |
| Oracle | 20—199 GiB | 3 000 IOPS/125 MiB/s | N/A | N/A |
| Oracle | 200—65.536 GiB | 12 000 IOPS/500 MiB/s | 12 000–64 000 IOPS | 500-4 000 MiB/s |
| SQL Server | 20—16.384 GiB | 3 000 IOPS/125 MiB/s | 3 000–16 000 IOPS | 125–1 000 MiB/s |
Für jede DB-Engine außer RDS für SQL Server können Sie zusätzliche IOPS und zusätzlichen Speicherdurchsatz bereitstellen, wenn die Speichergröße den Schwellenwert erreicht oder überschreitet. Für RDS für SQL Server können Sie zusätzliche IOPS und zusätzlichen Speicherdurchsatz für jede verfügbare Speichergröße bereitstellen. Für alle DB-Engines zahlen Sie nur für die zusätzliche bereitgestellte Speicherleistung. Weitere Informationen finden Sie unter Amazon RDS – Preise
Die zusätzlichen bereitgestellten IOPS und der Speicherdurchsatz hängen zwar nicht von der Speichergröße ab, sind jedoch miteinander verbunden. Wenn Sie die IOPS für MariaDB und MySQL auf über 32.000 erhöhen, erhöht sich der Speicherdurchsatzwert automatisch von 500. MiBps Wenn Sie beispielsweise die IOPS auf RDS für MySQL auf 40.000 festlegen, muss der Speicherdurchsatz mindestens 625 MiBps betragen. Die automatische Erhöhung erfolgt nicht für Db2-, Oracle-, PostgreSQL- und SQL Server-DB-Instances.
Für Multi-AZ-DB-Cluster legt Amazon RDS den Durchsatzwert automatisch auf der Grundlage der von Ihnen bereitgestellten IOPS fest. Sie können den Durchsatzwert nicht ändern.
Für Speicherleistungswerte für gp3-Volumes in RDS gelten die folgenden Einschränkungen:
-
Das maximale Verhältnis von Speicherdurchsatz zu IOPS beträgt 0,25 für alle unterstützten DB-Engines.
-
Das Mindestverhältnis von IOPS zu zugewiesenem Speicher (in GiB) liegt für RDS für SQL Server bei 0,5. Für die anderen unterstützten DB-Engines gibt es kein Mindestverhältnis.
-
Das maximale Verhältnis von IOPS zu Speicherdurchsatz beträgt 500 für alle unterstützten DB-Engines.
-
Wenn Sie die automatische Speicherskalierung verwenden, gelten auch die gleichen Verhältnisse zwischen IOPS und maximalem Speicherschwellenwert (in GiB).
Weitere Informationen zur automatischen Speicherskalierung finden Sie unter Automatische Kapazitätsverwaltung mit automatischer Amazon RDS-Speicherskalierung.
GP2-Speicher (vorherige Generation)
Wenn Ihre Anwendungen keine hohe Speicherleistung benötigen, können Sie Allzweck-SSD-gp2-Speicher verwenden. Die I/O-Basisleistung bei gp2-Speicher liegt bei 3 IOPS pro GiB mit mindestens 100 IOPS. Dieses Verhältnis bedeutet, dass die Leistung bei großen Volumes besser. Die Basisleistung für ein 100-GiB-Volume beträgt beispielsweise 300 IOPS. Ein Volume mit 1 000 GiB verfügt über eine Basisleistung von 3 000 IOPS.
Einzelne gp2-Volumes unter 1 000 GiB können über einen längeren Zeitraum zudem bis auf 3 000 IOPS steigen. Die Steigerungsleistung wird durch das I/O-Guthaben des Volumes bestimmt. Eine detailliertere Beschreibung der Auswirkungen der Basisleistung und des I/O-Guthabensaldos auf die Leistung finden Sie im Beitrag Understanding Burst vs. Baseline Performance with Amazon RDS and gp2
Bei vielen Workloads wird die Burst-Balance nicht ausgeschöpft. Bei einigen Workloads kann das Burst-Speicherguthaben von 3.000 IOPS jedoch aufgebraucht sein. Planen Sie Ihre Speicherkapazität daher so, dass sie den Anforderungen Ihrer Workloads entspricht.
Bei GP2-Volumes mit mehr als 4.000 GiB ist die Basisleistung höher als die Burst-Leistung. Für solche Volumes ist die Spitzenlast irrelevant, da die Ausgangsleistung besser ist als die 3.000 IOPS-Spitzenlastleistung. Bei DB-Instances bestimmter Engines und Größen wird der Speicher durch Striping jedoch auf vier Volumes verteilt, was den vierfachen Basisdurchsatz und die vierfache IOPS-Spitzenleistung eines einzelnen Volumes bietet.
Die Speicherleistung für GP2-Volumes verschiedener Speichergrößen auf Amazon RDS-DB-Engines ist in der folgenden Tabelle dargestellt.
| DB-Engine | Größe des RDS-Speichers | Bereich der Basis-IOPS | Bereich des Baseline-Durchsatzes | IOPS-Spitzenleistung |
|---|---|---|---|---|
| MariaDB, MySQL und PostgreSQL | 5—399 GiB¹ | 100-1 197 IOPS | 128-250 MiB/s | 3,000 |
| MariaDB, MySQL und PostgreSQL | 400—1.335 GiB | 1 200-4 005 IOPS | 512—1.000 MiB/s | 12.000 |
| MariaDB, MySQL und PostgreSQL | 1.336—3.999 GiB | 4 008-11 997 IOPS | 1 000 MiB/s | 12.000 |
| MariaDB, MySQL und PostgreSQL | 4.000—65.536 GiB | 12 000–64 000 IOPS | 1 000 MiB/s | N/A² |
| Oracle | 20—199 GiB | 100-597 IOPS | 128-250 MiB/s | 3,000 |
| Oracle | 200—1.335 GiB | 600-4 005 IOPS | 512—1.000 MiB/s | 12.000 |
| Oracle | 1.336—3.999 GiB | 4 008-11 997 IOPS | 1 000 MiB/s | 12.000 |
| Oracle | 4.000—65.536 GiB | 12 000–64 000 IOPS | 1 000 MiB/s | N/A² |
| SQL Server | 20—333 GiB | 100-999 IOPS | 128-250 MiB/s | 3,000 |
| SQL Server | 334—999 GiB | 1 002–2 997 IOPS | 250 MiB/s | 3,000 |
| SQL Server | 1.000—16.384 GiB | 3 000–16 000 IOPS | 250 MiB/s | N/A² |
Anmerkung
¹ Mit dem AWS Management Console können Sie DB-Instances mit einer Mindestspeichergröße von 5 GiB im kostenlosen Kontingent für die DB-Instance-Klassen db.t3.micro und db.t4g.micro erstellen. Andernfalls beträgt die Mindestspeichergröße 20 GiB. Diese Einschränkung gilt nicht für die AWS CLI und RDS-API.
² Die Ausgangsleistung des Volumes übersteigt die maximale Burst-Leistung.
Leistungsmerkmale von Solid-State-Drive-Speichertypen (SSD)
Die folgende Tabelle zeigt Anwendungsfälle und Leistungsmerkmale der von Amazon RDS verwendeten SSD-Speicher-Volumes.
| Merkmal | Bereitgestellte IOPS (io2 Block Express) | Bereitgestellte IOPS (io1) | Allzweck (gp3) | Allzweck (gp2) |
|---|---|---|---|---|
| Beschreibung |
Höchste Leistung innerhalb des RDS-Speicherportfolios (IOPS, Durchsatz, Latenz) Konzipiert für latenzempfindliche, transaktionale Workloads |
Konsistente Speicherleistung (IOPS, Durchsatz, Latenz) Konzipiert für latenzempfindliche, transaktionale Workloads |
Flexibilität bei der unabhängigen Bereitstellung von Speicher, IOPS und Durchsatz Bietet ein günstiges Preis-Leistungs-Verhältnis für ein breites Spektrum an Transaktions-Workloads |
Bietet burstfähige IOPS Bietet ein günstiges Preis-Leistungs-Verhältnis für ein breites Spektrum an Transaktions-Workloads |
| Anwendungsfälle |
Geschäftskritische Transaktionsworkloads, die eine Latenz von unter einer Millisekunde und eine anhaltende IOPS-Leistung von bis zu 256.000 IOPS erfordern |
Transaktions-Workloads, die anhaltende IOPS-Leistung von bis zu 256 000 IOPS erfordern |
Breites Spektrum an Workloads, die auf mittelgroßen relationalen Datenbanken in Entwicklungs-/Testumgebungen ausgeführt werden |
Breites Spektrum an Workloads, die auf mittelgroßen relationalen Datenbanken in Entwicklungs-/Testumgebungen ausgeführt werden |
| Latency |
Im Submillisekundenbereich, konsistent in 99,9% der Fälle bereitgestellt |
Einstellige Millisekunde, die in 99,9 % der Fälle konstant bereitgestellt wird |
Einstellige Millisekunde, die in 99 % der Fälle konstant bereitgestellt wird |
Einstellige Millisekunde, die in 99 % der Fälle konstant bereitgestellt wird |
| Volume-Größe |
100—65.536 GiB |
100—65.536 GiB (20—16.384 GiB auf RDS für SQL Server) |
20—65.536 GiB (16.384 GiB auf RDS für SQL Server) |
20—65.536 GiB (16.384 GiB auf RDS für SQL Server) |
| Maximale IOPS |
256 000 |
256 000 (64 000 in RDS für SQL Server) |
64 000 (16 000 in RDS für SQL Server) |
64 000 (16 000 in RDS für SQL Server) AnmerkungSie können IOPS nicht direkt auf dem gp2-Speicher bereitstellen. IOPS variiert je nach Größe des zugewiesenen Speichers. |
| Maximaler Durchsatz |
Skaliert auf Basis der bereitgestellten IOPS bis zu 4 000 MB/s Der Durchsatz wird proportional auf eine Größe von bis zu 0,256 skaliert. 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 Für Instanzen, die nicht auf dem AWS Nitro-System basieren, beträgt der maximale Durchsatz eine Größe von 2.000. MiB/s can be achieved at 128,000 IOPS with a 16-KiB I/O |
Skaliert auf Basis der bereitgestellten IOPS bis zu 4 000 MB/s |
Stellen Sie zusätzlichen Durchsatz bereit (bis zu 4.000 MB/s (1000 MB/s auf RDS für SQL Server) |
1000 MB/s (250 MB/s auf RDS (für SQL Server) |
| AWS CLI und RDS-API-Name | io2 | io1 | gp3 | gp2 |
Automatisches Striping auf allen SSD-Volumes
Wenn Sie „Allzweck-SSD“ oder „Bereitgestellte IOPS-SSD“ auswählen, verteilt Amazon RDS je nach ausgewählter Engine und angeforderter Speichermenge Daten automatisch per Striping auf mehrere Volumes, um die Leistung zu verbessern, wie in der folgenden Tabelle dargestellt.
| Datenbank-Engine | Amazon-RDS-Speichergröße | Anzahl der bereitgestellten Volumes |
|---|---|---|
| Db2 | Weniger als 400 GiB | 1 |
| Db2 | 400—65.536 GiB | 4 |
| MariaDB, MySQL und PostgreSQL | Weniger als 400 GiB | 1 |
| MariaDB, MySQL und PostgreSQL | 400—65.536 GiB | 4 |
| Oracle | Weniger als 200 GiB | 1 |
| Oracle | 200—65.536 GiB | 4 |
| SQL Server | Any | 1 |
Auswirkungen auf die Leistung, wenn Sie ein SSD-Volume ändern
Wenn Sie ein Allzweck-SSD- oder Bereitgestelltes IOPS-SSD-Volume ändern, durchläuft es eine Reihe von Zuständen. Solange sich das Volume im optimizing Status befindet, liegt die Leistung Ihres Volumes zwischen den Quell- und Zielkonfigurationsspezifikationen. Die Leistung des Volumes in der Übergangszeit wird nicht geringer sein als die niedrigere der beiden Spezifikationen.
Wenn Sie den Speicher einer Instance so ändern, dass er von einem Volume auf vier Volumes wechselt, oder wenn Sie eine Instance mithilfe von Magnetspeicher ändern, verwendet Amazon RDS die Elastic Volumes-Funktion nicht. Stattdessen stellt Amazon RDS neue Volumes bereit und verschiebt die Daten transparent vom alten Volume auf die neuen Volumes. Dieser Vorgang verbraucht eine erhebliche Menge an IOPS und einen erheblichen Durchsatz sowohl des alten als auch des neuen Volumes. Abhängig von der Größe des Volumes und der Menge der Datenbank-Arbeitslast, die während der Änderung anfällt, kann dieser Vorgang eine hohe Menge an IOPS verbrauchen, die I/O-Latenz erheblich erhöhen und mehrere Stunden dauern, bis der Vorgang abgeschlossen ist, solange die RDS-Instance im Modifying Status bleibt.
Basiswerte und maximale IOPS-Raten für EBS-optimierte Instances
Für EBS-optimierte Instances gibt es eine Baseline und eine maximale IOPS-Rate. Die maximale IOPS-Rate wird auf DB-Instance-Ebene erzwungen. Eine Reihe von EBS-Volumes, die zusammen eine IOPS-Rate haben, die über dem Maximum liegt, darf den Schwellenwert auf Instance-Ebene nicht überschreiten. Wenn die maximale IOPS-Rate für eine bestimmte DB-Instance-Klasse beispielsweise 40 000 beträgt und Sie vier 64 000 IOPS-EBS-Volumes anhängen, beträgt die maximale IOPS-Rate 40 000 statt 256 000. Informationen zum IOPS-Maximum, das für jeden EC2 Instance-Typ spezifisch ist, finden Sie unter Unterstützte Instance-Typen im EC2 Amazon-Benutzerhandbuch für Linux-Instances.
Magnetischer Speicher (veraltet, nicht empfohlen)
Amazon RDS unterstützt außerdem aus Gründen der Rückwärtskompatibilität Magnetspeichergeräte. Wir empfehlen generell die Nutzung von Allzweck-SSD-Speicher oder SSD-Speicher mit bereitgestellten IOPS. Nachfolgend finden Sie einige Einschränkungen bei Magnetfestplatten:
Eine Speicherskalierung ist bei Verwendung der SQL Server-Datenbank-Engine nicht möglich.
-
Erlaubt Ihnen nicht, in einen anderen Speichertyp zu konvertieren, wenn Sie die SQL Server-Datenbank-Engine verwenden.
-
Automatische Speicherskalierung wird nicht unterstützt.
Unterstützt keine Zero-ETL-Integrationen mit Amazon Redshift.
Elastic Volumes werden nicht unterstützt.
Begrenzt auf eine Maximalgröße von 3 TiB.
Begrenzt auf eine Maximalgröße von 1.000 IOPS.
Dediziertes Protokollvolumen (DLV)
Sie können ein dediziertes Log-Volume (DLV) für eine DB-Instance verwenden, die Provisioned IOPS (PIOPS) -Speicher verwendet, indem Sie die Amazon RDS-Konsole oder die Amazon AWS CLI RDS-API verwenden. Ein DLV verschiebt Transaktionsprotokolle und Anforderungen 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 pro Sekunde (IOPS) für PostgreSQL-Datenbanken oder latenzempfindliche Workloads.
DLVs werden für PIOPS-Speicher (io1 und io2 Block Express) unterstützt und werden mit einer festen Größe von 1.024 GiB und 3.000 bereitgestellten IOPS erstellt.
Anmerkung
DLVs werden für Allzweckspeicher (gp2 und gp3) nicht unterstützt.
Amazon RDS unterstützt DLVs AWS-Regionen insgesamt die folgenden Versionen:
MariaDB 10.6.7 und höhere 10-Versionen
MySQL 8.0.28 und höhere 8.0-Versionen, MySQL 8.4.3 und höhere 8.4-Versionen
PostgreSQL 13.10 und höher 13 Versionen, 14.7 und höher 14 Versionen, 15.2 und höher 15 Versionen und 16.1 und höher 16 Versionen
RDS unterstützt Multi-AZ-Bereitstellungen. DLVs Wenn Sie eine Multi-AZ-Instance ändern oder erstellen, wird ein DLV sowohl für die primäre als auch für die sekundäre Instance erstellt.
RDS unterstützt DLVs mit Read Replicas. Wenn für die primäre DB-Instance ein DLV aktiviert ist, verfügen alle Lesereplikate, die nach der Aktivierung des DLV erstellt wurden, auch über ein DLV. Für alle Lesereplikate, die vor dem Wechsel zu DLV erstellt wurden, wird diese Funktion nicht aktiviert, sofern sie nicht ausdrücklich entsprechend geändert wurde. Wir empfehlen, dass alle Lesereplikate, die vor der Aktivierung von DLV einer primären Instance angefügt wurden, ebenfalls manuell so geändert werden, dass sie über ein DLV verfügen.
Nachdem Sie die DLV-Einstellung für eine DB-Instance geändert haben, muss die DB-Instance neu gestartet werden.
Informationen zur Aktivierung eines DLV finden Sie unter. Verwenden eines dedizierten Log-Volumes (DLV)
Überwachung der Datenbankleistung
Amazon RDS bietet mehrere Metriken, mit deren Hilfe Sie die Leistung der DB-Instance ermitteln können. Sie können die Metriken auf der Übersichtsseite Ihrer Instance in der Amazon RDS Management Console anzeigen. Sie können Amazon auch verwenden CloudWatch , um diese Metriken zu überwachen. Weitere Informationen finden Sie unter Metriken in der RDS Amazon-Konsole anzeigen. Erweiterte Überwachung bietet detailliertere I/O-Metriken. Weitere Informationen finden Sie unter Überwachen von Betriebssystem-Metriken mithilfe von „Enhanced Monitoring“·(Erweiterte·Überwachung).
Die folgenden Metriken sind nützlich, um die Leistung Ihrer DB-Instance zu überwachen:
-
DiskQueueDepth— Die Anzahl der I/O-Anfragen in der Warteschlange, die darauf warten, bearbeitet zu werden. Hierbei handelt es sich um E/A-Anfragen, die von der Anwendung übermittelt, aber noch nicht an das Gerät gesendet wurden, weil das Gerät mit anderen E/A-Anfragen beschäftigt ist. Zeit in der Warteschlange ist ein Teil der Latenz- und Verarbeitungszeit (nicht als Metrik verfügbar). Diese Metrik gibt die durchschnittliche Warteschlangentiefe für einen bestimmten Zeitraum an. Amazon RDS meldet die Warteschlangentiefe in Intervallen von 1 Minute. Übliche Werte für die Warteschlangentiefe liegen zwischen null und mehreren hundert. -
EBSByteBalance%— Der Prozentsatz der verbleibenden Durchsatz-Credits im Burst-Bucket Ihrer RDS-Datenbank. Diese Metrik ist nur für die grundlegende Überwachung verfügbar. Der Metrikwert basiert auf dem Durchsatz aller Volumes, einschließlich des Root-Volumes, und nicht nur auf den Volumes, die Datenbankdateien enthalten.Wenn sich diese Metrik Null nähert, bedeutet dies, dass Ihrer DB-Instance die Rechenkapazität ausgeht. Wenn dies regelmäßig passiert, sollten Sie ein Upgrade auf eine größere Instance-Klassengröße in Betracht ziehen, z. B. von db.r6g.large auf db.r6g.xlarge. Weitere Informationen finden Sie unter DB-Instance-Klasse.
-
ReadIOPSund — Die Anzahl der pro Sekunde abgeschlossenen I/O-Operationen.WriteIOPSDiese Metrik gibt die durchschnittliche IOPS für einen bestimmten Zeitraum an. Amazon RDS meldet Lese- und Schreib-IOPS getrennt in 1-Minuten-Intervallen.TotalIOPSist die Summe der Lese- und Schreib-IOPS. Übliche Werte für IOPS liegen zwischen null und mehreren zehntausend pro Sekunde.Wenn sich Ihre
TotalIOPSWerte regelmäßig dem Wert für bereitgestellte IOPS nähern, den Sie für Ihre DB-Instance festgelegt haben, sollten Sie eine Erhöhung der bereitgestellten IOPS (Speichertypen io1, io2 Block Express und gp3) in Betracht ziehen.Gemessene IOPS-Werte sind von der Größe der individuellen I/O-Operation unabhängig. Wenn Sie die I/O-Leistung messen, müssen Sie auf den Durchsatz der Instance achten und nicht einfach auf die Anzahl der I/O-Operationen.
-
ReadLatencyundWriteLatency— Die verstrichene Zeit zwischen der Übermittlung einer I/O-Anfrage und deren Abschluss. Diese Metrik gibt die durchschnittliche Latenz für einen bestimmten Zeitraum an. Amazon RDS gibt Lese- und Schreib-Latenz separat für 1-minütige Intervalle an. Übliche Werte für die Latenz liegen im Millisekundenbereich (ms). -
ReadThroughputundWriteThroughput— Die Anzahl der Byte pro Sekunde, die auf oder von der Festplatte übertragen werden. Diese Metrik gibt den durchschnittlichen Durchsatz für einen bestimmten Zeitraum an. Amazon RDS meldet den Lese- und Schreibdurchsatz getrennt in Intervallen von 1 Minute in Einheiten von Byte pro Sekunde (B/s). Übliche Werte für den Durchsatz liegen zwischen null und der maximalen Bandbreite des E/A-Kanals.Wenn sich Ihre Durchsatzwerte regelmäßig dem maximalen Durchsatz für Ihre DB-Instance nähern, sollten Sie erwägen, mehr Speicherdurchsatz bereitzustellen, wenn Sie den Speichertyp gp3 verwenden.
Faktoren, die die Datenbankleistung beeinflussen
Systemaktivitäten, Datenbank-Workload und DB-Instance-Klasse können sich auf die Datenbankleistung auswirken.
Systemaktivitäten
Die folgenden systembezogenen Aktivitäten verbrauchen I/O-Kapazität und verringern möglicherweise die Leistung der DB-Instance, wenn sie ausgeführt werden:
-
Standby-Erstellung mit Multi-AZ
-
Read Replica-Erstellung
-
Ändern von Speichertypen
Datenbank-Workload
In einigen Fällen führt der Entwurf Ihrer Datenbank oder Anwendung zu Gleichzeitigkeitsproblemen, Sperren oder anderen Datenbankkonflikten. Dann können Sie die gesamte bereitgestellte Bandbreite möglicherweise nicht direkt nutzen. Außerdem kann es zu folgenden Situationen bezüglich des Workloads kommen:
-
Die Durchsatzgrenze des zugrunde liegenden Instance-Typs wird erreicht.
-
Die Tiefe der Warteschlange liegt konstant unter 1, da Ihre Anwendung nicht genug I/O-Operationen durchführen kann.
-
Sie bemerken auch bei noch ungenutzter I/O-Kapazität Abfragekonflikte in der Datenbank.
In einigen Fällen gibt es keine Systemressource, die an oder nahe einem Limit liegt, und das Hinzufügen von Threads erhöht die Datenbanktransaktionsrate nicht. In solchen Fällen ist der Engpass höchstwahrscheinlich ein Konflikt in der Datenbank. Die verbreitetsten Formen sind Zeilensperr- und Indexseitensperrkonflikte, aber zahlreiche andere Möglichkeiten bestehen ebenso. Falls dies Ihre Situation beschreibt, sollten Sie den Rat eines Experten für die Optimierung der Datenbankleistung einholen.
DB-Instance-Klasse
Um Ihre Amazon RDS-DB-Instance optimal zu nutzen, sollten Sie einen aktuellen Instance-Typ mit ausreichend Bandbreite für Ihren Speichertyp verwenden. Sie können beispielsweise Amazon-EBS-optimierte Instances und Instances mit einer 10-Gigabit-Netzwerkanbindung nutzen.
Wichtig
Je nach der von Ihnen verwendeten Instance-Klasse kann die IOPS-Leistung unter dem Maximum liegen, das Sie mit RDS bereitstellen können. Spezifische Informationen zur IOPS-Leistung für DB-Instance-Klassen finden Sie unter Amazon EBS — Optimized Instances im EC2 Amazon-Benutzerhandbuch. Wir empfehlen, dass Sie die maximale IOPS-Anzahl für die Instance-Klasse bestimmen, bevor Sie einen bereitgestellten IOPS-Wert für Ihre DB-Instance festlegen.
Wir empfehlen Ihnen, Instances der aktuellen Generation zu verwenden, um die bestmögliche Leistung zu erhalten. DB-Instances der vorherigen Generation können auch einen geringeren maximalen Speicherplatz haben.
Einige ältere 32-Bit-Dateisysteme haben möglicherweise geringere Speicherkapazitäten. Um die Speicherkapazität Ihrer DB-Instance zu ermitteln, können Sie den describe-valid-db-instance Befehl -modifications verwenden. AWS CLI
Die folgende Liste zeigt den maximalen Speicherplatz, auf den die meisten DB-Instance-Klassen für jede Datenbank-Engine skalieren können:
-
Db2 — 64 TiB
-
MariaDB: 64 TiB
-
Microsoft SQL Server — 64 TiB
-
MySQL: 64 TiB
-
Oracle: 64 TiB
-
PostgreSQL: 64 TiB
In der folgenden Tabelle werden einige Ausnahmen für maximalen Speicherplatz (in TiB) angezeigt. Alle RDS für Microsoft SQL Server-DB-Instances mit Ausnahme des io2 Block Express-Speichers haben einen maximalen Speicherplatz von 16 TiB, sodass es keine Einträge für SQL Server gibt.
| Instance-Klasse | Db2 | MariaDB | MySQL | Oracle | PostgreSQL |
|---|---|---|---|---|---|
| db.m3 – Standard-Instance-Klassen | |||||
| db.t4g – Instance-Klassen mit Spitzenlastleistung | |||||
| db.t4g.medium | N/A | 16 | 16 | N/A | 32 |
| db.t4g.klein | N/A | 16 | 16 | N/A | 16 |
| db.t4g.micro | N/A | 6 | 6 | N/A | 6 |
| db.t3 – Instance-Klassen mit Spitzenlastleistung | |||||
| 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 – Instance-Klassen mit Spitzenlastleistung | |||||
Weitere Informationen zu allen unterstützten Instance-Klassen finden Sie unter DB-Instances der vorherigen Generation
