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.
# DynamoDB-Durchsatzkapazität
Dieser Abschnitt enthält einen Überblick über die beiden Durchsatzmodi, die für Ihre DynamoDB-Tabelle verfügbar sind, sowie Überlegungen zur Auswahl des geeigneten Kapazitätsmodus für Ihre Anwendung. Der Durchsatzmodus einer Tabelle bestimmt, wie die Kapazität einer Tabelle verwaltet wird. Der Durchsatzmodus bestimmt auch, wie Ihnen die Lese- und Schreibvorgänge in Ihren Tabellen in Rechnung gestellt werden. In Amazon DynamoDB können Sie zwischen dem **On-Demand-Modus** und dem **Modus bereitgestellter Kapazität** für Ihre Tabellen wählen, um unterschiedlichen Workload-Anforderungen gerecht zu werden.
**Topics**
+ [On-Demand-Modus](#capacity-mode-on-demand)
+ [Modus bereitgestellter Kapazität](#capacity-mode-provisioned)
+ [On-Demand-Kapazitätsmodus von DynamoDB](on-demand-capacity-mode.md)
+ [DynamoDB – Modus mit bereitgestellter Kapazität](provisioned-capacity-mode.md)
+ [Grundlegendes zum Warmdurchsatz von DynamoDB](warm-throughput.md)
+ [DynamoDB – Burst- und adaptive Kapazität](burst-adaptive-capacity.md)
+ [Überlegungen beim Umstellen der Kapazitätsmodi in DynamoDB](bp-switching-capacity-modes.md)
## On-Demand-Modus
Der On-Demand-Modus von Amazon DynamoDB ist eine Serverless-Durchsatzoption, die das Datenbankmanagement vereinfacht und automatisch skaliert, um die anspruchsvollsten Anwendungen der Kunden zu unterstützen. Mit DynamoDB On-Demand können Sie eine Tabelle erstellen, ohne sich Gedanken über Kapazitätsplanung, Nutzungsüberwachung und die Konfiguration von Skalierungsrichtlinien machen zu müssen. DynamoDB On-Demand bietet pay-per-request Preise für Lese- und Schreibanforderungen, sodass Sie nur für das bezahlen, was Sie tatsächlich nutzen. Für On-Demand-Modustabellen müssen Sie nicht angeben, wie viel Lese- und Schreibdurchsatz Sie von Ihrer Anwendung erwarten.
Der On-Demand-Modus ist die standardmäßige und empfohlene Durchsatzoption für die meisten DynamoDB-Workloads. DynamoDB kümmert sich um alle Aspekte der Durchsatzverwaltung und -skalierung, um Workloads zu unterstützen, die klein beginnen und auf Millionen von Anforderungen pro Sekunde skaliert werden. Sie können nach Bedarf Lese- und Schreibvorgänge in Ihrer DynamoDB-Tabellen ausführen, ohne die Durchsatzkapazität der Tabelle verwalten zu müssen. Weitere Informationen finden Sie unter [On-Demand-Kapazitätsmodus von DynamoDB](on-demand-capacity-mode.md).
## Modus bereitgestellter Kapazität
Im Modus bereitgestellter Kapazität müssen Sie die Anzahl der Lese- und Schreibvorgänge pro Sekunde festlegen, die Sie für Ihre Anwendung benötigen. Die Abrechnung erfolgt auf der Grundlage der von Ihnen bereitgestellten stündlichen Lese- und Schreibkapazität. Sie basiert nicht darauf, wie viel von der bereitgestellten Kapazität Sie tatsächlich verbraucht haben. Auf diese Weise können Sie leicht regeln, dass Ihre DynamoDB-Nutzung eine definierte Anforderungsrate nicht überschreitet, um planbare Kosten zu erzielen.
Sie können die bereitgestellte Kapazität nutzen, wenn Sie über konstante Workloads mit vorhersehbarem Wachstum verfügen und Sie die Kapazitätsanforderungen für Ihre Anwendung zuverlässig prognostizieren können. Weitere Informationen finden Sie unter [DynamoDB – Modus mit bereitgestellter Kapazität](provisioned-capacity-mode.md).
# On-Demand-Kapazitätsmodus von DynamoDB
Amazon DynamoDB On-Demand bietet ein echtes Serverless-Datenbankerlebnis, das automatisch skaliert wird, um die anspruchsvollsten Workloads ohne Kapazitätsplanung zu bewältigen. Der On-Demand-Modus vereinfacht den Einrichtungsprozess, macht die Kapazitätsverwaltung und -überwachung überflüssig und ermöglicht eine schnelle, automatische Skalierung. Bei der pay-per-request Preisgestaltung müssen Sie sich keine Gedanken über ungenutzte Kapazitäten machen, da Sie nur für den Durchsatz zahlen, den Sie tatsächlich nutzen. Die Abrechnung erfolgt pro Lese- oder Schreibanforderung, sodass Ihre Kosten direkt Ihre tatsächliche Nutzung widerspiegeln.
Wenn Sie den On-Demand-Modus wählen, passt DynamoDB Ihre Workloads, wenn sie steigen oder sinken, sofort an einen beliebigen zuvor erreichten Stand des Datenverkehrs an. Wenn der Datenverkehr eines Workloads einen neuen Höchststand erreicht, skaliert DynamoDB automatisch, um den erhöhten Durchsatzanforderungen gerecht zu werden. Der On-Demand-Modus ist die standardmäßige und empfohlene Durchsatzoption, da er die Erstellung moderner Serverless-Anwendungen vereinfacht, die klein beginnen und auf Millionen von Anforderungen pro Sekunde skaliert werden. Sobald Ihre On-Demand-Tabelle aufskaliert ist, können Sie künftig sofort wieder denselben Durchsatz erzielen, ohne dass eine Drosselung erforderlich ist. Wenn Sie keinen Traffic zu Ihrer Tabelle lenken, wird Ihnen bei On-Demand-Modus kein Durchsatz in Rechnung gestellt. Weitere Informationen zu den Skalierungseigenschaften des On-Demand-Modus finden Sie unter [Anfänglicher Durchsatz und Skalierungseigenschaften](#on-demand-capacity-mode-initial).
Tabellen, die den On-Demand-Modus nutzen, erzielen dieselbe Latenz im einstelligen Millisekundenbereich, das Service Level Agreement (SLA) und die Sicherheit, die vom DynamoDB-Modus bereitgestellter Kapazität geboten werden.
**Anmerkung**
Standardmäßig schützt DynamoDB Sie vor unbeabsichtigter, unkontrollierter Nutzung. Um die Durchsatzgrenzen von 40 000 Lese- und Schreibvorgängen auf Tabellenebene für alle Tabellen in Ihrem Konto zu überschreiten, können Sie eine Erhöhung dieses Kontingents anfordern. Durchsatzanforderungen, die das standardmäßige Durchsatzkontingent der Tabelle überschreiten, werden gedrosselt. Weitere Informationen finden Sie unter [Standardkontingente für den Durchsatz](ServiceQuotas.md#default-limits-throughput).
Optional können Sie auch den maximalen Lese- oder Schreibdurchsatz (oder beides) pro Sekunde für einzelne On-Demand-Tabellen und globale sekundäre Indizes konfigurieren. Durch die Konfiguration des Durchsatzes können Sie die Nutzung und Kosten auf Tabellenebene begrenzen, sich vor einem unbeabsichtigten Anstieg verbrauchter Ressourcen schützen und eine übermäßige Nutzung verhindern, um ein vorhersehbares Kostenmanagement zu gewährleisten. Durchsatzanforderungen, die den maximalen Tabellendurchsatz überschreiten, werden gedrosselt. Sie können den tabellenspezifischen maximalen Durchsatz jederzeit an Ihre Anwendungsanforderungen anpassen. Weitere Informationen finden Sie unter [Maximaler DynamoDB-Durchsatz für On-Demand-Tabellen](on-demand-capacity-mode-max-throughput.md).
Erstellen oder aktualisieren Sie zunächst eine Tabelle zur Verwendung des On-Demand-Modus. Weitere Informationen finden Sie unter [Grundlegende Operationen für DynamoDB-Tabellen](WorkingWithTables.Basics.md).
Sie können Tabellen innerhalb eines fortlaufenden 24-stündigen Zeitfensters bis zu viermal vom Modus mit bereitgestellter Kapazität auf den On-Demand-Modus umstellen. Sie können Tabellen jederzeit vom On-Demand-Modus auf den Modus mit bereitgestellter Kapazität umstellen.
Weitere Informationen zum Wechseln zwischen Lese- und Schreibkapazitätsmodus finden Sie unter [Überlegungen beim Umstellen der Kapazitätsmodi in DynamoDB](bp-switching-capacity-modes.md). Informationen zu On-Demand-Tabellenkontingenten finden Sie unter [Lese- und Schreibdurchsatz](ServiceQuotas.md#default-limits-throughput-capacity-modes).
**Topics**
+ [Leseanforderungseinheiten und Schreibanforderungseinheiten](#read-write-request-units)
+ [Anfänglicher Durchsatz und Skalierungseigenschaften](#on-demand-capacity-mode-initial)
+ [Maximaler DynamoDB-Durchsatz für On-Demand-Tabellen](on-demand-capacity-mode-max-throughput.md)
## Leseanforderungseinheiten und Schreibanforderungseinheiten
DynamoDB berechnet Ihnen die Lese- und Schreibvorgänge, die Ihre Anwendung bei Ihren Tabellen durchführt, als *Leseanforderungseinheiten* und als *Schreibanforderungseinheiten*.
Eine *Leseanforderungseinheit* entspricht einem strikt konsistenten Lesevorgang pro Sekunde oder zwei letztendlich konsistenten Lesevorgängen pro Sekunde für ein Element mit einer Größe von bis zu 4 KB. Weitere Informationen über die DynamoDB-Lesekonsistenzmodelle finden Sie unter [DynamoDB-Lesekonsistenz](HowItWorks.ReadConsistency.md).
Eine *Schreibanforderungseinheit* entspricht einem Schreibvorgang pro Sekunde für ein Element mit einer Größe von bis zu 1 KB.
Weitere Informationen zum Verbrauch von Lese- und Schreibeinheiten finden Sie unter [Lese- und Schreibvorgänge in DynamoDB](read-write-operations.md).
## Anfänglicher Durchsatz und Skalierungseigenschaften
DynamoDB-Tabellen mit dem On-Demand-Kapazitätsmodus passen sich automatisch an das Datenverkehrsaufkommen Ihrer Anwendung an. Neue On-Demand-Tabellen können bis zu 4 000 Schreibvorgänge pro Sekunde und 12 000 Lesevorgänge pro Sekunde verarbeiten. Der On-Demand-Kapazitätsmodus passt sich sofort an bis zu das Doppelte des vorherigen Höchststands des Datenverkehrs für eine Tabelle an. Nehmen wir z. B. an, dass das Datenverkehrsmuster Ihrer Anwendung zwischen 25 000 und 50 000 strikt konsistenten Lesevorgängen pro Sekunde variiert. Der vorherige Höchststand des Datenverkehrs liegt bei 50 000 Lesevorgängen pro Sekunde. Der On-Demand-Kapazitätsmodus ermöglicht sofort einen anhaltenden Datenverkehr von bis zu 100 000 Lesevorgängen pro Sekunde. Wenn Ihre Anwendung einen Datenverkehr von 100 000 Lesevorgängen pro Sekunde aufrechterhält, wird dieser Höchststand zum neuen vorherigen Höchststand. Dieser Höchststand ermöglicht es, dass ein nachfolgender Datenverkehr von bis zu 200 000 Lesevorgängen pro Sekunde erreicht werden kann.
Wenn Ihr Workload mehr als das Doppelte des vorherigen Höchststands für eine Tabelle generiert, weist DynamoDB automatisch mehr Kapazität zu, während sich Ihr Verkehrsaufkommen erhöht. Diese Kapazitätszuweisung trägt dazu bei, dass Ihr Workload nicht gedrosselt wird. Eine Drosselung kann jedoch eintreten, wenn Sie innerhalb von 30 Minuten das Doppelte Ihres vorherigen Höchststands überschreiten. Nehmen wir z. B. an, dass das Datenverkehrsmuster Ihrer Anwendung zwischen 25 000 und 50 000 strikt konsistenten Lesevorgängen pro Sekunde variiert. Der vorherige Höchststand des Datenverkehrs liegt bei 50 000 Lesevorgängen pro Sekunde. Wir empfehlen, Ihre Tabelle entsprechend vorzubereiten oder Ihr Datenverkehrswachstum auf mindestens 30 Minuten zu verteilen, bevor Sie mehr als 100 000 Lesevorgänge pro Sekunde erreichen. Weitere Informationen zum Vorwärmen finden Sie unter [Grundlegendes zum Warmdurchsatz von DynamoDB](warm-throughput.md).
DynamoDB legt die 30-minütige Drosselungsbeschränkung nicht fest, wenn der Höchststand des Datenverkehrs Ihres Workloads innerhalb des Doppelten des vorherigen Höchststands bleibt. Wenn der Höchststand Ihres Datenverkehrs das Doppelte des Höchststands überschreitet, stellen Sie sicher, dass dieses Wachstum 30 Minuten nach dem letzten Erreichen des Höchststands erfolgt.
# Maximaler DynamoDB-Durchsatz für On-Demand-Tabellen
Für On-Demand-Tabellen können Sie optional den maximalen Lese- oder Schreibdurchsatz (oder beides) pro Sekunde für einzelne Tabellen und zugehörige globale Sekundärindizes (GSIs) angeben. Die Angabe eines maximalen On-Demand-Durchsatzes trägt dazu bei, die Nutzung und die Kosten auf Tabellenebene zu begrenzen. Standardmäßig gelten die Einstellungen für den maximalen Durchsatz nicht. Ihre On-Demand-Durchsatzrate ist durch ein [AWS -Servicekontingent](ServiceQuotas.md#default-limits-throughput) auf einen Durchsatz von 40 000 Lese- und Schreibvorgängen auf Tabellenebene für alle Tabellen im Konto begrenzt. Bei Bedarf können Sie eine Erhöhung des Servicekontingents beantragen.
Wenn Sie den maximalen Durchsatz für eine On-Demand-Tabelle konfigurieren, werden Durchsatzanforderungen, die den angegebenen Höchstwert überschreiten, gedrosselt. Sie können die Einstellungen für den maximalen Durchsatz auf Tabellenebene jederzeit an Ihre Anwendungsanforderungen anpassen.
Im Folgenden sind einige gängige Anwendungsfälle aufgeführt, für die der maximale Durchsatz für On-Demand-Tabellen von Vorteil sein kann:
+ **Optimierung der Durchsatzkosten** – Die Verwendung des maximalen Durchsatzes für On-Demand-Tabellen bietet eine zusätzliche Ebene der Kostenvorhersehbarkeit und Verwaltbarkeit. Darüber hinaus profitieren Sie von mehr Flexibilität mit dem On-Demand-Modus zur Unterstützung von Workloads mit unterschiedlichen Datenverkehrsmustern und Budgets.
+ **Schutz vor übermäßiger Nutzung** – Wenn Sie den maximalen Durchsatz festlegen, können Sie verhindern, dass bei einer On-Demand-Tabelle ein unbeabsichtigter Anstieg des Lese- oder Schreibverbrauchs auftritt, der durch nicht optimierten Code oder nicht autorisierte Prozesse entstehen könnte. Diese Einstellung auf Tabellenebene kann Unternehmen davor schützen, innerhalb eines bestimmten Zeitraums übermäßig viele Ressourcen zu verbrauchen.
+ **Schutz nachgelagerter Dienste** – Eine Kundenanwendung kann Serverless- und Nicht-Serverless-Technologien beinhalten. Der Serverless-Teil der Architektur kann schnell skaliert werden, um den Anforderungen gerecht zu werden. Nachgelagerte Komponenten mit festen Kapazitäten könnten jedoch überlastet sein. Durch die Implementierung von Einstellungen für den maximalen Durchsatz für On-Demand-Tabellen kann verhindert werden, dass große Mengen von Ereignissen mit unerwarteten negativen Auswirkungen auf mehrere nachgelagerte Komponenten übertragen werden.
Sie können den maximalen Durchsatz für den On-Demand-Modus für neue und bestehende Tabellen mit einer Region und globale Tabellen und konfigurieren. GSIs Sie können den maximalen Durchsatz außerdem bei der Tabellenwiederherstellung und beim Datenimport aus Amazon-S3-Workflows konfigurieren.
Sie können die Einstellungen für den maximalen Durchsatz für On-Demand-Tabellen über die [DynamoDB-Konsole](https://console.aws.amazon.com/dynamodb/), die [AWS CLI](AccessingDynamoDB.md#Tools.CLI), [AWS CloudFormation](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-resource-dynamodb-table.html) oder die [DynamoDB-API](https://docs.aws.amazon.com/amazondynamodb/latest/APIReference/Welcome.html) festlegen.
**Anmerkung**
Der maximale Durchsatz für eine On-Demand-Tabelle wird mit bestem Bemühen angewendet und sollte als Ziel und nicht als garantierte Anforderungsobergrenze betrachtet werden. Ihr Workload kann aufgrund der [*Burst-Kapazität*](burst-adaptive-capacity.md#burst-capacity) vorübergehend den angegebenen maximalen Durchsatz überschreiten. In einigen Fällen verwendet DynamoDB die *Burst-Kapazität*, um Lese- und Schreibvorgänge zu bewältigen, die Ihre Einstellungen für den maximalen Durchsatz der Tabelle überschreiten. Mit Burst-Kapazität können unerwartete Lese- oder Schreibanforderungen erfolgreich sein, wo sie andernfalls gedrosselt werden würden.
**Topics**
+ [Überlegungen zur Verwendung des maximalen Durchsatzes für den On-Demand-Modus](#consideration-use-max-throughput-ondemand)
+ [Drosselung und Metriken anfordern CloudWatch](#max-throughput-ondemand-request-throttle)
## Überlegungen zur Verwendung des maximalen Durchsatzes für den On-Demand-Modus
Wenn Sie den maximalen Durchsatz für Tabellen im On-Demand-Modus verwenden, gelten die folgenden Überlegungen:
+ Sie können unabhängig voneinander den maximalen Durchsatz für Lese- und Schreibvorgänge für jede On-Demand-Tabelle oder einen einzelnen globalen sekundären Index innerhalb dieser Tabelle festlegen, um Ihren Ansatz auf der Grundlage spezifischer Anforderungen zu optimieren.
+ Sie können Amazon verwenden CloudWatch , um DynamoDB-Nutzungsmetriken auf Tabellenebene zu überwachen und zu verstehen und die geeigneten Einstellungen für den maximalen Durchsatz für den On-Demand-Modus zu ermitteln. Weitere Informationen finden Sie unter [DynamoDB-Metriken und -Dimensionen](metrics-dimensions.md).
+ Wenn Sie die Einstellungen für den maximalen Lese- oder Schreibdurchsatz (oder beide) für ein Replikat einer globalen Tabelle angeben, werden dieselben Einstellungen für den maximalen Durchsatz automatisch auf alle Replikattabellen angewendet. Es ist wichtig, dass die Replikattabellen und sekundären Indizes in einer globalen Tabelle über identische Schreibdurchsatzeinstellungen verfügen, um eine ordnungsgemäße Replikation der Daten sicherzustellen. Weitere Informationen finden Sie unter [Bewährte Methoden für globale Tabellen](globaltables-bestpractices.md).
+ Der kleinste maximale Lese- oder Schreibdurchsatz, den Sie angeben können, ist eine Anforderungseinheit pro Sekunde.
+ Der von Ihnen angegebene maximale Durchsatz muss unter dem Standard-Durchsatzkontingent liegen, das für jede On-Demand-Tabelle oder einen einzelnen globalen sekundären Index innerhalb dieser Tabelle verfügbar ist.
## Drosselung und Metriken anfordern CloudWatch
Wenn Ihre Anwendung den maximalen Lese- oder Schreibdurchsatz überschreitet, den Sie für Ihre On-Demand-Tabelle festgelegt haben, beginnt DynamoDB, diese Anforderungen zu drosseln. Wenn DynamoDB einen Lese- oder Schreibvorgang drosselt, gibt er eine `ThrottlingException` an den Aufrufer zurück. Sie können dann, falls erforderlich, entsprechende Maßnahmen ergreifen. Sie können beispielsweise die Einstellung für den maximalen Tabellendurchsatz erhöhen oder deaktivieren oder kurz warten, bevor Sie die Anforderung erneut versuchen.
Um die Überwachung des für eine Tabelle oder einen globalen sekundären Index konfigurierten maximalen Durchsatzes zu vereinfachen, CloudWatch bietet die folgenden Metriken: [OnDemandMaxReadRequestUnits](metrics-dimensions.md#OnDemandMaxReadRequestUnits) und. [OnDemandMaxWriteRequestUnits](metrics-dimensions.md#OnDemandMaxWriteRequestUnits)
# DynamoDB – Modus mit bereitgestellter Kapazität
Wenn Sie eine neue bereitgestellte Tabelle in DynamoDB erstellen, müssen Sie ihre *bereitgestellte Durchsatzkapazität* angeben. Dies ist der Umfang des Lese- und Schreibdurchsatzes, der von der Tabelle unterstützt werden kann. Die Abrechnung erfolgt auf der Grundlage der von Ihnen bereitgestellten stündlichen Lese- und Schreibkapazität. Sie basiert nicht darauf, wie viel von der bereitgestellten Kapazität Sie tatsächlich verbraucht haben.
Da sich Ihre Anwendungsdaten und Zugriffsanforderungen ändern, müssen Sie möglicherweise die Durchsatzeinstellungen der Tabelle anpassen. Die bereitgestellte Kapazität Ihrer Tabelle kann mithilfe von Auto Scaling als Reaktion auf Datenverkehrsänderungen automatisch angepasst werden. DynamoDB Auto Scaling verwendet eine [Skalierungsrichtlinie](https://docs.aws.amazon.com/autoscaling/application/userguide/application-auto-scaling-target-tracking.html) in [Application Auto Scaling](https://docs.aws.amazon.com/autoscaling/application/userguide/what-is-application-auto-scaling.html). Um Auto Scaling in DynamoDB zu konfigurieren, legen Sie zusätzlich zum Zielauslastungsprozentsatz die Mindest- und Höchstwerte der Lese- und Schreibkapazität fest. Application Auto Scaling erstellt und verwaltet die CloudWatch Alarme, die Skalierungsereignisse auslösen, wenn die Metrik vom Ziel abweicht. Auto Scaling überwacht die Aktivität Ihrer Tabelle und passt ihre Kapazitätseinstellungen basierend auf vorkonfigurierten Schwellenwerten nach oben oder unten an. Auto Scaling wird ausgelöst, wenn Ihre verbrauchte Kapazität für zwei aufeinanderfolgende Minuten die konfigurierte Zielauslastung überschreitet. CloudWatch Alarme können eine kurze Verzögerung von bis zu einigen Minuten haben, bevor sie die auto Skalierung auslösen. Weitere Informationen finden Sie unter [Automatische Verwaltung der Durchsatzkapazität mit DynamoDB-Auto-Scaling](AutoScaling.md).
Wenn Sie DynamoDB-Auto-Scaling verwenden, werden die Durchsatzeinstellungen automatisch, entsprechend der tatsächlichen Workloads, angepasst. Sie können auch die [UpdateTable](https://docs.aws.amazon.com/amazondynamodb/latest/APIReference/API_UpdateTable.html)-Operation verwenden, um die Durchsatzkapazität der Tabelle manuell anzupassen. Dafür können Sie sich beispielsweise entscheiden, wenn Sie Daten per Massenladevorgang aus einem vorhandenen Datenspeicher in die neue DynamoDB-Tabelle übertragen müssen. Sie könnten die Tabelle mit einer Einstellung für einen großen Schreibdurchsatz erstellen und anschließend diese Einstellung, nachdem das Massenladen der Daten beendet ist, reduzieren.
**Anmerkung**
Standardmäßig schützt DynamoDB Sie vor unbeabsichtigter, unkontrollierter Nutzung. Um die Durchsatzgrenzen von 40 000 Lese- und Schreibvorgängen auf Tabellenebene für alle Tabellen in Ihrem Konto zu überschreiten, können Sie eine Erhöhung dieses Kontingents anfordern. Durchsatzanforderungen, die das standardmäßige Durchsatzkontingent der Tabelle überschreiten, werden gedrosselt. Weitere Informationen finden Sie unter [Standardkontingente für den Durchsatz](ServiceQuotas.md#default-limits-throughput).
Sie können Tabellen innerhalb eines fortlaufenden 24-stündigen Zeitfensters bis zu viermal vom Modus mit bereitgestellter Kapazität auf den On-Demand-Modus umstellen. Sie können Tabellen jederzeit vom On-Demand-Modus auf den Modus mit bereitgestellter Kapazität umstellen.
Weitere Informationen zum Wechseln zwischen Lese- und Schreibkapazitätsmodus finden Sie unter [Überlegungen beim Umstellen der Kapazitätsmodi in DynamoDB](bp-switching-capacity-modes.md).
**Topics**
+ [Lesekapazitätseinheiten und Schreibkapazitätseinheiten](#read-write-capacity-units)
+ [Auswählen der ersten Durchsatzeinstellungen](#choosing-initial-throughput)
+ [DynamoDB Auto Scaling](#ddb-autoscaling)
+ [Automatische Verwaltung der Durchsatzkapazität mit DynamoDB-Auto-Scaling](AutoScaling.md)
+ [DynamoDB – reservierte Kapazität](reserved-capacity.md)
## Lesekapazitätseinheiten und Schreibkapazitätseinheiten
Für Tabellen im bereitgestellten Modus geben Sie die Durchsatzanforderungen in Form von *Kapazitätseinheiten* an. Diese Einheiten stellen die Datenmenge dar, die Ihre Anwendung zum Lesen oder Schreiben pro Sekunde benötigt. Sie können diese Einstellungen später bei Bedarf ändern oder DynamoDB-Auto-Scaling aktivieren, um sie automatisch zu ändern.
Für ein Elemente mit einer Größe von bis zu 4 KB entspricht eine *Leseanforderungseinheit* (RCU) einem strikt konsistenten Lesevorgang pro Sekunde oder zwei letztendlich konsistenten Lesevorgängen pro Sekunde. Weitere Informationen über die DynamoDB-Lesekonsistenzmodelle finden Sie unter [DynamoDB-Lesekonsistenz](HowItWorks.ReadConsistency.md).
Eine *Schreibkapazitätseinheit* (WCU) stellt einen Schreibvorgang pro Sekunde für ein Element mit einer Größe von bis zu 1 KB dar. Weitere Informationen über die verschiedenen Lese- und Schreibvorgänge finden Sie unter [Lese- und Schreibvorgänge in DynamoDB](read-write-operations.md).
## Auswählen der ersten Durchsatzeinstellungen
Für jede Anwendung gelten unterschiedliche Anforderungen für Lese- und Schreibvorgänge in einer Datenbank. Wenn Sie die ersten Durchsatzeinstellungen für eine DynamoDB-Tabelle festlegen, berücksichtigen Sie Folgendes:
+ **Erwartete Lese- und Schreibanforderungsraten** – Sie müssen die Anzahl der Lese- und Schreibvorgänge schätzen, die Sie pro Sekunde ausführen müssen.
+ **Größe der Elemente** – Einige Elemente sind so klein, dass sie mit einer einzigen Kapazitätseinheit gelesen oder geschrieben werden können. Größere Elemente erfordern mehrere Kapazitätseinheiten. Durch die Schätzung der durchschnittlichen Größe der Elemente in der Tabelle können Sie genaue Einstellungen für den bereitgestellten Durchsatz der Tabelle angeben.
+ **Anforderungen an die Lesekonsistenz** – Lesekapazitätseinheiten basieren auf strikt konsistenten Lesevorgängen, die doppelt so viele Datenbankressourcen verbrauchen wie letztendlich konsistente Lesevorgänge. Sie müssen selbst entscheiden, ob Ihre Anwendung Strongly Consistent-Lesevorgänge erfordert oder ob sie diese Anforderung lockern kann und stattdessen Eventually Consistent-Lesevorgänge verwendet. Lesevorgänge in DynamoDB sind standardmäßig letztendlich konsistent. Sofern erforderlich, können Sie strikt konsistente Lesevorgänge für diese Operationen anfordern.
Angenommen, Sie möchten 80 Elemente pro Sekunde aus einer Tabelle lesen. Die Elemente haben eine Größe von 3 KB und Sie benötigen strikt konsistente Lesevorgänge. In diesem Szenario ist für jeden Lesevorgang eine bereitgestellte Lesekapazitätseinheit erforderlich. Um die entsprechende Zahl zu bestimmen, teilen Sie die Elementgröße der Operation durch 4 KB. Runden Sie dann auf die nächste ganze Zahl auf, wie im folgenden Beispiel dargestellt:
+ 3 KB / 4 KB = 0,75 oder **1** Lesekapazitätseinheit
Um also 80 Elemente pro Sekunde aus einer Tabelle zu lesen, legen Sie den bereitgestellten Lesedurchsatz der Tabelle auf 80 Lesekapazitätseinheiten fest, wie im folgenden Beispiel gezeigt:
+ 1 Lesekapazitätseinheit pro Element × 80 Lesevorgänge pro Sekunde = **80** Lesekapazitätseinheiten
Nehmen wir jetzt an, Sie möchten 100 Elemente pro Sekunde in Ihre Tabelle schreiben und die Elemente haben jeweils eine Größe von 512 Byte. In diesem Fall ist für jeden Schreibvorgang eine bereitgestellte Schreibkapazitätseinheit erforderlich. Um die entsprechende Zahl zu bestimmen, teilen Sie die Elementgröße der Operation durch 1 KB. Runden Sie dann auf die nächste ganze Zahl auf, wie im folgenden Beispiel dargestellt:
+ 512 Byte / 1 KB = 0,5 oder **1** Schreibkapazitätseinheit
Um 100 Elemente pro Sekunde in Ihre Tabelle zu schreiben, legen Sie den bereitgestellten Schreibdurchsatz der Tabelle auf 100 Schreibkapazitätseinheiten fest:
+ 1 Schreibkapazitätseinheit pro Element × 100 Schreibvorgänge pro Sekunde = **100** Schreibkapazitätseinheiten
## DynamoDB Auto Scaling
DynamoDB Auto Scaling verwaltet die bereitgestellte Durchsatzkapazität für Tabellen und globale sekundäre Indizes. Mit Auto Scaling definieren Sie einen Bereich (Unter- und Obergrenze) für Lese- und Schreibkapazitätseinheiten. Außerdem legen Sie einen Zielauslastungsprozentsatz in diesem Bereich fest. DynamoDB-Auto-Scaling versucht, Ihre Zielauslastung aufrechtzuerhalten, auch wenn der Workload Ihrer Anwendung steigt oder sinkt.
Mit Auto Scaling von DynamoDB kann eine Tabelle oder ein globaler sekundärer Index ihre bereitgestellte Lese- und Schreibkapazität erhöhen, um plötzliche Erhöhungen des Datenverkehrs ohne Anforderungsdrosselung zu bewältigen. Wenn die Workload abnimmt, kann Auto Scaling von DynamoDB den Durchsatz verringern, sodass Sie nicht für ungenutzte bereitgestellte Kapazität bezahlen.
**Anmerkung**
Wenn Sie den verwenden AWS-Managementkonsole , um eine Tabelle oder einen globalen sekundären Index zu erstellen, ist DynamoDB Auto Scaling standardmäßig aktiviert.
Sie können die Auto Scaling-Einstellungen jederzeit mithilfe der Konsole AWS CLI, der oder einer der verwalten AWS SDKs. Weitere Informationen finden Sie unter [Automatische Verwaltung der Durchsatzkapazität mit DynamoDB-Auto-Scaling](AutoScaling.md).
### Nutzungsrate
Mithilfe der Nutzungsrate können Sie feststellen, ob Sie die zu viel Kapazität bereitstellen. In diesem Fall sollten Sie die Kapazität Ihrer Tabelle reduzieren, um Kosten zu sparen. Umgekehrt kann sie mit der Nutzungsrate auch feststellen, ob Sie zu wenig Kapazität bereitstellen. In diesem Fall sollten Sie die Tabellenkapazität erhöhen, um eine mögliche Drosselung von Anforderung bei Instances mit unerwartet hohem Datenverkehr zu verhindern. Weitere Informationen finden Sie unter [Amazon DynamoDB auto scaling: Performance and cost optimization at any scale](https://aws.amazon.com/blogs/database/amazon-dynamodb-auto-scaling-performance-and-cost-optimization-at-any-scale/).
Wenn Sie DynamoDB Auto Scaling verwenden, müssen Sie auch einen Zielauslastungsprozentsatz festlegen. Auto Scaling verwendet diesen Prozentsatz als Ziel, um die Kapazität nach oben oder unten anzupassen. Wir empfehlen, die Zielauslastung auf 70 % festzulegen. Weitere Informationen finden Sie unter [Automatische Verwaltung der Durchsatzkapazität mit DynamoDB-Auto-Scaling](AutoScaling.md).
# Automatische Verwaltung der Durchsatzkapazität mit DynamoDB-Auto-Scaling
Viele Datenbank-Workloads sind zyklischer Natur, während andere sich nur schwer vorhersagen lassen. Nehmen wir als Beispiel eine Social-Networking-App, bei der die meisten Benutzer tagsüber aktiv sind. Die Datenbank muss in der Lage sein, die Aktivitäten am Tag zu verarbeiten, während in der Nacht nicht so viel Durchsatz erforderlich ist. Ein weiteres Beispiel wäre eine neue Mobile-Gaming-App, die sich unerwartet schnell großer Beliebtheit erfreut. Wenn das Spiel jedoch zu beliebt wird, kann dies dazu führen, dass die verfügbaren Datenbankressourcen überschritten werden und sich dies negativ auf die Leistung und Kundenzufriedenheit auswirkt. Diese Arten von Workloads erfordern häufig manuelle Eingriffe, um die Datenbankressourcen nach oben oder unten zu skalieren, um sie an die jeweiligen Nutzungsschwankungen anzupassen.
Amazon DynamoDB Auto Scaling verwendet den AWS Application Auto Scaling-Service, um die bereitgestellte Durchsatzkapazität in Ihrem Namen dynamisch an die tatsächlichen Verkehrsmuster anzupassen. Auf diese Weise kann eine Tabelle oder ein globaler sekundärer Index (GSI) die bereitgestellte Lese- und Schreibkapazität erhöhen, um einen plötzlichen Anstieg des Datenverkehrs ohne Drosselung zu bewältigen. Wenn der Workload abnimmt, senkt Application Auto Scaling Auto Scaling den Durchsatz, sodass Sie für ungenutzte Kapazität nicht zahlen müssen.
**Anmerkung**
Wenn Sie den verwenden AWS-Managementkonsole , um eine Tabelle oder einen globalen sekundären Index zu erstellen, ist DynamoDB Auto Scaling standardmäßig aktiviert. Sie können Ihre Auto Scaling-Einstellungen jederzeit ändern. Weitere Informationen finden Sie unter [Verwenden der auto AWS-Managementkonsole Skalierung mit DynamoDB](AutoScaling.Console.md).
Wenn Sie eine Tabelle oder ein globales Tabellenreplikat löschen, werden alle zugehörigen skalierbaren Ziele, Skalierungsrichtlinien oder CloudWatch Alarme nicht automatisch mit gelöscht.
Mit Application Auto Scaling erstellen Sie eine *Skalierungsrichtlinie* für eine Tabelle oder einen globalen sekundären Index. Die Skalierungsrichtlinie gibt an, ob die Lese- oder Schreibkapazität (oder beides) sowie die Einstellungen für die minimalen und maximalen bereitgestellten Kapazitätseinheiten für die Tabelle oder den Index skaliert werden sollen.
Die Skalierungsrichtlinie enthält außerdem eine *Zielauslastung*, d. h. den zu einem bestimmten Zeitpunkt verbrauchten bereitgestellten Durchsatz in Prozent. Application Auto Scaling verwendet einen *Zielverfolgungsalgorithmus*, um den bereitgestellten Durchsatz der Tabelle (oder des Indexes) als Reaktion auf die tatsächlichen Workloads nach oben oder unten anzupassen, sodass die tatsächliche Kapazitätsauslastung bei oder in der Nähe Ihrer Zielauslastung bleibt.
DynamoDB-Ausgaben verbrauchten den bereitgestellten Durchsatz für Zeiträume von einer Minute. Auto Scaling wird ausgelöst, wenn Ihre verbrauchte Kapazität für zwei aufeinanderfolgende Minuten die konfigurierte Zielauslastung überschreitet. CloudWatch Alarme können eine kurze Verzögerung von bis zu einigen Minuten haben, bevor sie die auto Skalierung auslösen. Diese Verzögerung gewährleistet eine genaue CloudWatch metrische Auswertung. Wenn die Spitzen des verbrauchten Durchsatzes in Abständen von mehr als einer Minute auftreten, wird Auto Scaling möglicherweise nicht ausgelöst. In ähnlicher Weise kann es zu einer Herunterskalierung kommen, wenn 15 aufeinanderfolgende Datenpunkte unter der Zielauslastung liegen. In beiden Fällen wird die [UpdateTable](https://docs.aws.amazon.com/amazondynamodb/latest/APIReference/API_UpdateTable.html)API aufgerufen, nachdem Auto Scaling ausgelöst wurde. Die Aktualisierung der bereitgestellten Kapazität für die Tabelle oder den Index kann dann einige Minuten dauern. Während dieses Zeitraums werden alle Anforderungen gedrosselt, die die zuvor bereitgestellte Kapazität der Tabellen überschreiten.
**Wichtig**
Sie können die Anzahl der Datenpunkte, die verletzt werden müssen, um den zugrunde liegenden Alarm auszulösen, nicht anpassen (obwohl sich die aktuelle Anzahl künftig ändern könnte).
Sie können die Zielauslastungswerte von Auto Scaling auf 20 bis 90 % für Ihre Lese- und Schreibkapazität festlegen.
**Anmerkung**
Zusätzlich zu den Tabellen unterstützt DynamoDB-Auto-Scaling auch globale sekundäre Indizes. Jeder globale sekundäre Index verfügt über eine eigene bereitgestellte Durchsatzkapazität, unabhängig von der seiner Basistabelle. Wenn Sie eine Skalierungsrichtlinie für einen globalen sekundären Index erstellen, passt Application Auto Scaling die Einstellungen für den bereitgestellten Durchsatz für den Index an, um sicherzustellen, dass die tatsächliche Auslastung auf oder in der Nähe des gewünschten Auslastungsverhältnisses bleibt.
## Funktionsweise von DynamoDB-Auto-Scaling
**Anmerkung**
Informationen für einen schnellen Einstieg in DynamoDB-Auto-Scaling finden Sie unter [Verwenden der auto AWS-Managementkonsole Skalierung mit DynamoDB](AutoScaling.Console.md).
Die folgende Abbildung bietet einen allgemeinen Überblick darüber, wie DynamoDB-Auto-Scaling die Durchsatzkapazität für eine Tabelle verwaltet:
![\[DynamoDB Auto Scaling passt die Durchsatzkapazität einer Tabelle an die Nachfrage an.\]](http://docs.aws.amazon.com/de_de/amazondynamodb/latest/developerguide/images/auto-scaling.png)
Die folgenden Schritte fassen den Prozess der automatischen Skalierung zusammen, wie in der vorherigen Abbildung gezeigt:
1. Sie erstellen eine Application-Auto-Scaling-Richtlinie für die DynamoDB-Tabelle.
1. DynamoDB veröffentlicht Kennzahlen zur verbrauchten Kapazität auf Amazon. CloudWatch
1. Wenn die verbrauchte Kapazität der Tabelle Ihre Zielauslastung für einen bestimmten Zeitraum überschreitet (oder unter das Ziel fällt), CloudWatch löst Amazon einen Alarm aus. Sie können den Alarm in der Konsole anzeigen und Benachrichtigungen über Amazon Simple Notification Service (Amazon SNS) erhalten.
1. Der CloudWatch Alarm ruft Application Auto Scaling auf, um Ihre Skalierungsrichtlinie auszuwerten.
1. Application Auto Scaling gibt eine `UpdateTable`-Anforderung aus, um den bereitgestellten Durchsatz der Tabelle anzupassen.
1. DynamoDB verarbeitet die `UpdateTable`-Anforderung und erhöht (bzw. senkt) die bereitgestellte Durchsatzkapazität der Tabelle dynamisch, sodass sie sich der Zielauslastung nähert.
Wir wollen die Funktionsweise von DynamoDB-Auto-Scaling anhand einer Beispieltabelle namens `ProductCatalog` erläutern. In die Tabelle werden selten Daten massenweise geladen, es erfolgt also nicht sehr viel Schreibaktivität. Es gibt jedoch ein hohes Maß an Leseaktivität, die im Laufe der Zeit variiert. Durch die Überwachung der CloudWatch Amazon-Metriken für stellen Sie fest`ProductCatalog`, dass die Tabelle 1.200 Lesekapazitätseinheiten benötigt (um zu verhindern, dass DynamoDB Leseanforderungen drosselt, wenn die Aktivität ihren Höhepunkt erreicht). Sie stellen außerdem fest, dass `ProductCatalog` mindestens 150 Lesekapazitätseinheiten erfordert, wenn der Leseverkehr am niedrigsten ist. Weitere Informationen zur Vermeidung einer Drosselung finden Sie unter [Beheben von Drosselungsereignissen in Amazon DynamoDB](TroubleshootingThrottling.md).
Angesichts der Spanne von 150 bis 1.200 Lesekapazitätseinheiten entscheiden Sie, dass eine Zielauslastung von 70 Prozent für die Tabelle `ProductCatalog` angemessen wäre. Die *Zielauslastung* ist das Verhältnis der verbrauchten Kapazitätseinheiten zu den bereitgestellten Kapazitätseinheiten in Prozent. Application Auto Scaling verwendet einen eigenen Ziel-Tracking-Algorithmus, um sicherzustellen, dass die bereitgestellte Lesekapazität von `ProductCatalog` wie erforderlich angepasst wird, damit die Auslastung nahezu 70 Prozent beträgt.
**Anmerkung**
DynamoDB Auto Scaling ändert die Einstellungen für den bereitgestellten Durchsatz nur, wenn die tatsächliche Workload über einen anhaltenden Zeitraum von mehreren Minuten erhöht oder niedrig bleibt. Der Ziel-Tracking-Algorithmus von Application Auto Scaling versucht, dafür zu sorgen, dass die Zielauslastung langfristig Ihrem gewählten Wert nahezu entspricht.
Plötzliche Aktivitätsspitzen werden von der integrierten Burst-Kapazität der Tabelle bewältigt. Weitere Informationen finden Sie unter [Burst-Kapazität](burst-adaptive-capacity.md#burst-capacity).
Um DynamoDB-Auto-Scaling für die Tabelle `ProductCatalog` zu aktivieren, erstellen Sie eine Skalierungsrichtlinie. Diese Richtlinie legt Folgendes fest:
+ Die Tabelle oder der globale sekundäre Index, die Sie verwalten möchten
+ Den Kapazitätstyp, der verwaltet werden soll (Lese- oder Schreibkapazität)
+ Die Ober- und Untergrenze für die bereitgestellten Durchsatzeinstellungen
+ Ihre Zielauslastung
Wenn Sie eine Skalierungsrichtlinie erstellen, erstellt Application Auto Scaling in Ihrem Namen zwei CloudWatch Amazon-Alarme. Jedes Paar stellt die Ober- und Untergrenze für Ihren bereitgestellten Durchsatz dar. Diese CloudWatch Alarme werden ausgelöst, wenn die tatsächliche Auslastung der Tabelle über einen längeren Zeitraum von Ihrer Zielauslastung abweicht.
Wenn einer der CloudWatch Alarme ausgelöst wird, sendet Ihnen Amazon SNS eine Benachrichtigung (sofern Sie ihn aktiviert haben). Der CloudWatch Alarm ruft dann Application Auto Scaling auf, das wiederum DynamoDB auffordert, die bereitgestellte Kapazität der `ProductCatalog` Tabelle nach Bedarf nach oben oder unten anzupassen.
Während eines Skalierungsereignisses AWS Config wird pro aufgezeichnetem Konfigurationselement abgerechnet. Wenn ein Skalierungsereignis auftritt, werden für jedes auto-scaling Skalierungsereignis beim Lesen und Schreiben vier CloudWatch ProvisionedCapacity Alarme erstellt: ProvisionedCapacityLow alarms: ProvisionedCapacityHigh und ConsumedCapacity alarms: AlarmHigh, AlarmLow. Das bedeutet insgesamt acht Alarme. AWS Config Zeichnet daher acht Konfigurationselemente für jedes Skalierungsereignis auf.
**Anmerkung**
Sie können die DynamoDB-Skalierung auch so planen, dass sie zu bestimmten Zeiten erfolgt. Erfahren Sie [hier](https://docs.aws.amazon.com/autoscaling/application/userguide/get-started-exercise.html) mehr über die grundlegenden Schritte.
## Nutzungshinweise
Bevor Sie DynamoDB-Auto-Scaling verwenden, beachten Sie Folgendes:
+ Bei DynamoDB-Auto-Scaling kann die Lese- bzw. Schreibkapazität in Übereinstimmung mit Ihrer Auto-Scaling-Richtlinie so oft wie nötig erhöht werden. Alle DynamoDB-Kontingente bleiben in Kraft, wie unter [Kontingente in Amazon DynamoDB](ServiceQuotas.md) beschrieben.
+ DynamoDB-Auto-Scaling hindert Sie nicht daran, die Einstellungen für den bereitgestellten Durchsatz manuell zu ändern. Diese manuellen Anpassungen wirken sich nicht auf bestehende CloudWatch Alarme aus, die sich auf DynamoDB Auto Scaling beziehen.
+ Wenn Sie die automatische DynamoDB-Skalierung für eine Tabelle aktivieren, die über einen oder mehrere globale sekundäre Indizes verfügt, wird dringend empfohlen, die automatische Skalierung auch einheitlich auf diese Indexe anzuwenden. Dies trägt dazu bei, eine bessere Leistung beim Schreiben und Lesen von Tabellen zu gewährleisten und eine Drosselung zu vermeiden. Sie können Auto Scaling aktivieren, indem Sie **Apply same settings to global secondary indexes** (Die gleichen Einstellungen für globale sekundäre Indizes anwenden) in der AWS-Managementkonsole auswählen. Weitere Informationen finden Sie unter [Aktivieren von DynamoDB-Auto-Scaling in bestehenden Tabellen](AutoScaling.Console.md#AutoScaling.Console.ExistingTable).
+ Wenn Sie eine Tabelle oder ein globales Tabellenreplikat löschen, werden alle zugehörigen skalierbaren Ziele, Skalierungsrichtlinien oder CloudWatch Alarme nicht automatisch mit gelöscht.
+ Beim Erstellen einer GSI für eine vorhandene Tabelle ist Auto Scaling für die GSI nicht aktiviert. Sie müssen die Kapazität während der Erstellung der GSI manuell verwalten. Sobald der Backfill auf der GSI abgeschlossen ist und sie den aktiven Status erreicht, funktioniert Auto Scaling wie gewohnt.
# Verwenden der auto AWS-Managementkonsole Skalierung mit DynamoDB
Wenn Sie das verwenden, AWS-Managementkonsole um eine neue Tabelle zu erstellen, ist Amazon DynamoDB Auto Scaling für diese Tabelle standardmäßig aktiviert. Sie können die Konsole auch verwenden, um Auto Scaling für vorhandene Tabellen zu aktivieren, Auto Scaling-Einstellungen zu ändern oder Auto Scaling zu deaktivieren.
**Anmerkung**
Für erweiterte Funktionen wie das Einstellen der Abklingzeiten für Scale-In und Scale-Out verwenden Sie die AWS Command Line Interface (AWS CLI), um die auto Skalierung von DynamoDB zu verwalten. Weitere Informationen finden Sie unter [Verwenden der auto AWS CLI Skalierung von DynamoDB zur Verwaltung](AutoScaling.CLI.md).
**Topics**
+ [Bevor Sie beginnen: Erteilen von Benutzerberechtigungen für DynamoDB-Auto-Scaling](#AutoScaling.Permissions)
+ [Erstellen einer neuen Tabelle mit aktiviertem Auto Scaling](#AutoScaling.Console.NewTable)
+ [Aktivieren von DynamoDB-Auto-Scaling in bestehenden Tabellen](#AutoScaling.Console.ExistingTable)
+ [Anzeigen von Auto-Scaling-Aktivitäten in der Konsole](#AutoScaling.Console.ViewingActivities)
+ [Ändern oder Deaktivieren der DynamoDB-Auto-Scaling-Einstellungen](#AutoScaling.Console.Modifying)
## Bevor Sie beginnen: Erteilen von Benutzerberechtigungen für DynamoDB-Auto-Scaling
In AWS Identity and Access Management (IAM) `DynamoDBFullAccess` stellt die AWS verwaltete Richtlinie die erforderlichen Berechtigungen für die Verwendung der DynamoDB-Konsole bereit. Jedoch benötigen Benutzer für DynamoDB Auto Scaling einige zusätzliche Berechtigungen.
**Wichtig**
Zum Löschen einer Tabelle mit Auto Scaling sind `application-autoscaling:*`-Berechtigungen erforderlich. Die AWS verwaltete Richtlinie `DynamoDBFullAccess` umfasst solche Berechtigungen.
Um einen Benutzer für DynamoDB-Konsolenzugriff und DynamoDB Auto Scaling einzurichten, erstellen Sie eine Rolle und fügen Sie die **AmazonDynamoDBFullAccess-Richtlinie** zu dieser Rolle hinzu. Weisen Sie die Rolle dann einem Benutzer zu.
## Erstellen einer neuen Tabelle mit aktiviertem Auto Scaling
**Anmerkung**
DynamoDB Auto Scaling erfordert das Vorhandensein einer serviceverknüpften Rolle (`AWSServiceRoleForApplicationAutoScaling_DynamoDBTable`), die in Ihrem Namen Auto-Scaling-Aktionen durchführt. Diese Rolle wird automatisch für Sie erstellt. Weitere Informationen finden Sie unter [Serviceverknüpfte Rollen für Application Auto Scaling](https://docs.aws.amazon.com/autoscaling/application/userguide/application-auto-scaling-service-linked-roles.html) im *Benutzerhandbuch zu Application Auto Scaling*.
**So erstellen Sie eine neue Tabelle mit aktiviertem Auto Scaling**
1. Öffnen Sie die DynamoDB-Konsole unter. [https://console.aws.amazon.com/dynamodb/](https://console.aws.amazon.com/dynamodb/)
1. Wählen Sie **Create table** (Tabelle erstellen) aus.
1. Geben Sie auf der Seite **Tabelle erstellen** einen **Tabellennamen** und Details zum Primärschlüssel ein.
1. Wenn Sie **Standardeinstellungen** auswählen, wird Auto Scaling in der neuen Tabelle aktiviert.
Wählen Sie andernfalls **Einstellungen anpassen** aus und gehen Sie wie folgt vor, um benutzerdefinierte Einstellungen für die Tabelle anzugeben:
1. Behalten Sie für **Tabellenklasse** die Standardauswahl **DynamoDB Standard** bei.
1. Behalten Sie für **Lese-/Schreibkapazitätseinstellungen** die Standardauswahl **Bereitgestellt** bei und gehen Sie dann wie folgt vor:
1. Stellen Sie sicher, dass unter **Lesekapazität** die Option **Auto Scaling** auf **An** festgelegt ist.
1. Stellen Sie sicher, dass unter **Schreibkapazität** die Option **Auto Scaling** auf **An** festgelegt ist.
1. Legen Sie unter **Lesekapazität** und **Schreibkapazität** die gewünschte Skalierungsrichtlinie für die Tabelle und optional alle globalen sekundären Indizes der Tabelle fest.
+ **Minimale Kapazitätseinheiten** – Geben Sie den unteren Grenzwert für den Auto-Scaling-Bereich ein.
+ **Maximale Kapazitätseinheiten** – Geben Sie den oberen Grenzwert für den Auto-Scaling-Bereich ein.
+ **Zielauslastung** – Geben Sie den Zielauslastungsprozentsatz für die Tabelle ein.
**Anmerkung**
Wenn Sie einen globalen Sekundärindex für die neue Tabelle erstellen, entspricht die Kapazität des Index zum Zeitpunkt der Erstellung der Kapazität Ihrer Basistabelle. Sie können die Kapazität des Index in den Einstellungen der Tabelle ändern, nachdem Sie die Tabelle erstellt haben.
1. Wählen Sie **Create table** (Tabelle erstellen) aus. Die Tabelle wird mit den von Ihnen angegebenen Auto-Scaling-Parametern erstellt.
## Aktivieren von DynamoDB-Auto-Scaling in bestehenden Tabellen
**Anmerkung**
DynamoDB Auto Scaling erfordert das Vorhandensein einer serviceverknüpften Rolle (`AWSServiceRoleForApplicationAutoScaling_DynamoDBTable`), die in Ihrem Namen Auto-Scaling-Aktionen durchführt. Diese Rolle wird automatisch für Sie erstellt. Weitere Informationen finden Sie unter [Serviceverknüpfte Rollen für Application Auto Scaling](https://docs.aws.amazon.com/autoscaling/application/userguide/application-auto-scaling-service-linked-roles.html).
**So aktivieren Sie DynamoDB-Auto-Scaling für eine vorhandene Tabelle**
1. Öffnen Sie die DynamoDB-Konsole unter. [https://console.aws.amazon.com/dynamodb/](https://console.aws.amazon.com/dynamodb/)
1. Klicken Sie im Navigationsbereich auf der linken Seite der Konsole auf **Tabellen**.
1. Wählen Sie die Tabelle aus, für die Sie Auto Scaling aktivieren möchten, und gehen Sie dann wie folgt vor:
1. Wählen Sie die Registerkarte **Zusätzliche Einstellungen** aus.
1. Wählen Sie im Abschnitt **Lese-/Schreibkapazität** die Option **Bearbeiten** aus.
1. Wählen Sie im Abschnitt **Kapazitätsmodus** die Option **Bereitgestellt** aus.
1. Setzen Sie im Abschnitt **Kapazität der Tabelle** **Auto Scaling** auf **Ein** für **Lesekapazität**, **Schreibkapazität** oder beides. Legen Sie für jeden dieser Punkte die gewünschte Skalierungsrichtlinie für die Tabelle und optional alle globalen sekundären Indizes der Tabelle fest.
+ **Minimale Kapazitätseinheiten** – Geben Sie den unteren Grenzwert für den Auto-Scaling-Bereich ein.
+ **Maximale Kapazitätseinheiten** – Geben Sie den oberen Grenzwert für den Auto-Scaling-Bereich ein.
+ **Zielauslastung** – Geben Sie den Zielauslastungsprozentsatz für die Tabelle ein.
+ **Dieselben read/write Kapazitätseinstellungen für alle globalen sekundären Indizes verwenden** — Wählen Sie aus, ob globale sekundäre Indizes dieselbe Auto Scaling-Richtlinie wie die Basistabelle verwenden sollen.
**Anmerkung**
Um eine optimale Leistung zu erzielen, empfehlen wir, die Option **Dieselben read/write Kapazitätseinstellungen für alle globalen sekundären Indizes verwenden** zu aktivieren. Mit dieser Option kann die automatische DynamoDB-Skalierung alle globalen sekundären Indexe in der Basistabelle einheitlich skalieren. Dazu gehören vorhandene globale sekundäre Indizes und alle anderen, die Sie in Zukunft für diese Tabelle erstellen.
Wenn diese Option aktiviert ist, können Sie keine Skalierungsrichtlinie für einen einzelnen globale sekundäre Index festlegen.
1. Wenn Sie die gewünschten Einstellungen vorgenommen haben, wählen Sie **Save** (Speichern) aus.
## Anzeigen von Auto-Scaling-Aktivitäten in der Konsole
Wenn Ihre Anwendung Lese- und Schreibverkehr in die Tabellen führt, modifiziert DynamoDB-Auto-Scaling die Durchsatzeinstellungen der Tabelle dynamisch. Amazon CloudWatch verfolgt die bereitgestellte und verbrauchte Kapazität, gedrosselte Ereignisse, Latenz und andere Kennzahlen für all Ihre DynamoDB-Tabellen und sekundären Indizes.
Wenn Sie diese Metriken in der DynamoDB-Konsole anzeigen möchten, wählen Sie die Tabelle aus, mit der Sie arbeiten möchten, und öffnen Sie die Registerkarte **Überwachen**. **Um eine anpassbare Ansicht der Tabellenmetriken zu erstellen, wählen Sie Alle anzeigen in. CloudWatch**
## Ändern oder Deaktivieren der DynamoDB-Auto-Scaling-Einstellungen
Sie können den verwenden AWS-Managementkonsole , um Ihre DynamoDB-Auto-Scaling-Einstellungen zu ändern. Gehen Sie dazu zur Registerkarte **Zusätzliche Einstellungen** für Ihre Tabelle und wählen Sie **Bearbeiten** im Abschnitt **Lese-/Schreibkapazität** aus. Weitere Informationen zu diesen Einstellungen finden Sie unter [Aktivieren von DynamoDB-Auto-Scaling in bestehenden Tabellen](#AutoScaling.Console.ExistingTable).
# Verwenden der auto AWS CLI Skalierung von DynamoDB zur Verwaltung
Anstatt das zu verwenden AWS-Managementkonsole, können Sie das AWS Command Line Interface (AWS CLI) verwenden, um die auto Skalierung von Amazon DynamoDB zu verwalten. Das Tutorial in diesem Abschnitt erläutert, wie der AWS CLI installiert und konfiguriert wird, um DynamoDB-Auto-Scaling zu verwalten. In diesem Tutorial führen Sie folgende Aufgaben aus:
+ Erstellen einer DynamoDB-Tabelle mit dem Namen `TestTable`. Die Ersteinstellungen des Durchsatzes sind 5 Lesekapazitätseinheiten und 5 Schreibkapazitätseinheiten.
+ Erstellen Sie die Application-Auto-Scaling-Richtlinie für `TestTable`. Die Richtlinie versucht ein 50 %-Zielverhältnis zwischen verbrauchter und bereitgestellter Schreibkapazität beizubehalten. Der Bereich für diese Metrik liegt zwischen 5 und 10 Schreibkapazitätseinheiten. (Application Auto Scaling darf den Durchsatz außerhalb dieses Bereichs nicht anpassen.)
+ Ausführen eines Python-Programms, um den Datenverkehr zu `TestTable` zu leiten. Wenn das Zielverhältnis 50 Prozent über einen anhaltenden Zeitraum überschreitet, benachrichtigt Application Auto Scaling DynamoDB, um den Durchsatz von `TestTable` nach oben anzupassen, sodass die 50 % Zielauslastung aufrechterhalten werden kann.
+ Überprüfen, ob DynamoDB die bereitgestellte Schreibkapazität für `TestTable` erfolgreich angepasst hat.
**Anmerkung**
Sie können die DynamoDB-Skalierung auch so planen, dass sie zu bestimmten Zeiten erfolgt. Erfahren Sie [hier](https://docs.aws.amazon.com/autoscaling/application/userguide/get-started-exercise.html) mehr über die grundlegenden Schritte.
**Topics**
+ [Bevor Sie beginnen](#AutoScaling.CLI.BeforeYouBegin)
+ [Schritt 1: Erstellen einer DynamoDB-Tabelle](#AutoScaling.CLI.CreateTable)
+ [Schritt 2: Registrieren eines skalierbaren Ziels](#AutoScaling.CLI.RegisterScalableTarget)
+ [Schritt 3: Erstellen einer Skalierungsrichtlinie](#AutoScaling.CLI.CreateScalingPolicy)
+ [Schritt 4: Leiten Sie den Schreibverkehr weiter zu TestTable](#AutoScaling.CLI.DriveTraffic)
+ [Schritt 5: Anzeigen der Application Auto Scaling](#AutoScaling.CLI.ViewCWAlarms)
+ [(Optional) Schritt 6: Bereinigen](#AutoScaling.CLI.CleanUp)
## Bevor Sie beginnen
Führen Sie folgende Schritte durch, bevor Sie das Tutorial starten.
### Installieren Sie das AWS CLI
Wenn Sie es noch nicht getan haben, müssen Sie AWS CLI installieren und konfigurieren. Befolgen Sie hierzu die Anweisungen im *AWS Command Line Interface Benutzerhandbuch*:
+ [Installieren des AWS CLI](https://docs.aws.amazon.com/cli/latest/userguide/installing.html)
+ [Konfigurieren von AWS CLI](https://docs.aws.amazon.com/cli/latest/userguide/cli-chap-getting-started.html)
### Installieren von Python
Ein Teil dieses Tutorials erfordert von Ihnen das Ausführen eines Python-Programms (siehe [Schritt 4: Leiten Sie den Schreibverkehr weiter zu TestTable](#AutoScaling.CLI.DriveTraffic)). Wenn Sie das noch nicht installiert haben, können Sie [Python herunterladen](https://www.python.org/downloads).
## Schritt 1: Erstellen einer DynamoDB-Tabelle
In diesem Schritt verwenden Sie die AWS CLI zum Erstellen`TestTable`. Der Primärschlüssel besteht aus `pk` (Partitionsschlüssel) und `sk` (Sortierschlüssel). Beide Attribute sind vom Typ `Number`. Die Ersteinstellungen des Durchsatzes sind 5 Lesekapazitätseinheiten und 5 Schreibkapazitätseinheiten.
1. Verwenden Sie den folgenden AWS CLI Befehl, um die Tabelle zu erstellen.
```
aws dynamodb create-table \
--table-name TestTable \
--attribute-definitions \
AttributeName=pk,AttributeType=N \
AttributeName=sk,AttributeType=N \
--key-schema \
AttributeName=pk,KeyType=HASH \
AttributeName=sk,KeyType=RANGE \
--provisioned-throughput ReadCapacityUnits=5,WriteCapacityUnits=5
```
1. Verwenden Sie den folgenden Befehl, um den Status der Tabelle zu überprüfen.
```
aws dynamodb describe-table \
--table-name TestTable \
--query "Table.[TableName,TableStatus,ProvisionedThroughput]"
```
Die Tabelle ist betriebsbereit, wenn ihr Status `ACTIVE` ist.
## Schritt 2: Registrieren eines skalierbaren Ziels
Jetzt registrieren Sie die Schreibkapazität der Tabelle als ein skalierbares Ziel mit Application Auto Scaling. Auf diese Weise kann Application Auto Scaling die bereitgestellte Schreibkapazität für *TestTable*, jedoch nur im Bereich von 5—10 Kapazitätseinheiten, anpassen.
**Anmerkung**
DynamoDB-Auto-Scaling erfordert das Vorhandensein einer Rolle (`AWSServiceRoleForApplicationAutoScaling_DynamoDBTable`), die in Ihrem Namen Auto-Scaling-Aktionen durchführt. Diese Rolle wird automatisch für Sie erstellt. Weitere Informationen finden Sie unter [Serviceverknüpfte Rollen für Application Auto Scaling](https://docs.aws.amazon.com/autoscaling/application/userguide/application-auto-scaling-service-linked-roles.html) im *Benutzerhandbuch zu Application Auto Scaling*.
1. Geben Sie den folgenden Befehl ein, um das skalierbare Ziel zu registrieren.
```
aws application-autoscaling register-scalable-target \
--service-namespace dynamodb \
--resource-id "table/TestTable" \
--scalable-dimension "dynamodb:table:WriteCapacityUnits" \
--min-capacity 5 \
--max-capacity 10
```
1. Verwenden Sie den folgenden Befehl, um die Registrierung zu überprüfen.
```
aws application-autoscaling describe-scalable-targets \
--service-namespace dynamodb \
--resource-id "table/TestTable"
```
**Anmerkung**
Sie können ein skalierbares Ziel auch für einen globalen sekundären Index registrieren. Beispielsweise werden für einen globalen sekundären Index („Testindex“) die Ressourcen-ID und die skalierbaren Dimensionsargumente entsprechend aktualisiert.
```
aws application-autoscaling register-scalable-target \
--service-namespace dynamodb \
--resource-id "table/TestTable/index/test-index" \
--scalable-dimension "dynamodb:index:WriteCapacityUnits" \
--min-capacity 5 \
--max-capacity 10
```
## Schritt 3: Erstellen einer Skalierungsrichtlinie
In diesem Schritt erstellen Sie eine Skalierungsrichtlinie für `TestTable`. Die Richtlinie definiert die Details, unter denen Application Auto Scaling den bereitgestellten Durchsatz Ihrer Tabelle anpassen kann und welche Aktionen erfolgen müssen, wenn dies geschieht. Sie ordnen diese Richtlinie dem skalierbaren Ziel zu, das Sie im vorherigen Schritt definiert haben (Schreibkapazitätseinheiten für die `TestTable`-Tabelle).
Die Richtlinie enthält die folgenden Elemente:
+ `PredefinedMetricSpecification` – Die Metrik, die Application Auto Scaling anpassen darf. Für DynamoDB sind die folgenden Werte gültige Werte für `PredefinedMetricType`:
+ `DynamoDBReadCapacityUtilization`
+ `DynamoDBWriteCapacityUtilization`
+ `ScaleOutCooldown` – Die Mindestzeit (in Sekunden) zwischen jedem Application-Auto-Scaling-Ereignis, das den bereitgestellten Durchsatz erhöht. Dieser Parameter ermöglicht Application Auto Scaling den Durchsatz als Reaktion auf reale Workloads fortlaufend, aber nicht aggressiv, zu erhöhen. Die Standardeinstellung für `ScaleOutCooldown` lautet 0.
+ `ScaleInCooldown` – Die Mindestzeit (in Sekunden) zwischen jedem Application-Auto-Scaling-Ereignis, das den bereitgestellten Durchsatz verringert. Dieser Parameter ermöglicht Application Auto Scaling den Durchsatz schrittweise und berechenbar zu verringern. Die Standardeinstellung für `ScaleInCooldown` lautet 0.
+ `TargetValue`—Application Auto Scaling stellt sicher, dass das Verhältnis von verbrauchter Kapazität zu bereitgestellter Kapazität diesem Wert nahezu entspricht. Sie definieren `TargetValue` als Prozentsatz.
**Anmerkung**
Um besser zu verstehen, wie der `TargetValue` funktioniert, nehmen Sie an, dass Sie über eine Tabelle mit einer Einstellung des bereitgestellten Durchsatzes von 200 Schreibkapazitätseinheiten verfügen. Sie entscheiden sich dafür, eine Skalierungsrichtlinie für diese Tabelle mit einem `TargetValue` von 70 % zu erstellen.
Angenommen, Sie beginnen den Schreibverkehr zu der Tabelle zu leiten, damit der tatsächliche Schreibdurchsatz bei 150 Kapazitätseinheiten liegt. Das consumed-to-provisioned Verhältnis liegt jetzt bei (150/ 200) oder 75 Prozent. Dieses Verhältnis überschreitet Ihr Ziel, sodass Application Auto Scaling die bereitgestellte Schreibkapazität auf 215 erhöht, damit das Verhältnis (150 / 215) oder 69,77 Prozent ist – so nah an Ihrem `TargetValue` wie möglich, jedoch nicht darüber.
Für `TestTable`, setzen Sie `TargetValue` 50 Prozent. Application Auto Scaling passt den bereitgestellten Durchsatz der Tabelle im Bereich von 5 bis 10 Kapazitätseinheiten (siehe[Schritt 2: Registrieren eines skalierbaren Ziels](#AutoScaling.CLI.RegisterScalableTarget)) an, sodass das consumed-to-provisioned Verhältnis bei oder nahe 50 Prozent bleibt. Sie legen die Werte für `ScaleOutCooldown` und `ScaleInCooldown` auf 60 Sekunden fest.
1. Erstellen Sie eine Datei mit dem Namen `scaling-policy.json` und dem folgenden Inhalt.
```
{
"PredefinedMetricSpecification": {
"PredefinedMetricType": "DynamoDBWriteCapacityUtilization"
},
"ScaleOutCooldown": 60,
"ScaleInCooldown": 60,
"TargetValue": 50.0
}
```
1. Verwenden Sie den folgenden AWS CLI Befehl, um die Richtlinie zu erstellen.
```
aws application-autoscaling put-scaling-policy \
--service-namespace dynamodb \
--resource-id "table/TestTable" \
--scalable-dimension "dynamodb:table:WriteCapacityUnits" \
--policy-name "MyScalingPolicy" \
--policy-type "TargetTrackingScaling" \
--target-tracking-scaling-policy-configuration file://scaling-policy.json
```
1. Beachten Sie in der Ausgabe, dass Application Auto Scaling zwei CloudWatch Amazon-Alarme generiert hat — jeweils einen für die obere und untere Grenze des Skalierungszielbereichs.
1. Verwenden Sie den folgenden AWS CLI Befehl, um weitere Details zur Skalierungsrichtlinie anzuzeigen.
```
aws application-autoscaling describe-scaling-policies \
--service-namespace dynamodb \
--resource-id "table/TestTable" \
--policy-name "MyScalingPolicy"
```
1. Überprüfen Sie in der Ausgabe, dass die Richtlinieneinstellungen mit Ihren Spezifikationen von [Schritt 2: Registrieren eines skalierbaren Ziels](#AutoScaling.CLI.RegisterScalableTarget) und [Schritt 3: Erstellen einer Skalierungsrichtlinie](#AutoScaling.CLI.CreateScalingPolicy) übereinstimmen.
## Schritt 4: Leiten Sie den Schreibverkehr weiter zu TestTable
Jetzt können Sie Ihre Skalierungsrichtlinie testen, indem Sie Daten in die `TestTable` schreiben. Führen Sie dafür ein Python-Programm aus.
1. Erstellen Sie eine Datei mit dem Namen `bulk-load-test-table.py` und dem folgenden Inhalt.
```
import boto3
dynamodb = boto3.resource('dynamodb')
table = dynamodb.Table("TestTable")
filler = "x" * 100000
i = 0
while (i < 10):
j = 0
while (j < 10):
print (i, j)
table.put_item(
Item={
'pk':i,
'sk':j,
'filler':{"S":filler}
}
)
j += 1
i += 1
```
1. Geben Sie den folgenden Befehl ein, um das Programm auszuführen.
`python bulk-load-test-table.py`
Die bereitgestellte Schreibkapazität für `TestTable` ist sehr niedrig (5 Schreibkapazitätseinheiten), sodass das Programm aufgrund von Schreibeinschränkungen gelegentlich stockt. Dieses Verhalten wird erwartet.
Lassen Sie das Programm weiter ausführen, während Sie mit dem nächsten Schritt fortfahren.
## Schritt 5: Anzeigen der Application Auto Scaling
In diesem Schritt sehen Sie sich die Application-Auto-Scaling-Aktionen an, die in Ihrem Namen initiiert werden. Sie überprüfen ebenfalls, ob Application Auto Scaling die bereitgestellte Schreibkapazität für `TestTable` aktualisiert hat.
1. Geben Sie den folgenden Befehl ein, um die Application Auto Scaling-Aktionen anzuzeigen.
```
aws application-autoscaling describe-scaling-activities \
--service-namespace dynamodb
```
Führen Sie diesen Befehl gelegentlich erneut aus, während das Python-Programm ausgeführt wird. (Es kann einige Minuten dauern, bevor die Skalierungsrichtlinie aufgerufen wird.) Sie sollten schließlich die folgende Ausgabe sehen.
```
...
{
"ScalableDimension": "dynamodb:table:WriteCapacityUnits",
"Description": "Setting write capacity units to 10.",
"ResourceId": "table/TestTable",
"ActivityId": "0cc6fb03-2a7c-4b51-b67f-217224c6b656",
"StartTime": 1489088210.175,
"ServiceNamespace": "dynamodb",
"EndTime": 1489088246.85,
"Cause": "monitor alarm AutoScaling-table/TestTable-AlarmHigh-1bb3c8db-1b97-4353-baf1-4def76f4e1b9 in state ALARM triggered policy MyScalingPolicy",
"StatusMessage": "Successfully set write capacity units to 10. Change successfully fulfilled by dynamodb.",
"StatusCode": "Successful"
},
...
```
Dies weist darauf hin, dass Application Auto Scaling eine `UpdateTable`Anforderung an DynamoDB ausgegeben hat.
1. Geben Sie den folgenden Befehl ein, um zu überprüfen, ob DynamoDB die Schreibkapazität der Tabelle erhöht hat:
```
aws dynamodb describe-table \
--table-name TestTable \
--query "Table.[TableName,TableStatus,ProvisionedThroughput]"
```
Die `WriteCapacityUnits` hätten von `5` auf `10` skaliert werden sollen.
## (Optional) Schritt 6: Bereinigen
In diesem Tutorial haben Sie einige Ressourcen erstellt. Sie können diese Ressourcen löschen, wenn Sie sie nicht mehr benötigen.
1. Löschen Sie die Skalierungsrichtlinie für `TestTable`:
```
aws application-autoscaling delete-scaling-policy \
--service-namespace dynamodb \
--resource-id "table/TestTable" \
--scalable-dimension "dynamodb:table:WriteCapacityUnits" \
--policy-name "MyScalingPolicy"
```
1. Melden Sie das skalierbare Ziel ab.
```
aws application-autoscaling deregister-scalable-target \
--service-namespace dynamodb \
--resource-id "table/TestTable" \
--scalable-dimension "dynamodb:table:WriteCapacityUnits"
```
1. Löschen Sie die `TestTable`-Tabelle.
```
aws dynamodb delete-table --table-name TestTable
```
# Verwenden des AWS SDK zur Konfiguration von Auto Scaling für Amazon DynamoDB-Tabellen
Zusätzlich zur Verwendung von AWS-Managementkonsole und AWS Command Line Interface (AWS CLI) können Sie Anwendungen schreiben, die mit Amazon DynamoDB Auto Scaling interagieren. Dieser Abschnitt enthält zwei Java-Programme, die Sie verwenden können, um diese Funktionalität zu testen:
+ `EnableDynamoDBAutoscaling.java`
+ `DisableDynamoDBAutoscaling.java`
## Aktivieren von Application Auto Scaling für eine Tabelle
Das folgende Programm zeigt ein Beispiel für die Einrichtung einer Auto-Scaling-Richtlinie für eine DynamoDB-Tabelle (`TestTable`). Es fährt wie folgt fort:
+ Das Programm registriert Schreibkapazitätseinheiten als skalierbares Ziel für `TestTable`. Der Bereich für diese Metrik liegt zwischen 5 und 10 Schreibkapazitätseinheiten.
+ Nachdem das skalierbare Ziel erstellt wird, erstellt das Programm eine Ziel-Tracking-Konfiguration. Die Richtlinie versucht ein 50 %-Zielverhältnis zwischen verbrauchter und bereitgestellter Schreibkapazität beizubehalten.
+ Das Programm erstellt dann die Skalierungsrichtlinie, basierend auf der Ziel-Tracking-Konfiguration.
**Anmerkung**
Wenn Sie eine Tabelle oder ein globales Tabellenreplikat manuell entfernen, entfernen Sie nicht automatisch alle zugehörigen skalierbaren Ziele, Skalierungsrichtlinien oder Alarme. CloudWatch
------
#### [ Java v2 ]
```
import software.amazon.awssdk.regions.Region;
import software.amazon.awssdk.services.applicationautoscaling.ApplicationAutoScalingClient;
import software.amazon.awssdk.services.applicationautoscaling.model.ApplicationAutoScalingException;
import software.amazon.awssdk.services.applicationautoscaling.model.DescribeScalableTargetsRequest;
import software.amazon.awssdk.services.applicationautoscaling.model.DescribeScalableTargetsResponse;
import software.amazon.awssdk.services.applicationautoscaling.model.DescribeScalingPoliciesRequest;
import software.amazon.awssdk.services.applicationautoscaling.model.DescribeScalingPoliciesResponse;
import software.amazon.awssdk.services.applicationautoscaling.model.PolicyType;
import software.amazon.awssdk.services.applicationautoscaling.model.PredefinedMetricSpecification;
import software.amazon.awssdk.services.applicationautoscaling.model.PutScalingPolicyRequest;
import software.amazon.awssdk.services.applicationautoscaling.model.RegisterScalableTargetRequest;
import software.amazon.awssdk.services.applicationautoscaling.model.ScalingPolicy;
import software.amazon.awssdk.services.applicationautoscaling.model.ServiceNamespace;
import software.amazon.awssdk.services.applicationautoscaling.model.ScalableDimension;
import software.amazon.awssdk.services.applicationautoscaling.model.MetricType;
import software.amazon.awssdk.services.applicationautoscaling.model.TargetTrackingScalingPolicyConfiguration;
import java.util.List;
/**
* Before running this Java V2 code example, set up your development environment, including your credentials.
*
* For more information, see the following documentation topic:
*
* https://docs.aws.amazon.com/sdk-for-java/latest/developer-guide/get-started.html
*/
public class EnableDynamoDBAutoscaling {
public static void main(String[] args) {
final String usage = """
Usage:
\s
Where:
tableId - The table Id value (for example, table/Music).
roleARN - The ARN of the role that has ApplicationAutoScaling permissions.
policyName - The name of the policy to create.
""";
if (args.length != 3) {
System.out.println(usage);
System.exit(1);
}
System.out.println("This example registers an Amazon DynamoDB table, which is the resource to scale.");
String tableId = args[0];
String roleARN = args[1];
String policyName = args[2];
ServiceNamespace ns = ServiceNamespace.DYNAMODB;
ScalableDimension tableWCUs = ScalableDimension.DYNAMODB_TABLE_WRITE_CAPACITY_UNITS;
ApplicationAutoScalingClient appAutoScalingClient = ApplicationAutoScalingClient.builder()
.region(Region.US_EAST_1)
.build();
registerScalableTarget(appAutoScalingClient, tableId, roleARN, ns, tableWCUs);
verifyTarget(appAutoScalingClient, tableId, ns, tableWCUs);
configureScalingPolicy(appAutoScalingClient, tableId, ns, tableWCUs, policyName);
}
public static void registerScalableTarget(ApplicationAutoScalingClient appAutoScalingClient, String tableId, String roleARN, ServiceNamespace ns, ScalableDimension tableWCUs) {
try {
RegisterScalableTargetRequest targetRequest = RegisterScalableTargetRequest.builder()
.serviceNamespace(ns)
.scalableDimension(tableWCUs)
.resourceId(tableId)
.roleARN(roleARN)
.minCapacity(5)
.maxCapacity(10)
.build();
appAutoScalingClient.registerScalableTarget(targetRequest);
System.out.println("You have registered " + tableId);
} catch (ApplicationAutoScalingException e) {
System.err.println(e.awsErrorDetails().errorMessage());
}
}
// Verify that the target was created.
public static void verifyTarget(ApplicationAutoScalingClient appAutoScalingClient, String tableId, ServiceNamespace ns, ScalableDimension tableWCUs) {
DescribeScalableTargetsRequest dscRequest = DescribeScalableTargetsRequest.builder()
.scalableDimension(tableWCUs)
.serviceNamespace(ns)
.resourceIds(tableId)
.build();
DescribeScalableTargetsResponse response = appAutoScalingClient.describeScalableTargets(dscRequest);
System.out.println("DescribeScalableTargets result: ");
System.out.println(response);
}
// Configure a scaling policy.
public static void configureScalingPolicy(ApplicationAutoScalingClient appAutoScalingClient, String tableId, ServiceNamespace ns, ScalableDimension tableWCUs, String policyName) {
// Check if the policy exists before creating a new one.
DescribeScalingPoliciesResponse describeScalingPoliciesResponse = appAutoScalingClient.describeScalingPolicies(DescribeScalingPoliciesRequest.builder()
.serviceNamespace(ns)
.resourceId(tableId)
.scalableDimension(tableWCUs)
.build());
if (!describeScalingPoliciesResponse.scalingPolicies().isEmpty()) {
// If policies exist, consider updating an existing policy instead of creating a new one.
System.out.println("Policy already exists. Consider updating it instead.");
List polList = describeScalingPoliciesResponse.scalingPolicies();
for (ScalingPolicy pol : polList) {
System.out.println("Policy name:" +pol.policyName());
}
} else {
// If no policies exist, proceed with creating a new policy.
PredefinedMetricSpecification specification = PredefinedMetricSpecification.builder()
.predefinedMetricType(MetricType.DYNAMO_DB_WRITE_CAPACITY_UTILIZATION)
.build();
TargetTrackingScalingPolicyConfiguration policyConfiguration = TargetTrackingScalingPolicyConfiguration.builder()
.predefinedMetricSpecification(specification)
.targetValue(50.0)
.scaleInCooldown(60)
.scaleOutCooldown(60)
.build();
PutScalingPolicyRequest putScalingPolicyRequest = PutScalingPolicyRequest.builder()
.targetTrackingScalingPolicyConfiguration(policyConfiguration)
.serviceNamespace(ns)
.scalableDimension(tableWCUs)
.resourceId(tableId)
.policyName(policyName)
.policyType(PolicyType.TARGET_TRACKING_SCALING)
.build();
try {
appAutoScalingClient.putScalingPolicy(putScalingPolicyRequest);
System.out.println("You have successfully created a scaling policy for an Application Auto Scaling scalable target");
} catch (ApplicationAutoScalingException e) {
System.err.println("Error: " + e.awsErrorDetails().errorMessage());
}
}
}
}
```
------
#### [ Java v1 ]
Das Programm erfordert, dass Sie einenn Amazon-Ressourcennamen (ARN) für eine gültige serviceverknüpfte Application-Auto-Scaling-Rolle angeben. (Zum Beispiel: `arn:aws:iam::122517410325:role/AWSServiceRoleForApplicationAutoScaling_DynamoDBTable`.) Ersetzen Sie im folgenden Programm `SERVICE_ROLE_ARN_GOES_HERE` mit dem tatsächlichen ARN.
```
package com.amazonaws.codesamples.autoscaling;
import com.amazonaws.services.applicationautoscaling.AWSApplicationAutoScalingClient;
import com.amazonaws.services.applicationautoscaling.AWSApplicationAutoScalingClientBuilder;
import com.amazonaws.services.applicationautoscaling.model.DescribeScalableTargetsRequest;
import com.amazonaws.services.applicationautoscaling.model.DescribeScalableTargetsResult;
import com.amazonaws.services.applicationautoscaling.model.DescribeScalingPoliciesRequest;
import com.amazonaws.services.applicationautoscaling.model.DescribeScalingPoliciesResult;
import com.amazonaws.services.applicationautoscaling.model.MetricType;
import com.amazonaws.services.applicationautoscaling.model.PolicyType;
import com.amazonaws.services.applicationautoscaling.model.PredefinedMetricSpecification;
import com.amazonaws.services.applicationautoscaling.model.PutScalingPolicyRequest;
import com.amazonaws.services.applicationautoscaling.model.RegisterScalableTargetRequest;
import com.amazonaws.services.applicationautoscaling.model.ScalableDimension;
import com.amazonaws.services.applicationautoscaling.model.ServiceNamespace;
import com.amazonaws.services.applicationautoscaling.model.TargetTrackingScalingPolicyConfiguration;
public class EnableDynamoDBAutoscaling {
static AWSApplicationAutoScalingClient aaClient = (AWSApplicationAutoScalingClient) AWSApplicationAutoScalingClientBuilder
.standard().build();
public static void main(String args[]) {
ServiceNamespace ns = ServiceNamespace.Dynamodb;
ScalableDimension tableWCUs = ScalableDimension.DynamodbTableWriteCapacityUnits;
String resourceID = "table/TestTable";
// Define the scalable target
RegisterScalableTargetRequest rstRequest = new RegisterScalableTargetRequest()
.withServiceNamespace(ns)
.withResourceId(resourceID)
.withScalableDimension(tableWCUs)
.withMinCapacity(5)
.withMaxCapacity(10)
.withRoleARN("SERVICE_ROLE_ARN_GOES_HERE");
try {
aaClient.registerScalableTarget(rstRequest);
} catch (Exception e) {
System.err.println("Unable to register scalable target: ");
System.err.println(e.getMessage());
}
// Verify that the target was created
DescribeScalableTargetsRequest dscRequest = new DescribeScalableTargetsRequest()
.withServiceNamespace(ns)
.withScalableDimension(tableWCUs)
.withResourceIds(resourceID);
try {
DescribeScalableTargetsResult dsaResult = aaClient.describeScalableTargets(dscRequest);
System.out.println("DescribeScalableTargets result: ");
System.out.println(dsaResult);
System.out.println();
} catch (Exception e) {
System.err.println("Unable to describe scalable target: ");
System.err.println(e.getMessage());
}
System.out.println();
// Configure a scaling policy
TargetTrackingScalingPolicyConfiguration targetTrackingScalingPolicyConfiguration = new TargetTrackingScalingPolicyConfiguration()
.withPredefinedMetricSpecification(
new PredefinedMetricSpecification()
.withPredefinedMetricType(MetricType.DynamoDBWriteCapacityUtilization))
.withTargetValue(50.0)
.withScaleInCooldown(60)
.withScaleOutCooldown(60);
// Create the scaling policy, based on your configuration
PutScalingPolicyRequest pspRequest = new PutScalingPolicyRequest()
.withServiceNamespace(ns)
.withScalableDimension(tableWCUs)
.withResourceId(resourceID)
.withPolicyName("MyScalingPolicy")
.withPolicyType(PolicyType.TargetTrackingScaling)
.withTargetTrackingScalingPolicyConfiguration(targetTrackingScalingPolicyConfiguration);
try {
aaClient.putScalingPolicy(pspRequest);
} catch (Exception e) {
System.err.println("Unable to put scaling policy: ");
System.err.println(e.getMessage());
}
// Verify that the scaling policy was created
DescribeScalingPoliciesRequest dspRequest = new DescribeScalingPoliciesRequest()
.withServiceNamespace(ns)
.withScalableDimension(tableWCUs)
.withResourceId(resourceID);
try {
DescribeScalingPoliciesResult dspResult = aaClient.describeScalingPolicies(dspRequest);
System.out.println("DescribeScalingPolicies result: ");
System.out.println(dspResult);
} catch (Exception e) {
e.printStackTrace();
System.err.println("Unable to describe scaling policy: ");
System.err.println(e.getMessage());
}
}
}
```
------
## Deaktivieren der Application Auto Scaling für eine Tabelle
Das folgende Programm macht den vorherigen Prozess rückgängig. Es entfernt die Auto Scaling-Richtlinie und hebt die Registrierung des skalierbaren Ziels auf.
------
#### [ Java v2 ]
```
import software.amazon.awssdk.regions.Region;
import software.amazon.awssdk.services.applicationautoscaling.ApplicationAutoScalingClient;
import software.amazon.awssdk.services.applicationautoscaling.model.ApplicationAutoScalingException;
import software.amazon.awssdk.services.applicationautoscaling.model.DeleteScalingPolicyRequest;
import software.amazon.awssdk.services.applicationautoscaling.model.DeregisterScalableTargetRequest;
import software.amazon.awssdk.services.applicationautoscaling.model.DescribeScalableTargetsRequest;
import software.amazon.awssdk.services.applicationautoscaling.model.DescribeScalableTargetsResponse;
import software.amazon.awssdk.services.applicationautoscaling.model.DescribeScalingPoliciesRequest;
import software.amazon.awssdk.services.applicationautoscaling.model.DescribeScalingPoliciesResponse;
import software.amazon.awssdk.services.applicationautoscaling.model.ScalableDimension;
import software.amazon.awssdk.services.applicationautoscaling.model.ServiceNamespace;
/**
* Before running this Java V2 code example, set up your development environment, including your credentials.
*
* For more information, see the following documentation topic:
*
* https://docs.aws.amazon.com/sdk-for-java/latest/developer-guide/get-started.html
*/
public class DisableDynamoDBAutoscaling {
public static void main(String[] args) {
final String usage = """
Usage:
\s
Where:
tableId - The table Id value (for example, table/Music).\s
policyName - The name of the policy (for example, $Music5-scaling-policy).
""";
if (args.length != 2) {
System.out.println(usage);
System.exit(1);
}
ApplicationAutoScalingClient appAutoScalingClient = ApplicationAutoScalingClient.builder()
.region(Region.US_EAST_1)
.build();
ServiceNamespace ns = ServiceNamespace.DYNAMODB;
ScalableDimension tableWCUs = ScalableDimension.DYNAMODB_TABLE_WRITE_CAPACITY_UNITS;
String tableId = args[0];
String policyName = args[1];
deletePolicy(appAutoScalingClient, policyName, tableWCUs, ns, tableId);
verifyScalingPolicies(appAutoScalingClient, tableId, ns, tableWCUs);
deregisterScalableTarget(appAutoScalingClient, tableId, ns, tableWCUs);
verifyTarget(appAutoScalingClient, tableId, ns, tableWCUs);
}
public static void deletePolicy(ApplicationAutoScalingClient appAutoScalingClient, String policyName, ScalableDimension tableWCUs, ServiceNamespace ns, String tableId) {
try {
DeleteScalingPolicyRequest delSPRequest = DeleteScalingPolicyRequest.builder()
.policyName(policyName)
.scalableDimension(tableWCUs)
.serviceNamespace(ns)
.resourceId(tableId)
.build();
appAutoScalingClient.deleteScalingPolicy(delSPRequest);
System.out.println(policyName +" was deleted successfully.");
} catch (ApplicationAutoScalingException e) {
System.err.println(e.awsErrorDetails().errorMessage());
}
}
// Verify that the scaling policy was deleted
public static void verifyScalingPolicies(ApplicationAutoScalingClient appAutoScalingClient, String tableId, ServiceNamespace ns, ScalableDimension tableWCUs) {
DescribeScalingPoliciesRequest dscRequest = DescribeScalingPoliciesRequest.builder()
.scalableDimension(tableWCUs)
.serviceNamespace(ns)
.resourceId(tableId)
.build();
DescribeScalingPoliciesResponse response = appAutoScalingClient.describeScalingPolicies(dscRequest);
System.out.println("DescribeScalableTargets result: ");
System.out.println(response);
}
public static void deregisterScalableTarget(ApplicationAutoScalingClient appAutoScalingClient, String tableId, ServiceNamespace ns, ScalableDimension tableWCUs) {
try {
DeregisterScalableTargetRequest targetRequest = DeregisterScalableTargetRequest.builder()
.scalableDimension(tableWCUs)
.serviceNamespace(ns)
.resourceId(tableId)
.build();
appAutoScalingClient.deregisterScalableTarget(targetRequest);
System.out.println("The scalable target was deregistered.");
} catch (ApplicationAutoScalingException e) {
System.err.println(e.awsErrorDetails().errorMessage());
}
}
public static void verifyTarget(ApplicationAutoScalingClient appAutoScalingClient, String tableId, ServiceNamespace ns, ScalableDimension tableWCUs) {
DescribeScalableTargetsRequest dscRequest = DescribeScalableTargetsRequest.builder()
.scalableDimension(tableWCUs)
.serviceNamespace(ns)
.resourceIds(tableId)
.build();
DescribeScalableTargetsResponse response = appAutoScalingClient.describeScalableTargets(dscRequest);
System.out.println("DescribeScalableTargets result: ");
System.out.println(response);
}
}
```
------
#### [ Java v1 ]
```
package com.amazonaws.codesamples.autoscaling;
import com.amazonaws.services.applicationautoscaling.AWSApplicationAutoScalingClient;
import com.amazonaws.services.applicationautoscaling.model.DeleteScalingPolicyRequest;
import com.amazonaws.services.applicationautoscaling.model.DeregisterScalableTargetRequest;
import com.amazonaws.services.applicationautoscaling.model.DescribeScalableTargetsRequest;
import com.amazonaws.services.applicationautoscaling.model.DescribeScalableTargetsResult;
import com.amazonaws.services.applicationautoscaling.model.DescribeScalingPoliciesRequest;
import com.amazonaws.services.applicationautoscaling.model.DescribeScalingPoliciesResult;
import com.amazonaws.services.applicationautoscaling.model.ScalableDimension;
import com.amazonaws.services.applicationautoscaling.model.ServiceNamespace;
public class DisableDynamoDBAutoscaling {
static AWSApplicationAutoScalingClient aaClient = new AWSApplicationAutoScalingClient();
public static void main(String args[]) {
ServiceNamespace ns = ServiceNamespace.Dynamodb;
ScalableDimension tableWCUs = ScalableDimension.DynamodbTableWriteCapacityUnits;
String resourceID = "table/TestTable";
// Delete the scaling policy
DeleteScalingPolicyRequest delSPRequest = new DeleteScalingPolicyRequest()
.withServiceNamespace(ns)
.withScalableDimension(tableWCUs)
.withResourceId(resourceID)
.withPolicyName("MyScalingPolicy");
try {
aaClient.deleteScalingPolicy(delSPRequest);
} catch (Exception e) {
System.err.println("Unable to delete scaling policy: ");
System.err.println(e.getMessage());
}
// Verify that the scaling policy was deleted
DescribeScalingPoliciesRequest descSPRequest = new DescribeScalingPoliciesRequest()
.withServiceNamespace(ns)
.withScalableDimension(tableWCUs)
.withResourceId(resourceID);
try {
DescribeScalingPoliciesResult dspResult = aaClient.describeScalingPolicies(descSPRequest);
System.out.println("DescribeScalingPolicies result: ");
System.out.println(dspResult);
} catch (Exception e) {
e.printStackTrace();
System.err.println("Unable to describe scaling policy: ");
System.err.println(e.getMessage());
}
System.out.println();
// Remove the scalable target
DeregisterScalableTargetRequest delSTRequest = new DeregisterScalableTargetRequest()
.withServiceNamespace(ns)
.withScalableDimension(tableWCUs)
.withResourceId(resourceID);
try {
aaClient.deregisterScalableTarget(delSTRequest);
} catch (Exception e) {
System.err.println("Unable to deregister scalable target: ");
System.err.println(e.getMessage());
}
// Verify that the scalable target was removed
DescribeScalableTargetsRequest dscRequest = new DescribeScalableTargetsRequest()
.withServiceNamespace(ns)
.withScalableDimension(tableWCUs)
.withResourceIds(resourceID);
try {
DescribeScalableTargetsResult dsaResult = aaClient.describeScalableTargets(dscRequest);
System.out.println("DescribeScalableTargets result: ");
System.out.println(dsaResult);
System.out.println();
} catch (Exception e) {
System.err.println("Unable to describe scalable target: ");
System.err.println(e.getMessage());
}
}
}
```
------
# DynamoDB – reservierte Kapazität
Für Tabellen mit bereitgestellter Kapazität, die die Standard-[Tabellenklasse](HowItWorks.TableClasses.md) verwenden, bietet DynamoDB die Möglichkeit, reservierte Kapazität für Ihre Lese- und Schreibkapazität zu erwerben. Der Erwerb reservierter Kapazität ist eine Vereinbarung zur Zahlung für eine Mindestmenge an bereitgestellter Durchsatzkapazität für die Dauer der Vereinbarung zu vergünstigten Preisen.
**Anmerkung**
Sie können keine reservierte Kapazität für replizierte Schreibkapazitätseinheiten (rWCUs) erwerben. Reservierte Kapazität gilt nur für die Region, in der sie erworben wurde. Reservierte Kapazität ist auch nicht für Tabellen verfügbar, die die DynamoDB Standard-IA-Tabellenklasse oder den On-Demand-Kapazitätsmodus verwenden.
Reservierte Kapazität wird in Zuordnungen von 100 WCUs oder 100 erworben. RCUs Das kleinste Angebot an reservierter Kapazität umfasst 100 Kapazitätseinheiten (Lese- oder Schreibvorgänge). Reservierte DynamoDB-Kapazität wird entweder als einjähriges Abonnement oder in ausgewählten Regionen als dreijähriges Abonnement angeboten. Bei einer Laufzeit von einem Jahr können Sie bis zu 54 % gegenüber den Standardtarifen und bei einer Laufzeit von drei Jahren bis zu 77 % gegenüber den Standardtarifen sparen. Weitere Informationen darüber, wie und wann Sie kaufen sollten, finden Sie unter [Amazon DynamoDB – reservierte Kapazität](https://aws.amazon.com/dynamodb/reserved-capacity/).
**Anmerkung**
Mit der AWS Management Console können Sie insgesamt bis zu 1.000.000 reservierte Kapazitätseinheiten für Schreibkapazitätseinheiten (WCUs) und Lesekapazitätseinheiten (RCUs) erwerben. Wenn Sie mehr als 1.000.000 bereitgestellte Kapazitätseinheiten in einem einzigen Kauf erwerben möchten oder über aktive reservierte Kapazität verfügen und zusätzliche reservierte Kapazität erwerben möchten, was zu mehr als 1.000.000 aktiven bereitgestellten Kapazitätseinheiten führen würde, gehen Sie wie im Abschnitt „So kaufen Sie reservierte Kapazität“ in [Amazon](https://aws.amazon.com/dynamodb/reserved-capacity/) DynamoDB Reserved Capacity beschrieben vor.
Wenn Sie reservierte DynamoDB-Kapazität erwerben, zahlen Sie eine einmalige Teilvorauszahlung und erhalten einen vergünstigten Stundensatz für die zugesicherte, bereitgestellte Nutzung. Sie zahlen für die gesamte zugesagte bereitgestellte Nutzung, unabhängig von der tatsächlichen Nutzung, sodass Ihre Kosteneinsparungen eng mit der Nutzung verknüpft sind. Kapazitäten, die Sie über die reservierte Kapazität hinaus nutzen, werden zu Standardpreisen für bereitgestellte Kapazität verrechnet. Durch die Reservierung der Lese- und Schreibkapazitätseinheiten im Voraus erzielen Sie erhebliche Einsparungen Ihrer Kosten für bereitgestellte Kapazitäten.
Sie können reservierte Kapazität nicht verkaufen, kündigen oder in eine andere Region oder ein anderes Konto übertragen.
# Grundlegendes zum Warmdurchsatz von DynamoDB
*Warmdurchsatz* bezieht sich auf die Anzahl der Lese- und Schreibvorgänge, die Ihre DynamoDB-Tabelle sofort unterstützen kann. Diese Werte sind standardmäßig für alle Tabellen und globalen sekundären Indizes (GSI) verfügbar und geben an, wie stark sie auf der Grundlage der historischen Nutzung skaliert wurden. Wenn Sie den On-Demand-Modus verwenden oder den bereitgestellten Durchsatz auf diese Werte aktualisieren, kann Ihre Anwendung sofort Anforderungen bis zu diesen Werten ausgeben.
DynamoDB passt die Werte für den Warmdurchsatz automatisch an, wenn Ihre Nutzung zunimmt. Sie können diese Werte bei Bedarf auch proaktiv erhöhen, was besonders bei bevorstehenden Spitzenereignissen wie Produkteinführungen oder Verkäufen nützlich ist. Bei geplanten Spitzenereignissen, bei denen die Anforderungsraten an Ihre DynamoDB-Tabelle um das Zehn-, Hundertfache oder mehr steigen könnten, können Sie jetzt bewerten, ob der aktuelle Warmdurchsatz ausreicht, um den erwarteten Datenverkehr zu bewältigen. Ist dies nicht der Fall, können Sie den Wert für den Warmdurchsatz erhöhen, ohne Ihre Durchsatzeinstellungen oder den [Fakturierungsmodus](capacity-mode.md) zu ändern. Dieser Vorgang wird als *Vorwärmen* einer Tabelle bezeichnet, sodass Sie eine Baseline festlegen können, den Ihre Tabellen sofort unterstützen können. Dadurch wird sichergestellt, dass Ihre Anwendungen höhere Anforderungsraten von dem Moment an bewältigen können, in dem sie auftreten. Sobald die Werte für den Warmdurchsatz erhöht wurden, können sie nicht mehr verringert werden.
Sie können den Wert für den Warmdurchsatz für Lesevorgänge, Schreibvorgänge oder beides erhöhen. Sie können diesen Wert für neue und bestehende Tabellen mit einer Region, globale Tabellen und GSIs erhöhen. Bei globalen Tabellen ist diese Funktion für [Version 2019.11.21 (aktuell)](GlobalTables.md) verfügbar. Die von Ihnen festgelegten Einstellungen für den Warmdurchsatz gelten automatisch für alle Replikattabellen in der globalen Tabelle. Es gibt keine Begrenzung der Anzahl von DynamoDB-Tabellen, die Sie jederzeit vorwärmen können. Die Dauer des Vorwärmens hängt von den von Ihnen eingestellten Werten und der Größe der Tabelle oder des Index ab. Sie können Anforderungen zum Vorwärmen gleichzeitig einreichen, ohne dass diese Anforderungen die Tabellenoperationen beeinträchtigen. Sie können Ihre Tabelle vorwärmen, bis das Tabellen- oder Indexkontingentlimit für Ihr Konto in dieser Region erreicht ist. Verwenden Sie die [Service-Quotas-Konsole](https://console.aws.amazon.com/servicequotas), um Ihre aktuellen Limits zu überprüfen und sie bei Bedarf zu erhöhen.
Werte für den Warmdurchsatz sind standardmäßig für alle Tabellen und sekundären Indizes kostenlos verfügbar. Wenn Sie diese Standardwerte für den Warmdurchsatz jedoch proaktiv erhöhen, um die Tabellen vorzuwärmen, werden Ihnen diese Anforderungen in Rechnung gestellt. Weitere Informationen finden Sie unter [Amazon DynamoDB – Preise](https://aws.amazon.com/dynamodb/pricing/).
Weitere Informationen zum Warmdurchsatz finden Sie in den folgenden Themen:
**Topics**
+ [Überprüfen des aktuellen Warmdurchsatzes Ihrer DynamoDB-Tabelle](check-warm-throughput.md)
+ [Erhöhen des Warmdurchsatzes für die vorhandene DynamoDB-Tabelle](update-warm-throughput.md)
+ [Erstellen einer neuen DynamoDB-Tabelle mit einem höheren Warmdurchsatz](create-table-warm-throughput.md)
+ [Grundlegendes zum DynamoDB-Warmdurchsatz in verschiedenen Szenarien](warm-throughput-scenarios.md)
# Überprüfen des aktuellen Warmdurchsatzes Ihrer DynamoDB-Tabelle
Verwenden Sie die folgenden Anweisungen AWS CLI und die Anweisungen in der AWS Konsole, um den aktuellen Warmdurchsatzwert Ihrer Tabelle oder Ihres Indexes zu überprüfen.
## AWS-Managementkonsole
So überprüfen Sie den Warmdurchsatz Ihrer DynamoDB-Tabelle mithilfe der DynamoDB-Konsole:
1. Melden Sie sich bei der an AWS-Managementkonsole und öffnen Sie die DynamoDB-Konsole unter. [https://console.aws.amazon.com/dynamodb/](https://console.aws.amazon.com/dynamodb/)
1. Wählen Sie im linken Navigationsbereich Tables (Tabellen) aus.
1. Wählen Sie auf der Seite **Tabellen** die gewünschte Tabelle aus.
1. Wählen Sie **Zusätzliche Einstellungen** aus, um den aktuellen Warmdurchsatzwert anzuzeigen. Dieser Wert wird als Leseeinheiten pro Sekunde und Schreibeinheiten pro Sekunde angezeigt.
## AWS CLI
Das folgende AWS CLI Beispiel zeigt Ihnen, wie Sie den Warmdurchsatz Ihrer DynamoDB-Tabelle überprüfen können.
1. Führen Sie die `describe-table`-Operation für die DynamoDB-Tabelle aus.
```
aws dynamodb describe-table --table-name GameScores
```
1. Sie erhalten eine ähnliche Antwort wie die folgende. Ihre `WarmThroughput`-Einstellungen werden als `ReadUnitsPerSecond` und `WriteUnitsPerSecond` angezeigt. `Status` lautet `UPDATING`, wenn der Wert für den Warmdurchsatz aktualisiert wird, und `ACTIVE`, wenn der neue Warmdurchsatzwert festgelegt wird.
```
{
"Table": {
"AttributeDefinitions": [
{
"AttributeName": "GameTitle",
"AttributeType": "S"
},
{
"AttributeName": "TopScore",
"AttributeType": "N"
},
{
"AttributeName": "UserId",
"AttributeType": "S"
}
],
"TableName": "GameScores",
"KeySchema": [
{
"AttributeName": "UserId",
"KeyType": "HASH"
},
{
"AttributeName": "GameTitle",
"KeyType": "RANGE"
}
],
"TableStatus": "ACTIVE",
"CreationDateTime": 1726128388.729,
"ProvisionedThroughput": {
"NumberOfDecreasesToday": 0,
"ReadCapacityUnits": 0,
"WriteCapacityUnits": 0
},
"TableSizeBytes": 0,
"ItemCount": 0,
"TableArn": "arn:aws:dynamodb:us-east-1:XXXXXXXXXXXX:table/GameScores",
"TableId": "XXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX",
"BillingModeSummary": {
"BillingMode": "PAY_PER_REQUEST",
"LastUpdateToPayPerRequestDateTime": 1726128388.729
},
"GlobalSecondaryIndexes": [
{
"IndexName": "GameTitleIndex",
"KeySchema": [
{
"AttributeName": "GameTitle",
"KeyType": "HASH"
},
{
"AttributeName": "TopScore",
"KeyType": "RANGE"
}
],
"Projection": {
"ProjectionType": "INCLUDE",
"NonKeyAttributes": [
"UserId"
]
},
"IndexStatus": "ACTIVE",
"ProvisionedThroughput": {
"NumberOfDecreasesToday": 0,
"ReadCapacityUnits": 0,
"WriteCapacityUnits": 0
},
"IndexSizeBytes": 0,
"ItemCount": 0,
"IndexArn": "arn:aws:dynamodb:us-east-1:XXXXXXXXXXXX:table/GameScores/index/GameTitleIndex",
"WarmThroughput": {
"ReadUnitsPerSecond": 12000,
"WriteUnitsPerSecond": 4000,
"Status": "ACTIVE"
}
}
],
"DeletionProtectionEnabled": false,
"WarmThroughput": {
"ReadUnitsPerSecond": 12000,
"WriteUnitsPerSecond": 4000,
"Status": "ACTIVE"
}
}
}
```
# Erhöhen des Warmdurchsatzes für die vorhandene DynamoDB-Tabelle
Nachdem Sie den aktuellen Warmdurchsatzwert Ihrer DynamoDB-Tabelle überprüft haben, können Sie ihn mit den folgenden Schritten aktualisieren:
## AWS-Managementkonsole
So überprüfen Sie den Warmdurchsatzwert Ihrer DynamoDB-Tabelle mithilfe der DynamoDB-Konsole:
1. Melden Sie sich bei der an AWS-Managementkonsole und öffnen Sie die DynamoDB-Konsole unter. [https://console.aws.amazon.com/dynamodb/](https://console.aws.amazon.com/dynamodb/)
1. Wählen Sie im linken Navigationsbereich Tables (Tabellen) aus.
1. Wählen Sie auf der Seite **Tabellen** die gewünschte Tabelle aus.
1. Wählen Sie im Feld **Warmdurchsatz** die Option **Bearbeiten** aus.
1. Wählen Sie auf der Seite **Warmdurchsatz bearbeiten** die Option **Warmdurchsatz erhöhen** aus.
1. Passen Sie die **Leseeinheiten pro Sekunde** und die **Schreibeinheiten pro Sekunde** an. Diese beiden Einstellungen definieren den Durchsatz, den die Tabelle sofort verarbeiten kann.
1. Wählen Sie **Speichern** aus.
1. Ihre **Leseeinheiten pro Sekunde** und **Schreibeinheiten pro Sekunde** werden im Feld **Warmdurchsatz** aktualisiert, wenn die Bearbeitung der Anforderung abgeschlossen ist.
**Anmerkung**
Die Aktualisierung des Werts für den Warmdurchsatz ist eine asynchrone Aufgabe. `Status` ändert sich von `UPDATING` in `ACTIVE`, wenn die Aktualisierung abgeschlossen ist.
## AWS CLI
Das folgende AWS CLI Beispiel zeigt Ihnen, wie Sie den Warmdurchsatzwert Ihrer DynamoDB-Tabelle aktualisieren.
1. Führen Sie die `update-table`-Operation für die DynamoDB-Tabelle aus.
```
aws dynamodb update-table \
--table-name GameScores \
--warm-throughput ReadUnitsPerSecond=12345,WriteUnitsPerSecond=4567 \
--global-secondary-index-updates \
"[
{
\"Update\": {
\"IndexName\": \"GameTitleIndex\",
\"WarmThroughput\": {
\"ReadUnitsPerSecond\": 88,
\"WriteUnitsPerSecond\": 77
}
}
}
]" \
--region us-east-1
```
1. Sie erhalten eine ähnliche Antwort wie die folgende. Ihre `WarmThroughput`-Einstellungen werden als `ReadUnitsPerSecond` und `WriteUnitsPerSecond` angezeigt. `Status` lautet `UPDATING`, wenn der Wert für den Warmdurchsatz aktualisiert wird, und `ACTIVE`, wenn der neue Warmdurchsatzwert festgelegt wird.
```
{
"TableDescription": {
"AttributeDefinitions": [
{
"AttributeName": "GameTitle",
"AttributeType": "S"
},
{
"AttributeName": "TopScore",
"AttributeType": "N"
},
{
"AttributeName": "UserId",
"AttributeType": "S"
}
],
"TableName": "GameScores",
"KeySchema": [
{
"AttributeName": "UserId",
"KeyType": "HASH"
},
{
"AttributeName": "GameTitle",
"KeyType": "RANGE"
}
],
"TableStatus": "ACTIVE",
"CreationDateTime": 1730242189.965,
"ProvisionedThroughput": {
"NumberOfDecreasesToday": 0,
"ReadCapacityUnits": 20,
"WriteCapacityUnits": 10
},
"TableSizeBytes": 0,
"ItemCount": 0,
"TableArn": "arn:aws:dynamodb:us-east-1:XXXXXXXXXXXX:table/GameScores",
"TableId": "XXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX",
"GlobalSecondaryIndexes": [
{
"IndexName": "GameTitleIndex",
"KeySchema": [
{
"AttributeName": "GameTitle",
"KeyType": "HASH"
},
{
"AttributeName": "TopScore",
"KeyType": "RANGE"
}
],
"Projection": {
"ProjectionType": "INCLUDE",
"NonKeyAttributes": [
"UserId"
]
},
"IndexStatus": "ACTIVE",
"ProvisionedThroughput": {
"NumberOfDecreasesToday": 0,
"ReadCapacityUnits": 50,
"WriteCapacityUnits": 25
},
"IndexSizeBytes": 0,
"ItemCount": 0,
"IndexArn": "arn:aws:dynamodb:us-east-1:XXXXXXXXXXXX:table/GameScores/index/GameTitleIndex",
"WarmThroughput": {
"ReadUnitsPerSecond": 50,
"WriteUnitsPerSecond": 25,
"Status": "UPDATING"
}
}
],
"DeletionProtectionEnabled": false,
"WarmThroughput": {
"ReadUnitsPerSecond": 12300,
"WriteUnitsPerSecond": 4500,
"Status": "UPDATING"
}
}
}
```
## AWS SDK
Die folgenden SDK-Beispiele zeigen Ihnen, wie Sie den Wert für den Warmdurchsatz Ihrer DynamoDB-Tabelle aktualisieren können.
------
#### [ Java ]
```
import software.amazon.awssdk.services.dynamodb.DynamoDbClient;
import software.amazon.awssdk.services.dynamodb.model.DynamoDbException;
import software.amazon.awssdk.services.dynamodb.model.GlobalSecondaryIndexUpdate;
import software.amazon.awssdk.services.dynamodb.model.UpdateGlobalSecondaryIndexAction;
import software.amazon.awssdk.services.dynamodb.model.UpdateTableRequest;
import software.amazon.awssdk.services.dynamodb.model.WarmThroughput;
...
public static WarmThroughput buildWarmThroughput(final Long readUnitsPerSecond,
final Long writeUnitsPerSecond) {
return WarmThroughput.builder()
.readUnitsPerSecond(readUnitsPerSecond)
.writeUnitsPerSecond(writeUnitsPerSecond)
.build();
}
public static void updateDynamoDBTable(DynamoDbClient ddb,
String tableName,
Long tableReadUnitsPerSecond,
Long tableWriteUnitsPerSecond,
String globalSecondaryIndexName,
Long globalSecondaryIndexReadUnitsPerSecond,
Long globalSecondaryIndexWriteUnitsPerSecond) {
final WarmThroughput tableWarmThroughput = buildWarmThroughput(tableReadUnitsPerSecond, tableWriteUnitsPerSecond);
final WarmThroughput gsiWarmThroughput = buildWarmThroughput(globalSecondaryIndexReadUnitsPerSecond, globalSecondaryIndexWriteUnitsPerSecond);
final GlobalSecondaryIndexUpdate globalSecondaryIndexUpdate = GlobalSecondaryIndexUpdate.builder()
.update(UpdateGlobalSecondaryIndexAction.builder()
.indexName(globalSecondaryIndexName)
.warmThroughput(gsiWarmThroughput)
.build()
).build();
final UpdateTableRequest request = UpdateTableRequest.builder()
.tableName(tableName)
.globalSecondaryIndexUpdates(globalSecondaryIndexUpdate)
.warmThroughput(tableWarmThroughput)
.build();
try {
ddb.updateTable(request);
} catch (DynamoDbException e) {
System.err.println(e.getMessage());
System.exit(1);
}
System.out.println("Done!");
}
```
------
#### [ Python ]
```
from boto3 import resource
from botocore.exceptions import ClientError
def update_dynamodb_table_warm_throughput(table_name, table_read_units, table_write_units, gsi_name, gsi_read_units, gsi_write_units, region_name="us-east-1"):
"""
Updates the warm throughput of a DynamoDB table and a global secondary index.
:param table_name: The name of the table to update.
:param table_read_units: The new read units per second for the table's warm throughput.
:param table_write_units: The new write units per second for the table's warm throughput.
:param gsi_name: The name of the global secondary index to update.
:param gsi_read_units: The new read units per second for the GSI's warm throughput.
:param gsi_write_units: The new write units per second for the GSI's warm throughput.
:param region_name: The AWS Region name to target. defaults to us-east-1
"""
try:
ddb = resource('dynamodb', region_name)
# Update the table's warm throughput
table_warm_throughput = {
"ReadUnitsPerSecond": table_read_units,
"WriteUnitsPerSecond": table_write_units
}
# Update the global secondary index's warm throughput
gsi_warm_throughput = {
"ReadUnitsPerSecond": gsi_read_units,
"WriteUnitsPerSecond": gsi_write_units
}
# Construct the global secondary index update
global_secondary_index_update = [
{
"Update": {
"IndexName": gsi_name,
"WarmThroughput": gsi_warm_throughput
}
}
]
# Construct the update table request
update_table_request = {
"TableName": table_name,
"GlobalSecondaryIndexUpdates": global_secondary_index_update,
"WarmThroughput": table_warm_throughput
}
# Update the table
ddb.update_table(**update_table_request)
print("Table updated successfully!")
except ClientError as e:
print(f"Error updating table: {e}")
raise e
```
------
#### [ Javascript ]
```
import { DynamoDBClient, UpdateTableCommand } from "@aws-sdk/client-dynamodb";
async function updateDynamoDBTableWarmThroughput(
tableName,
tableReadUnits,
tableWriteUnits,
gsiName,
gsiReadUnits,
gsiWriteUnits,
region = "us-east-1"
) {
try {
const ddbClient = new DynamoDBClient({ region: region });
// Construct the update table request
const updateTableRequest = {
TableName: tableName,
GlobalSecondaryIndexUpdates: [
{
Update: {
IndexName: gsiName,
WarmThroughput: {
ReadUnitsPerSecond: gsiReadUnits,
WriteUnitsPerSecond: gsiWriteUnits,
},
},
},
],
WarmThroughput: {
ReadUnitsPerSecond: tableReadUnits,
WriteUnitsPerSecond: tableWriteUnits,
},
};
const command = new UpdateTableCommand(updateTableRequest);
const response = await ddbClient.send(command);
console.log(`Table updated successfully! Response: ${response}`);
} catch (error) {
console.error(`Error updating table: ${error}`);
throw error;
}
}
```
------
# Erstellen einer neuen DynamoDB-Tabelle mit einem höheren Warmdurchsatz
Sie können die Werte für den Warmdurchsatz beim Erstellen Ihrer DynamoDB-Tabelle anpassen, indem Sie die folgenden Schritte ausführen. Diese Schritte gelten auch für die Erstellung einer [globalen Tabelle](GlobalTables.md) oder eines [sekundären Index](SecondaryIndexes.md).
## AWS-Managementkonsole
So erstellen Sie eine DynamoDB-Tabelle und passen die Werte für den Warmdurchsatz über die Konsole an:
1. Melden Sie sich bei der an AWS-Managementkonsole und öffnen Sie die DynamoDB-Konsole unter. [https://console.aws.amazon.com/dynamodb/](https://console.aws.amazon.com/dynamodb/)
1. Wählen Sie **Tabelle erstellen** aus.
1. Wählen Sie einen **Tabellennamen**, einen **Partitionsschlüssel** und einen **Sortierschlüssel (optional)** aus.
1. Wählen Sie unter **Tabelleneinstellungen** die Option **Einstellungen anpassen** aus.
1. Wählen Sie im Feld **Warmdurchsatz** die Option **Warmdurchsatz erhöhen** aus.
1. Passen Sie die **Leseeinheiten pro Sekunde** und die **Schreibeinheiten pro Sekunde** an. Diese beiden Einstellungen definieren den maximalen Durchsatz, den die Tabelle sofort verarbeiten kann.
1. Fügen Sie weitere Tabellendetails hinzu und wählen Sie dann **Tabelle erstellen** aus.
## AWS CLI
Das folgende AWS CLI Beispiel zeigt Ihnen, wie Sie eine DynamoDB-Tabelle mit benutzerdefinierten Warmdurchsatzwerten erstellen.
1. Führen Sie die `create-table`-Operation aus, um die folgende DynamoDB-Tabelle zu erstellen.
```
aws dynamodb create-table \
--table-name GameScores \
--attribute-definitions AttributeName=UserId,AttributeType=S \
AttributeName=GameTitle,AttributeType=S \
AttributeName=TopScore,AttributeType=N \
--key-schema AttributeName=UserId,KeyType=HASH \
AttributeName=GameTitle,KeyType=RANGE \
--provisioned-throughput ReadCapacityUnits=20,WriteCapacityUnits=10 \
--global-secondary-indexes \
"[
{
\"IndexName\": \"GameTitleIndex\",
\"KeySchema\": [{\"AttributeName\":\"GameTitle\",\"KeyType\":\"HASH\"},
{\"AttributeName\":\"TopScore\",\"KeyType\":\"RANGE\"}],
\"Projection\":{
\"ProjectionType\":\"INCLUDE\",
\"NonKeyAttributes\":[\"UserId\"]
},
\"ProvisionedThroughput\": {
\"ReadCapacityUnits\": 50,
\"WriteCapacityUnits\": 25
},\"WarmThroughput\": {
\"ReadUnitsPerSecond\": 1987,
\"WriteUnitsPerSecond\": 543
}
}
]" \
--warm-throughput ReadUnitsPerSecond=12345,WriteUnitsPerSecond=4567 \
--region us-east-1
```
1. Sie erhalten eine ähnliche Antwort wie die folgende. Ihre `WarmThroughput`-Einstellungen werden als `ReadUnitsPerSecond` und `WriteUnitsPerSecond` angezeigt. `Status` lautet `UPDATING`, wenn der Wert für den Warmdurchsatz aktualisiert wird, und `ACTIVE`, wenn der neue Warmdurchsatzwert festgelegt wird.
```
{
"TableDescription": {
"AttributeDefinitions": [
{
"AttributeName": "GameTitle",
"AttributeType": "S"
},
{
"AttributeName": "TopScore",
"AttributeType": "N"
},
{
"AttributeName": "UserId",
"AttributeType": "S"
}
],
"TableName": "GameScores",
"KeySchema": [
{
"AttributeName": "UserId",
"KeyType": "HASH"
},
{
"AttributeName": "GameTitle",
"KeyType": "RANGE"
}
],
"TableStatus": "CREATING",
"CreationDateTime": 1730241788.779,
"ProvisionedThroughput": {
"NumberOfDecreasesToday": 0,
"ReadCapacityUnits": 20,
"WriteCapacityUnits": 10
},
"TableSizeBytes": 0,
"ItemCount": 0,
"TableArn": "arn:aws:dynamodb:us-east-1:XXXXXXXXXXXX:table/GameScores",
"TableId": "XXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX",
"GlobalSecondaryIndexes": [
{
"IndexName": "GameTitleIndex",
"KeySchema": [
{
"AttributeName": "GameTitle",
"KeyType": "HASH"
},
{
"AttributeName": "TopScore",
"KeyType": "RANGE"
}
],
"Projection": {
"ProjectionType": "INCLUDE",
"NonKeyAttributes": [
"UserId"
]
},
"IndexStatus": "CREATING",
"ProvisionedThroughput": {
"NumberOfDecreasesToday": 0,
"ReadCapacityUnits": 50,
"WriteCapacityUnits": 25
},
"IndexSizeBytes": 0,
"ItemCount": 0,
"IndexArn": "arn:aws:dynamodb:us-east-1:XXXXXXXXXXXX:table/GameScores/index/GameTitleIndex",
"WarmThroughput": {
"ReadUnitsPerSecond": 1987,
"WriteUnitsPerSecond": 543,
"Status": "UPDATING"
}
}
],
"DeletionProtectionEnabled": false,
"WarmThroughput": {
"ReadUnitsPerSecond": 12345,
"WriteUnitsPerSecond": 4567,
"Status": "UPDATING"
}
}
}
```
## AWS SDK
Die folgenden SDK-Beispiele zeigen Ihnen, wie Sie eine DynamoDB-Tabelle mit benutzerdefinierten Werden für den Warmdurchsatz erstellen.
------
#### [ Java ]
```
import software.amazon.awscdk.services.dynamodb.ProjectionType;
import software.amazon.awssdk.services.dynamodb.DynamoDbClient;
import software.amazon.awssdk.services.dynamodb.model.CreateTableResponse;
import software.amazon.awssdk.services.dynamodb.model.CreateTableRequest;
import software.amazon.awssdk.services.dynamodb.model.KeySchemaElement;
import software.amazon.awssdk.services.dynamodb.model.KeyType;
import software.amazon.awssdk.services.dynamodb.model.ProvisionedThroughput;
import software.amazon.awssdk.services.dynamodb.model.Projection;
import software.amazon.awssdk.services.dynamodb.model.GlobalSecondaryIndex;
import software.amazon.awssdk.services.dynamodb.model.AttributeDefinition;
import software.amazon.awssdk.services.dynamodb.model.ScalarAttributeType;
import software.amazon.awssdk.services.dynamodb.model.WarmThroughput;
...
public static WarmThroughput buildWarmThroughput(final Long readUnitsPerSecond,
final Long writeUnitsPerSecond) {
return WarmThroughput.builder()
.readUnitsPerSecond(readUnitsPerSecond)
.writeUnitsPerSecond(writeUnitsPerSecond)
.build();
}
private static AttributeDefinition buildAttributeDefinition(final String attributeName,
final ScalarAttributeType scalarAttributeType) {
return AttributeDefinition.builder()
.attributeName(attributeName)
.attributeType(scalarAttributeType)
.build();
}
private static KeySchemaElement buildKeySchemaElement(final String attributeName,
final KeyType keyType) {
return KeySchemaElement.builder()
.attributeName(attributeName)
.keyType(keyType)
.build();
}
public static void createDynamoDBTable(DynamoDbClient ddb,
String tableName,
String partitionKey,
String sortKey,
String miscellaneousKeyAttribute,
String nonKeyAttribute,
Long tableReadCapacityUnits,
Long tableWriteCapacityUnits,
Long tableWarmReadUnitsPerSecond,
Long tableWarmWriteUnitsPerSecond,
String globalSecondaryIndexName,
Long globalSecondaryIndexReadCapacityUnits,
Long globalSecondaryIndexWriteCapacityUnits,
Long globalSecondaryIndexWarmReadUnitsPerSecond,
Long globalSecondaryIndexWarmWriteUnitsPerSecond) {
// Define the table attributes
final AttributeDefinition partitionKeyAttribute = buildAttributeDefinition(partitionKey, ScalarAttributeType.S);
final AttributeDefinition sortKeyAttribute = buildAttributeDefinition(sortKey, ScalarAttributeType.S);
final AttributeDefinition miscellaneousKeyAttributeDefinition = buildAttributeDefinition(miscellaneousKeyAttribute, ScalarAttributeType.N);
final AttributeDefinition[] attributeDefinitions = {partitionKeyAttribute, sortKeyAttribute, miscellaneousKeyAttributeDefinition};
// Define the table key schema
final KeySchemaElement partitionKeyElement = buildKeySchemaElement(partitionKey, KeyType.HASH);
final KeySchemaElement sortKeyElement = buildKeySchemaElement(sortKey, KeyType.RANGE);
final KeySchemaElement[] keySchema = {partitionKeyElement, sortKeyElement};
// Define the provisioned throughput for the table
final ProvisionedThroughput provisionedThroughput = ProvisionedThroughput.builder()
.readCapacityUnits(tableReadCapacityUnits)
.writeCapacityUnits(tableWriteCapacityUnits)
.build();
// Define the Global Secondary Index (GSI)
final KeySchemaElement globalSecondaryIndexPartitionKeyElement = buildKeySchemaElement(sortKey, KeyType.HASH);
final KeySchemaElement globalSecondaryIndexSortKeyElement = buildKeySchemaElement(miscellaneousKeyAttribute, KeyType.RANGE);
final KeySchemaElement[] gsiKeySchema = {globalSecondaryIndexPartitionKeyElement, globalSecondaryIndexSortKeyElement};
final Projection gsiProjection = Projection.builder()
.projectionType(String.valueOf(ProjectionType.INCLUDE))
.nonKeyAttributes(nonKeyAttribute)
.build();
final ProvisionedThroughput gsiProvisionedThroughput = ProvisionedThroughput.builder()
.readCapacityUnits(globalSecondaryIndexReadCapacityUnits)
.writeCapacityUnits(globalSecondaryIndexWriteCapacityUnits)
.build();
// Define the warm throughput for the Global Secondary Index (GSI)
final WarmThroughput gsiWarmThroughput = buildWarmThroughput(globalSecondaryIndexWarmReadUnitsPerSecond, globalSecondaryIndexWarmWriteUnitsPerSecond);
final GlobalSecondaryIndex globalSecondaryIndex = GlobalSecondaryIndex.builder()
.indexName(globalSecondaryIndexName)
.keySchema(gsiKeySchema)
.projection(gsiProjection)
.provisionedThroughput(gsiProvisionedThroughput)
.warmThroughput(gsiWarmThroughput)
.build();
// Define the warm throughput for the table
final WarmThroughput tableWarmThroughput = buildWarmThroughput(tableWarmReadUnitsPerSecond, tableWarmWriteUnitsPerSecond);
final CreateTableRequest request = CreateTableRequest.builder()
.tableName(tableName)
.attributeDefinitions(attributeDefinitions)
.keySchema(keySchema)
.provisionedThroughput(provisionedThroughput)
.globalSecondaryIndexes(globalSecondaryIndex)
.warmThroughput(tableWarmThroughput)
.build();
CreateTableResponse response = ddb.createTable(request);
System.out.println(response);
}
```
------
#### [ Python ]
```
from boto3 import resource
from botocore.exceptions import ClientError
def create_dynamodb_table_warm_throughput(table_name, partition_key, sort_key, misc_key_attr, non_key_attr, table_provisioned_read_units, table_provisioned_write_units, table_warm_reads, table_warm_writes, gsi_name, gsi_provisioned_read_units, gsi_provisioned_write_units, gsi_warm_reads, gsi_warm_writes, region_name="us-east-1"):
"""
Creates a DynamoDB table with a warm throughput setting configured.
:param table_name: The name of the table to be created.
:param partition_key: The partition key for the table being created.
:param sort_key: The sort key for the table being created.
:param misc_key_attr: A miscellaneous key attribute for the table being created.
:param non_key_attr: A non-key attribute for the table being created.
:param table_provisioned_read_units: The newly created table's provisioned read capacity units.
:param table_provisioned_write_units: The newly created table's provisioned write capacity units.
:param table_warm_reads: The read units per second setting for the table's warm throughput.
:param table_warm_writes: The write units per second setting for the table's warm throughput.
:param gsi_name: The name of the Global Secondary Index (GSI) to be created on the table.
:param gsi_provisioned_read_units: The configured Global Secondary Index (GSI) provisioned read capacity units.
:param gsi_provisioned_write_units: The configured Global Secondary Index (GSI) provisioned write capacity units.
:param gsi_warm_reads: The read units per second setting for the Global Secondary Index (GSI)'s warm throughput.
:param gsi_warm_writes: The write units per second setting for the Global Secondary Index (GSI)'s warm throughput.
:param region_name: The AWS Region name to target. defaults to us-east-1
"""
try:
ddb = resource('dynamodb', region_name)
# Define the table attributes
attribute_definitions = [
{ "AttributeName": partition_key, "AttributeType": "S" },
{ "AttributeName": sort_key, "AttributeType": "S" },
{ "AttributeName": misc_key_attr, "AttributeType": "N" }
]
# Define the table key schema
key_schema = [
{ "AttributeName": partition_key, "KeyType": "HASH" },
{ "AttributeName": sort_key, "KeyType": "RANGE" }
]
# Define the provisioned throughput for the table
provisioned_throughput = {
"ReadCapacityUnits": table_provisioned_read_units,
"WriteCapacityUnits": table_provisioned_write_units
}
# Define the global secondary index
gsi_key_schema = [
{ "AttributeName": sort_key, "KeyType": "HASH" },
{ "AttributeName": misc_key_attr, "KeyType": "RANGE" }
]
gsi_projection = {
"ProjectionType": "INCLUDE",
"NonKeyAttributes": [non_key_attr]
}
gsi_provisioned_throughput = {
"ReadCapacityUnits": gsi_provisioned_read_units,
"WriteCapacityUnits": gsi_provisioned_write_units
}
gsi_warm_throughput = {
"ReadUnitsPerSecond": gsi_warm_reads,
"WriteUnitsPerSecond": gsi_warm_writes
}
global_secondary_indexes = [
{
"IndexName": gsi_name,
"KeySchema": gsi_key_schema,
"Projection": gsi_projection,
"ProvisionedThroughput": gsi_provisioned_throughput,
"WarmThroughput": gsi_warm_throughput
}
]
# Define the warm throughput for the table
warm_throughput = {
"ReadUnitsPerSecond": table_warm_reads,
"WriteUnitsPerSecond": table_warm_writes
}
# Create the DynamoDB client and create the table
response = ddb.create_table(
TableName=table_name,
AttributeDefinitions=attribute_definitions,
KeySchema=key_schema,
ProvisionedThroughput=provisioned_throughput,
GlobalSecondaryIndexes=global_secondary_indexes,
WarmThroughput=warm_throughput
)
print(response)
except ClientError as e:
print(f"Error creating table: {e}")
raise e
```
------
#### [ Javascript ]
```
import { DynamoDBClient, CreateTableCommand } from "@aws-sdk/client-dynamodb";
async function createDynamoDBTableWithWarmThroughput(
tableName,
partitionKey,
sortKey,
miscKeyAttr,
nonKeyAttr,
tableProvisionedReadUnits,
tableProvisionedWriteUnits,
tableWarmReads,
tableWarmWrites,
indexName,
indexProvisionedReadUnits,
indexProvisionedWriteUnits,
indexWarmReads,
indexWarmWrites,
region = "us-east-1"
) {
try {
const ddbClient = new DynamoDBClient({ region: region });
const command = new CreateTableCommand({
TableName: tableName,
AttributeDefinitions: [
{ AttributeName: partitionKey, AttributeType: "S" },
{ AttributeName: sortKey, AttributeType: "S" },
{ AttributeName: miscKeyAttr, AttributeType: "N" },
],
KeySchema: [
{ AttributeName: partitionKey, KeyType: "HASH" },
{ AttributeName: sortKey, KeyType: "RANGE" },
],
ProvisionedThroughput: {
ReadCapacityUnits: tableProvisionedReadUnits,
WriteCapacityUnits: tableProvisionedWriteUnits,
},
WarmThroughput: {
ReadUnitsPerSecond: tableWarmReads,
WriteUnitsPerSecond: tableWarmWrites,
},
GlobalSecondaryIndexes: [
{
IndexName: indexName,
KeySchema: [
{ AttributeName: sortKey, KeyType: "HASH" },
{ AttributeName: miscKeyAttr, KeyType: "RANGE" },
],
Projection: {
ProjectionType: "INCLUDE",
NonKeyAttributes: [nonKeyAttr],
},
ProvisionedThroughput: {
ReadCapacityUnits: indexProvisionedReadUnits,
WriteCapacityUnits: indexProvisionedWriteUnits,
},
WarmThroughput: {
ReadUnitsPerSecond: indexWarmReads,
WriteUnitsPerSecond: indexWarmWrites,
},
},
],
});
const response = await ddbClient.send(command);
console.log(response);
} catch (error) {
console.error(`Error creating table: ${error}`);
throw error;
}
}
```
------
# Grundlegendes zum DynamoDB-Warmdurchsatz in verschiedenen Szenarien
Im Folgenden finden Sie verschiedene Szenarien, die Ihnen bei der Arbeit mit DynamoDB-Warmdurchsatz begegnen können.
**Topics**
+ [Warmdurchsatz und ungleiche Zugriffsmuster](#warm-throughput-scenarios-uneven)
+ [Warmdurchsatz für eine bereitgestellte Tabelle](#warm-throughput-scenarios-provisioned)
+ [Warmdurchsatz für eine On-Demand-Tabelle](#warm-throughput-scenarios-ondemand)
+ [Warmdurchsatz für eine On-Demand-Tabelle mit konfiguriertem maximalem Durchsatz](#warm-throughput-scenarios-max)
## Warmdurchsatz und ungleiche Zugriffsmuster
Auch wenn eine Tabelle einen Warmdurchsatz von 30 000 Leseeinheiten pro Sekunde und 10 000 Schreibeinheiten pro Sekunde hat, kann es dennoch zu Drosselungen bei Lese- oder Schreibvorgängen kommen, bevor diese Werte erreicht werden. Das liegt wahrscheinlich an einer Hot-Partition. DynamoDB kann zwar weiter skaliert werden, um einen praktisch unbegrenzten Durchsatz zu unterstützen, aber jede einzelne Partition ist auf 1 000 Schreibeinheiten pro Sekunde und 3 000 Leseeinheiten pro Sekunde begrenzt. Wenn Ihre Anwendung zu viel Datenverkehr auf einen kleinen Teil der Tabellenpartitionen lenkt, kann es zu einer Drosselung kommen, noch bevor Sie die Werte für den Warmdurchsatz der Tabelle erreichen. Wir empfehlen, die [bewährten Methoden für DynamoDB](bp-partition-key-design.md) zu befolgen, um eine nahtlose Skalierbarkeit zu gewährleisten und Hot-Partitionen zu vermeiden.
## Warmdurchsatz für eine bereitgestellte Tabelle
Stellen Sie sich eine bereitgestellte Tabelle mit einem Warmdurchsatz von 30 000 Leseeinheiten pro Sekunde und 10 000 Schreibeinheiten pro Sekunde vor, die derzeit jedoch über einen bereitgestellten Durchsatz von 4 000 RCU und 8 000 WCU verfügt. Sie können den bereitgestellten Durchsatz der Tabelle sofort auf bis zu 30 000 RCU oder 10 000 WCU skalieren, indem Sie Ihre Einstellungen für den bereitgestellten Durchsatz aktualisieren. Wenn Sie den bereitgestellten Durchsatz über diese Werte hinaus erhöhen, passt sich der Warmdurchsatz automatisch an die neuen höheren Werte an, da Sie einen neuen Spitzendurchsatz festgelegt haben. Wenn Sie beispielsweise den bereitgestellten Durchsatz auf 50 000 RCU festlegen, erhöht sich der Warmdurchsatz auf 50 000 Leseeinheiten pro Sekunde.
```
"ProvisionedThroughput":
{
"ReadCapacityUnits": 4000,
"WriteCapacityUnits": 8000
}
"WarmThroughput":
{
"ReadUnitsPerSecond": 30000,
"WriteUnitsPerSecond": 10000
}
```
## Warmdurchsatz für eine On-Demand-Tabelle
Eine neue On-Demand-Tabelle beginnt mit einem Warmdurchsatz von 12 000 Leseeinheiten pro Sekunde und 4 000 Schreibeinheiten pro Sekunde. Ihre Tabelle kann anhaltenden Datenverkehr bis zu diesen Werten sofort verarbeiten. Wenn Ihre Anforderungen 12 000 Leseeinheiten pro Sekunde oder 4 000 Schreibeinheiten pro Sekunde überschreiten, passt sich der Warmdurchsatz automatisch an höhere Werte an.
```
"WarmThroughput":
{
"ReadUnitsPerSecond": 12000,
"WriteUnitsPerSecond": 4000
}
```
## Warmdurchsatz für eine On-Demand-Tabelle mit konfiguriertem maximalem Durchsatz
Stellen Sie sich eine On-Demand-Tabelle mit einem Warmdurchsatz von 30 000 Leseeinheiten pro Sekunde vor, für die der [maximale Durchsatz](on-demand-capacity-mode-max-throughput.md) jedoch auf 5 000 Leseanforderungseinheiten (RRU) konfiguriert ist. In diesem Szenario wird der Durchsatz der Tabelle auf das von Ihnen festgelegte Maximum von 5 000 RRU begrenzt. Alle Durchsatzanforderungen, die diesen Höchstwert überschreiten, werden gedrosselt. Sie können den tabellenspezifischen maximalen Durchsatz jedoch jederzeit an die Anforderungen Ihrer Anwendung anpassen.
```
"OnDemandThroughput":
{
"MaxReadRequestUnits": 5000,
"MaxWriteRequestUnits": 4000
}
"WarmThroughput":
{
"ReadUnitsPerSecond": 30000,
"WriteUnitsPerSecond": 10000
}
```
# DynamoDB – Burst- und adaptive Kapazität
Um die Drosselung aufgrund von Durchsatzausnahmen zu minimieren, verwendet DynamoDB die *Burst-Kapazität*, um Nutzungsspitzen zu bewältigen. DynamoDB nutzt die *adaptive Kapazität*, um ungleichen Zugriffsmustern gerecht zu werden.
## Burst-Kapazität
DynamoDB bietet eine gewisse Flexibilität bei der Bereitstellung des Durchsatzes pro Partition durch Bereitstellung von *Burst-Kapazität*. Wenn Sie den verfügbaren Durchsatz nicht vollständig nutzen, reserviert DynamoDB einen Teil dieser ungenutzten Kapazität für spätere Durchsatz-*Bursts*, um Nutzungsspitzen zu bewältigen. Mit Burst-Kapazität können unerwartete Lese- oder Schreibanforderungen erfolgreich sein, wo sie andernfalls gedrosselt werden würden.
DynamoDB behält derzeit bis zu fünf Minuten (300 Sekunden) ungenutzte Lese- und Schreibkapazität bei. Während eines gelegentlichen Bursts von Lese- oder Schreibaktivitäten können diese zusätzlichen Kapazitätseinheiten schnell verbraucht werden – sogar schneller als die pro Sekunde bereitgestellte Durchsatzkapazität, die Sie für Ihre Tabelle definiert haben.
Zudem kann DynamoDB die Burst-Kapazität für Wartungsaktivitäten im Hintergrund sowie für andere Aufgaben verbrauchen, ohne Sie vorher zu informieren.
Beachten Sie, dass die Burst-Kapazität in Zukunft geändert werden kann.
## Adaptive Kapazität
DynamoDB verteilt Ihre Daten automatisch auf alle [Partitionen](HowItWorks.Partitions.md), die auf mehreren Servern in der AWS Cloud gespeichert werden. Es ist nicht immer möglich, die Lese- und Schreibaktivität jederzeit gleichmäßig zu verteilen. Wenn der Datenzugriff nicht ausgeglichen ist, kann es sein, dass eine „Hot Partition” mehr Lese- und Schreibdatenvolumen erhält als andere Partitionen. Da Lese- und Schreibvorgänge auf einer Partition unabhängig verwaltet werden, tritt eine Drosselung auf, wenn eine einzelne Partition mehr als 3 000 Lesevorgänge oder mehr als 1 000 Schreibvorgänge empfängt. Adaptive Kapazität funktioniert durch automatische Erhöhung der Durchsatzkapazität für Partitionen, die mehr Datenverkehr erhalten.
Um ungleichmäßigen Zugriffsmustern besser gerecht zu werden, ermöglicht die adaptive Kapazität von DynamoDB Ihrer Anwendung, weiterhin zu lesen und auf Hot-Partitionen zu schreiben, ohne gedrosselt zu werden, vorausgesetzt, dass der Datenverkehr die gesamte bereitgestellte Kapazität Ihrer Tabelle oder die maximale Partitionskapazität nicht überschreitet. Die adaptive Kapazität funktioniert durch automatische und sofortige Erhöhung der Durchsatzkapazität für Partitionen, die mehr Datenverkehr erhalten.
Das folgende Diagramm veranschaulicht, wie adaptive Kapazität funktioniert. Die Beispieltabelle enthält 400 Partitionen, die WCUs gleichmäßig auf vier Partitionen verteilt werden, sodass jede Partition bis zu 100 Partitionen WCUs pro Sekunde verwalten kann. Die Partitionen 1, 2 und 3 erhalten jeweils einen Schreibverkehr von 50. WCU/sec. Partition 4 receives 150 WCU/sec. This hot partition can accept write traffic while it still has unused burst capacity, but eventually it throttles traffic that exceeds 100 WCU/sec
DynamoDB Adaptive Capacity reagiert darauf, indem die Kapazität von Partition 4 erhöht wird, sodass sie die höhere Arbeitslast von 150 bewältigen kann, WCU/sec ohne gedrosselt zu werden.
![\[Die adaptive Kapazität erhöht automatisch den Durchsatz für Partition 4 mit höherem Datenverkehr, um eine Drosselung zu vermeiden.\]](http://docs.aws.amazon.com/de_de/amazondynamodb/latest/developerguide/images/adaptive-capacity.png)
Die adaptive Kapazität wird für jede DynamoDB-Tabelle ohne zusätzliche Kosten automatisch aktiviert. Die adaptive Kapazität muss nicht ausdrücklich aktiviert oder deaktiviert werden.
### Isolieren von Elementen mit häufigen Zugriffen
Wenn eine Anwendung unverhältnismäßig viel Datenverkehr an einzelne oder mehrere Elemente leitet, gleicht die Funktion für adaptive Kapazität die Partitionen so aus, dass häufig aufgerufene Elemente nicht in derselben Partition abgelegt werden. Durch das Isolieren von Elementen, auf die häufig zugegriffen wird, wird die Wahrscheinlichkeit einer Anforderungsdrosselung aufgrund eines Workloads, der das Durchsatzkontingent für eine einzelne Partition überschreitet, reduziert. Sie können eine Sammlung von Elementen auch nach Sortierschlüssel in Segmente aufteilen, sofern es sich bei der Sammlung nicht um Datenverkehr handelt, der durch eine monotone Erhöhung oder Verringerung des Sortierschlüssels verfolgt wird.
Wenn die Anwendung dauernd Datenverkehr in großem Umfang an ein einzelnes Element leitet, gleicht die Funktion für die adaptive Kapazität die Daten so aus, dass eine Partition nur ein einzelnes Element enthält, auf das häufig zugegriffen wird. In diesem Fall kann DynamoDB einen Durchsatz bis zum Partitionsmaximum von 3.000 RCUs und 1.000 für WCUs den Primärschlüssel dieses einzelnen Elements bereitstellen. Die adaptive Kapazität teilt Elementsammlungen nicht auf mehrere Partitionen der Tabelle auf, wenn ein [lokaler sekundärer Index](LSI.md) in der Tabelle enthalten ist.
# Überlegungen beim Umstellen der Kapazitätsmodi in DynamoDB
Beim Erstellen einer DynamoDB-Tabelle müssen Sie entweder den On-Demand-Kapazitätsmodus oder den Modus bereitgestellter Kapazität auswählen.
Sie können Tabellen innerhalb eines fortlaufenden 24-stündigen Zeitfensters bis zu viermal vom Modus mit bereitgestellter Kapazität auf den On-Demand-Modus umstellen. Sie können Tabellen jederzeit vom On-Demand-Modus auf den Modus mit bereitgestellter Kapazität umstellen.
**Topics**
+ [Umstellen vom Modus bereitgestellter Kapazität auf den On-Demand-Kapazitätsmodus](#switch-provisioned-to-ondemand)
+ [Umstellen vom On-Demand-Kapazitätsmodus auf den Modus bereitgestellter Kapazität](#switch-ondemand-to-provisioned)
## Umstellen vom Modus bereitgestellter Kapazität auf den On-Demand-Kapazitätsmodus
Im Modus bereitgestellter Kapazität legen Sie die Lese- und Schreibkapazität basierend auf den erwarteten Anwendungsanforderungen fest. Wenn Sie eine Tabelle vom Modus bereitgestellter Kapazität auf den On-Demand-Modus aktualisieren, brauchen Sie nicht anzugeben, wie viel Lese- und Schreibdurchsatz Ihre Anwendung erwartungsgemäß durchführen wird. DynamoDB On-Demand bietet eine einfache pay-per-request Preisgestaltung für Lese- und Schreibanforderungen, sodass Sie nur für das bezahlen, was Sie tatsächlich nutzen, sodass Kosten und Leistung leicht in Einklang gebracht werden können. Optional können Sie auch den maximalen Lese- oder Schreibdurchsatz (oder beides) für einzelne On-Demand-Tabellen und zugehörige globale sekundäre Indizes konfigurieren, um Kosten und Nutzung zu begrenzen. Weitere Informationen zum Einstellen des maximalen Durchsatzes für eine bestimmte Tabelle oder einen bestimmten Index finden Sie unter [Maximaler DynamoDB-Durchsatz für On-Demand-Tabellen](on-demand-capacity-mode-max-throughput.md).
Wenn Sie vom Modus bereitgestellter Kapazität auf On-Demand-Kapazitätsmodus umstellen, nimmt DynamoDB mehrere Änderungen an der Struktur der Tabelle und den Partitionen vor. Dieser Vorgang kann einige Minuten dauern. Während der Wechsel vollzogen wird, ist der von der Tabelle gelieferte Durchsatz mit der zuvor bereitgestellten Menge an Schreibkapazitätseinheiten und Lesekapazitätseinheiten konsistent.
### Anfänglicher Durchsatz für den On-Demand-Kapazitätsmodus
Wenn Sie vor Kurzem bei einer vorhandenen Tabelle erstmals zum On-Demand-Kapazitätsmodus gewechselt sind, weist die Tabelle den folgenden vorherigen eingestellten Höchststand auf, obwohl für die Tabelle bisher noch keinen Datenverkehr im On-Demand-Kapazitätsmodus bedient hat.
Im Folgenden finden Sie Beispiele für mögliche Szenarien:
+ **Jede bereitgestellte Tabelle mit einer Konfiguration unter 4 000 WCU und 12 000 RCU, für die noch nie zuvor mehr bereitgestellt wurde.** Wenn Sie diese Tabelle zum ersten Mal auf On-Demand-Modus umstellen, stellt DynamoDB sicher, dass sie so skaliert wird, dass sie sofort mindestens 4.000 Schreib units/sec - und 12.000 Leseeinheiten pro Sekunde unterstützt.
+ **Eine bereitgestellte Tabelle, die als 8.000 WCU und 24.000 RCU konfiguriert ist.** Wenn Sie diese Tabelle auf On-Demand-Modus umstellen, kann sie weiterhin jederzeit mindestens 8.000 Schreibvorgänge units/sec und 24.000 Lesevorgänge verarbeiten. units/sec
+ **Eine bereitgestellte Tabelle, konfiguriert mit 8.000 WCU und 24.000 RCU, die über einen längeren Zeitraum 6.000 Schreibvorgänge units/sec und 18.000 Lesevorgänge beanspruchte. units/sec ** Wenn Sie diese Tabelle auf On-Demand-Modus umstellen, kann sie weiterhin mindestens 8.000 Schreib- und 24.000 Leseeinheiten pro Sekunde verarbeiten. units/sec Der vorherige Datenverkehr kann es der Tabelle außerdem ermöglichen, ein viel höheres Datenverkehrsaufkommen ohne Drosselung zu unterstützen.
+ **Eine Tabelle, die zuvor mit 10 000 WCU und 10 000 RCU bereitgestellt wurde, derzeit jedoch mit 10 RCU und 10 WCU bereitgestellt wird.** Wenn Sie diese Tabelle auf On-Demand-Tabelle umstellen, kann sie mindestens 10.000 Schreib units/sec - und 10.000 Leseeinheiten pro Sekunde verarbeiten.
### Auto-Scaling-Einstellungen
Wenn Sie eine Tabelle vom Modus bereitgestellter Kapazität auf den On-Demand-Modus aktualisieren:
+ Wenn Sie die Konsole verwenden, werden alle Ihre Auto Scaling-Einstellungen (sofern vorhanden) gelöscht.
+ Wenn Sie das AWS SDK AWS CLI oder verwenden, werden alle Ihre Auto Scaling-Einstellungen beibehalten. Diese Einstellungen können übernommen werden, wenn Sie Ihre Tabelle wieder auf den Fakturierungsmodus bereitgestellter Kapazität aktualisieren.
### Massenbearbeitung des Kapazitätsmodus in der [DynamoDB-Konsole](https://console.aws.amazon.com/dynamodb)
Mithilfe der [DynamoDB-Konsole](https://console.aws.amazon.com/dynamodb) können Sie mehrere Tabellen per Massenbearbeitung vom Modus bereitgestellter Kapazität auf den On-Demand-Kapazitätsmodus umstellen. So stellen Sie den Kapazitätsmodus per Massenbearbeitung um:
1. Öffnen Sie die Seite **Tabellen** in der DynamoDB-Konsole.
1. Aktivieren Sie die Kontrollkästchen für die Tabellen, die Sie in den On-Demand-Kapazitätsmodus aktualisieren möchten.
1. Wählen Sie **Aktionen** und dann **Auf On-Demand-Kapazitätsmodus aktualisieren** aus.
Mit diesem Massenvorgang können Sie mehrere Tabellen effizient in den On-Demand-Kapazitätsmodus umstellen, ohne jede Tabelle einzeln aktualisieren zu müssen.
## Umstellen vom On-Demand-Kapazitätsmodus auf den Modus bereitgestellter Kapazität
Wenn vom On-Demand-Kapazitätsmodus zum Modus bereitgestellter Kapazität zurückgewechselt wird, ist der von Ihrer Tabelle gebotene Durchsatz mit dem zuvor erreichten Höchststand konsistent, als für die Tabelle der On-Demand-Modus eingestellt war.
### Verwalten der Kapazität
Berücksichtigen Sie beim Aktualisieren einer Tabelle vom On-Demand-Modus auf den Modus bereitgestellter Kapazität Folgendes:
+ Wenn Sie das AWS SDK AWS CLI oder verwenden, wählen Sie die richtigen Einstellungen für die bereitgestellte Kapazität Ihrer Tabelle und der globalen Sekundärindizes aus, indem Sie Amazon verwenden, CloudWatch um Ihren historischen Verbrauch (`ConsumedWriteCapacityUnits`und Ihre `ConsumedReadCapacityUnits` Kennzahlen) zu überprüfen, um die neuen Durchsatzeinstellungen zu ermitteln.
**Anmerkung**
Wenn Sie eine globale Tabelle in den Modus mit bereitgestellter Kapazität versetzen, zeigen Sie den maximalen Verbrauch für Basistabellen und globale sekundäre Indizes über alle regionalen Replikate hinweg an, wenn Sie die neuen Durchsatzeinstellungen bestimmen.
+ Wenn Sie vom On-Demand-Modus zurück auf den Modus bereitgestellter Kapazität umstellen, achten Sie darauf, dass die anfänglich bereitgestellten Einheiten hoch genug sind, um Ihre Tabellen- oder Indexkapazität während des Übergangs bewältigen zu können.
### Verwalten von Auto Scaling
Wenn Sie eine Tabelle vom On-Demand-Modus auf den Modus bereitgestellter Kapazität aktualisieren:
+ Wenn Sie die Konsole verwenden, empfehlen wir, Auto Scaling mit den folgenden Standardeinstellungen zu aktivieren:
+ Zielauslastung: 70 %
+ Minimal bereitgestellte Kapazität: 5 Einheiten
+ Maximal bereitgestellte Kapazität: Der Höchstwert der Region
+ Wenn Sie das SDK AWS CLI oder verwenden, werden Ihre vorherigen Auto Scaling-Einstellungen (falls vorhanden) beibehalten.