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.
3- Überschreitung der Kontolimits
Für On-Demand-Tabellen gibt es keine bereitgestellten Kapazitätsstufen, die verwaltet werden müssen, aber DynamoDB setzt Durchsatzlimits auf Kontoebene durch, um eine unkontrollierte Ausführung zu verhindern und eine faire Ressourcennutzung für alle Kunden sicherzustellen. Diese Kontolimits pro Tabelle dienen als einstellbare Sicherheitsvorkehrungen, die für jede Kombination aus Konto und Region festgelegt werden. Wenn Ihre Lese- oder Schreibverbrauchsrate diese Grenzwerte überschreitet, gibt DynamoDB in der Drosselungsausnahme den Drosselungsgrund AccountLimitExceeded zurück. Die standardmäßigen Kontolimits pro Tabelle gelten automatisch, wenn für Tabellen keine benutzerdefinierten Einstellungen für den maximalen Durchsatz konfiguriert sind. Sie können optional die Einstellungen für den maximalen Durchsatz konfigurieren, um die Kosten besser kontrollieren und präziser vorhersagen zu können, oder über die Kontingente in Amazon DynamoDB-Konsole Kontingenterhöhungen anfordern, falls Ihre Anwendungsanforderungen die Standardgrenzwerte überschreiten.
Das Kontolimit hat die Abhilfemaßnahmen überschritten
Dieser Abschnitt bietet Anleitungen zur Lösung von Drosselungsszenarien mit Kontolimits. Bevor Sie diese Anleitung verwenden, sollten Sie die spezifischen Drosselungsgründe anhand der Ausnahmebehandlung Ihrer Anwendung identifizieren und den Amazon-Ressourcennamen (ARN) der betroffenen Ressource ermitteln. Informationen dazu, wie Sie die Gründe für die Drosselung abrufen und gedrosselte Ressourcen identifizieren, finden Sie unter Diagnose-Framework für DynamoDB-Drosselungen.
Bevor Sie sich mit bestimmten Drosselungsszenarien befassen, sollten Sie zunächst ermitteln, ob tatsächlich Maßnahmen erforderlich sind:
-
Beurteilen der Auswirkungen auf die Leistung: Überprüfen Sie, ob Ihre Anwendung trotz der Drosselung die Leistungsanforderungen weiter erfüllt. Viele Anwendungen werden erfolgreich an oder nahe den Kontolimits ausgeführt, insbesondere bei Massenoperationen oder Datenmigrationen.
-
Überprüfen der Drosselungsmuster: Wenn die Drosselung nur sporadisch erfolgt und Ihre Anwendung Wiederholversuche effektiv verarbeitet, können die aktuellen Grenzwerte für Ihren Workload ausreichend sein.
Wenn Ihre Anwendung auch bei gelegentlichem Überschreiten der Kontolimits eine akzeptable Leistung erbringt, können Sie die Situation auch einfach überwachen, anstatt unmittelbar Änderungen vorzunehmen.
Wenn Sie feststellen, dass die Drosselung zu inakzeptablen Problemen mit der Leistung oder Zuverlässigkeit führt, wählen Sie unten einen bestimmten Drosselungsgrund aus, um die empfohlenen Abhilfemaßnahmen zu finden:
TableReadAccountLimitExceeded
Wenn dies auftritt
Der Leseverbrauch Ihrer Tabelle hat das Kontingent für den Lesedurchsatz pro Tabelle auf Kontoebene für Ihre Region überschritten. Sie können die CloudWatch Messwerte im Auge behalten, um Ihr Allgemeine Diagnose und Überwachung Drosselungsereignis zu analysieren.
Lösungsansatz
Führen Sie zur Behebung dieser Drosselung die folgenden Schritte aus:
-
Anfordern einer Kontingenterhöhung:
Beantragen Sie eine Erhöhung des Grenzwerts für den Lesedurchsatz pro Tabelle (Quotencode L-CF0). CBE56 Eine ausführliche Anleitung zum Einreichen der Anfrage finden Sie unter Requesting per-table quota increases.
TableWriteAccountLimitExceeded
Wenn dies auftritt
Der Schreibverbrauch Ihrer Tabelle hat das Kontingent für den Schreibdurchsatz pro Tabelle auf Kontoebene für Ihre Region überschritten. Sie können die CloudWatch Messwerte überwachen, um Ihr Allgemeine Diagnose und Überwachung Drosselungsereignis zu analysieren.
Lösungsansatz
Führen Sie zur Behebung dieser Drosselung die folgenden Schritte aus:
-
Erhöhung der Quote anfordern: Fordern Sie eine Erhöhung des Schreibdurchsatzlimits pro Tabelle an (Quotencode L-). AB614373 Eine ausführliche Anleitung zum Einreichen der Anfrage finden Sie unter Requesting per-table quota increases.
IndexReadAccountLimitExceeded
Wenn dies auftritt
Die Leseoperationen, die auf einen globalen sekundären Index (GSI) abzielen, verbrauchen mehr Durchsatz, als das Lesekontingent Ihres Kontos pro Tabelle in Ihrer aktuellen AWS -Region zulässt. Die Quote für den Lesedurchsatz pro Tabelle auf Kontoebene gilt sowohl für eine Tabelle als auch für die gesamte Tabelle zusammen. GSIs Sie können die CloudWatch Messwerte überwachen, um Ihr Allgemeine Diagnose und Überwachung Drosselungsereignis zu analysieren.
Lösungsansatz
Wählen Sie die passende Lösung auf der Grundlage der Kapazitätsverteilung Ihres Kontos:
-
Erhöhung des Kontingents anfordern: Beantragen Sie eine Erhöhung des Grenzwerts für den Lesedurchsatz pro Tabelle (Quotencode L-CF0). CBE56 Eine ausführliche Anleitung zum Einreichen der Anfrage finden Sie unter Requesting per-table quota increases.
-
Optimieren der GSI-Nutzung: Überprüfen Sie das GSI-Design und die Abfragemuster, um unnötigen Lesekapazitätsverbrauch zu reduzieren.
IndexWriteAccountLimitExceeded
Wenn dies auftritt
Schreibvorgänge in Ihre Basistabelle führen zu entsprechenden Aktualisierungen für einen globalen Index, die zusammen die Quote für den Schreibdurchsatz pro Tabelle auf Kontoebene für Ihre Region überschreiten. AWS Jede Schreiboperation in ein Basistabellenelement, das Attribute enthält, die von einem GSI-Trigger indiziert wurden, löst einen entsprechenden Schreibvorgang für diesen GSI aus. Diese kombinierten Schreibvorgänge werden auf Ihr Schreibdurchsatzkontingent pro Tabelle angerechnet. Sie können die CloudWatch Messwerte überwachenAllgemeine Diagnose und Überwachung, um die Muster und den Zeitpunkt dieser Drosselungsereignisse zu analysieren und herauszufinden, welche Operationen die übermäßige GSI-Schreibaktivität verursachen.
Lösungsansatz
Wählen Sie die passende Lösung auf der Grundlage der Kapazitätsverteilung Ihres Kontos:
-
Erhöhung des Anforderungskontingents: Fordern Sie eine Erhöhung des Grenzwerts für den Schreibdurchsatz pro Tabelle (Quotencode L-AB614373) an, um dem höheren GSI-Schreibdatenverkehr aus Basistabellenoperationen Rechnung zu tragen. Das Schreibdurchsatzkontingent pro Tabelle gilt für die gesamte Tabelle, einschließlich aller Tabellen. GSIs Eine ausführliche Anleitung zum Einreichen der Anfrage finden Sie unter Requesting per-table quota increases.
-
Optimieren Sie GSI-Prognosen: Überprüfen Sie die GSI-Prognosen und das Design, um das Schreibvolumen auf zu reduzieren. GSIs
Allgemeine Diagnose und Überwachung
Bei der Fehlerbehebung bei Überschreitung der Drosselung des Kontolimits können Sie anhand verschiedener CloudWatch Kennzahlen ermitteln, ob Sie die Grenzen pro Tabelle oder für das gesamte Konto überschreiten, und Ihre Kapazitätsverteilungsmuster besser nachvollziehen.
CloudWatch Wesentliche Messwerte
Überwachen Sie diese wichtigen Kennzahlen, um die Drosselung von Kontolimits zu diagnostizieren:
-
Drosselungsereignisse auf Kontoebene:
ReadAccountLimitThrottleEventsundWriteAccountLimitThrottleEventsverfolgen, wann Anforderungen aufgrund von Limits auf Kontoebene gedrosselt werden.ReadThrottleEventsundWriteThrottleEventsverfolgen, wann Lese- oder Schreibanforderungen die bereitgestellte Kapazität überschreiten. -
Kapazitätsverbrauch nach Ressource:
ConsumedReadCapacityUnitsundConsumedWriteCapacityUnitsfür jede Tabelle und jeden GSI zeigen die individuelle Ressourcennutzung an. -
Kontoweiter Verbrauch: Verwenden Sie CloudWatch metrische mathematische Ausdrücke, um die verbrauchte Kapazität in allen Tabellen zu summieren und GSIs die gesamte Kontonutzung zu überwachen.
Fehlerbehebung
Anfordern einer Kontingenterhöhung pro Tabelle
Wenn Ihre Anwendungen aus operativen Gründen die aktuellen Durchsatzlimits pro Tabelle überschreiten müssen, sollten Sie mit dem unten beschriebenen Verfahren eine Erhöhung des Kontingents beantragen. Jede DynamoDB-Tabelle in Ihrem AWS Konto (zusammen mit allen zugehörigen Tabellen GSIs) unterliegt diesen Durchsatzquoten innerhalb einer bestimmten Region. Diese Kontingente stellen die maximale Lese- oder Schreibkapazität dar, die eine einzelne Tabelle zusammen verbrauchen GSIs kann, und sie gelten unabhängig für jede Tabelle und nicht als Summe für alle Tabellen in Ihrem Konto.
Optional können Sie auch niedrigere Limits pro Tabelle oder GSI festlegen, indem Sie deren Einstellungen für den maximalen On-Demand-Durchsatz konfigurieren.
-
Identifizieren Sie das spezifische Kontingent, das erhöht werden muss:
-
Limit für den Lesedurchsatz pro Tabelle (Quotencode L-CF0CBE56): Standardmäßig 40.000 pro Tabelle RCUs
-
Grenzwert für den Schreibdurchsatz pro Tabelle (Quota-Code L-AB614373): Standardmäßig 40.000 pro Tabelle WCUs
-
-
Verwenden Sie zum Anfordern einer Erhöhung die AWS -Konsole für Service Quotas.
-
Navigieren Sie in Service Quotas zum DynamoDB-Service.
-
Suchen Sie mithilfe des Kontingentcodes nach dem entsprechenden Kontingent.
-
Fordern Sie eine Erhöhung auf der Grundlage Ihrer voraussichtlichen Spitzennutzung an.
-
-
Begründen Sie die Erhöhung, einschließlich folgender Informationen:
-
Aktuelle Nutzungsmuster und Anforderungen an den Spitzenverkehr
-
Geschäftliche Begründung für die Kapazitätserhöhung
-
Zeitplan für den Zeitpunkt, zu dem die erhöhte Kapazität benötigt wird
-
Anmerkung
Die Bearbeitung von Kontingenterhöhungen nimmt in der Regel 24 bis 48 Stunden in Anspruch. Planen Sie Ihre Anforderungen entsprechend und ziehen Sie vorübergehende Abhilfemaßnahmen in Betracht, während Sie auf die Genehmigung warten.
Optimieren von GSI-Projektionen und -Design
Optimieren Sie Ihre GSI-Projektionen und das Design, um den Kapazitätsverbrauch zu reduzieren und die Leistung zu verbessern.
Selektive Projektionsstrategien
Wenn Ihre Abfragen nur auf einige wenige Attribute zugreifen müssen, reduziert die Projektion nur dieser Attribute die Datenmenge, die in den GSI geschrieben wird, wenn sich die Elemente der Basistabelle ändern. Einzelheiten zu den Projektionstypen finden Sie unter Projections for Global Secondary Indexes.
-
Analysieren der Abfragemuster: Überprüfen Sie die Abfragemuster Ihrer Anwendung, um festzustellen, auf welche Attribute tatsächlich über den GSI zugegriffen wird.
-
Verwenden selektiver Prognosen: Projizieren Sie nur Attribute, die in Abfragen tatsächlich benötigt werden, um das Schreibvolumen zu reduzieren.
-
Erwägen von
KEYS_ONLY: Wenn Ihre Abfragen nur die Schlüsselattribute benötigen, verwenden Sie dieKEYS_ONLY-Projektion, um das Schreibvolumen zu minimieren. -
Abwägen zwischen Lese-/Schreibvorgängen: Die Projektion von weniger Attributen reduziert zwar den Schreibkapazitätsverbrauch, macht aber möglicherweise zusätzliche Lesevorgänge in der Basistabelle erforderlich.
Sparse-GSI-Implementierung
Sparse GSIs enthält nur Elemente, die das indizierte Attribut haben, und nicht alle Elemente aus Ihrer Basistabelle. Dadurch wird die Partitionsdichte reduziert und die Leistung verbessert, wenn Sie häufig bestimmte Teilmengen von Daten abfragen.
-
Design GSIs , das nur Elemente mit bestimmten Attributwerten enthält.
-
Implementieren Sie die bedingte Indizierung, indem Sie das Schlüsselattribut der GSI-Partition nur für Elemente festlegen, die indiziert werden sollen.
-
Verwenden Sie zusammengesetzte Schlüssel mit geringer Dichte GSIs (z. B. status #timestamp), um den Verkehr innerhalb der Teilmenge der indizierten Elemente weiter zu verteilen.
Weitere Informationen zur Umsetzung dieser Strategien finden Sie unter Bewährte Methoden für die Verwendung sekundärer Indexe in DynamoDB.