Grundlegendes zu Schreibdrosselung und Gegendruck im globalen sekundären Index (GSI) in DynamoDB - Amazon DynamoDB
Grundlegendes zur GSI-GegendruckdrosselungArten von GSI-Drosselung

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.

Grundlegendes zu Schreibdrosselung und Gegendruck im globalen sekundären Index (GSI) in DynamoDB

Die GSI-Gegendruckdrosselung stellt eines der komplexesten Drosselungsszenarien in DynamoDB dar, da sie eine indirekte Beziehung zwischen Schreibvorgängen und Drosselung herstellt: Ihre Anwendung schreibt in eine Basistabelle, wird jedoch aufgrund von Kapazitätsbeschränkungen bei einem oder mehreren Indizes gedrosselt.

Grundlegendes zur GSI-Gegendruckdrosselung

Wenn Sie in eine DynamoDB-Tabelle schreiben, werden alle globalen sekundären Indizes (GSIs) dieser Tabelle asynchron unter Verwendung eines Modells mit letztendlicher Konsistenz aktualisiert. Wenn ein GSI nicht über genügend Kapazität verfügt, um diese Aktualisierungen zu verarbeiten, drosselt DynamoDB Schreibvorgänge in die Basistabelle, um Datenkonsistenz aufrechtzuerhalten. Dies wird als GSI-Gegendruck bezeichnet. Weitere Informationen darüber, wie GSIs funktionieren, finden Sie unter Globale sekundäre Indizes in DynamoDB.

Im Gegensatz zur direkten Tabellendrosselung, bei der die Ressource, auf die zugegriffen wird, auch die Drosselung verursacht, erzeugt der GSI-Gegendruck eine Abhängigkeit zwischen der Basistabelle und ihren Indizes. Selbst wenn Ihre Basistabelle über ausreichend Kapazität verfügt, werden Schreibvorgänge gedrosselt, wenn ein zugeordneter GSI das Aktualisierungsvolumen nicht verarbeiten kann. Es ist besonders wichtig, diesen Zusammenhang zu verstehen, da Einschränkungen auf Partitionsebene unabhängig sowohl für die Basistabelle als auch für jeden GSI gelten — jede bzw. jeder hat ihre eigene Partitionsstruktur und entsprechende Durchsatzlimits.

Die GSI-Partitionierung basiert auf dem Partitionsschlüssel des GSI, der sich häufig vom Partitionsschlüssel der Basistabelle unterscheidet. Selbst wenn der Zugriff auf die Basistabelle perfekt auf die Partitionen verteilt ist, konzentrieren sich Ihre GSI-Aktualisierungen möglicherweise trotzdem auf bestimmte Partitionen, wodurch kritische Punkte im GSI entstehen. Allgemeine bewährte Methoden für das Design von Partitionsschlüsseln für Tabellen und GSIs finden Sie unter DynamoDB-Partitionsschlüsseldesign.

Wenn Ihre Basistabelle beispielsweise customerId als Partitionsschlüssel (gleichmäßig verteilt) verwendet, Ihr GSI jedoch status (mit begrenzten möglichen Werten wie „aktiv“, „ausstehend“, „geschlossen“), können Aktualisierungen von Elementen mit gängigen Statuswerten GSI-Hot-Partitionen erzeugen, selbst wenn der Zugriff auf die Basistabelle ausgewogen ist. Dies führt zu einem besonders schwierigen Szenario, in dem Ihre Anwendung aufgrund von GSI-Hot-Partitionen möglicherweise gedrosselt wird, obwohl sowohl die Basistabelle als auch der GSI über ausreichende Gesamtkapazität verfügen und das Zugriffsmuster der Basistabelle gut verteilt zu sein scheint.

Obwohl die Drosselungsausnahme auf den GSI (über ResourceArn) verweist, ist die eigentliche Operation, die gedrosselt wird, das Schreiben in die Basistabelle. Dies kann verwirrend sein, weil Ihre Anwendung zwar in die Basistabelle schreibt, aber eine Ausnahme bezüglich des GSI erhält.

Arten von GSI-Drosselung

Die Drosselung des GSI-Gegendrucks äußert sich je nach der spezifischen Kapazitätsbeschränkung in unterschiedlichen Arten von Ausnahmen:

  • Die vom GSI bereitgestellte Kapazität wurde überschritten: Tritt auf, wenn der GSI nicht über ausreichende Schreibkapazitätseinheiten verfügt, um Aktualisierungen aus Basistabellenoperationen zu verarbeiten. Dies führt zu einer ProvisionedThroughputExceededException mit dem Grund IndexWriteProvisionedThroughputExceeded und der ResourceArn weist direkt auf den GSI hin, bei dem Kapazitätsbeschränkungen vorliegen.

  • Maximaler GSI-On-Demand-Durchsatz wurde überschritten: Tritt auf, wenn GSI-Schreibvorgänge die konfigurierten Höchstgrenzen für On-Demand-Tabellen überschreiten. Dies führt zu einer ThrottlingException mit dem Grund IndexWriteMaxOnDemandThroughputExceeded, die den spezifischen GSI mit konfigurierten Durchsatzbeschränkungen angibt.

  • Die GSI-Partitionslimits wurden überschritten: Tritt auf, wenn einzelne GSI-Partitionen ihre Durchsatzlimits überschreiten (Hot-Partitionen), auch wenn die gesamte GSI-Kapazität ausreichend erscheint. Dadurch wird eine ThrottlingException mit dem Grund IndexWriteKeyRangeThroughputExceeded generiert, die auf Probleme mit Hot-Partitionen bei dem GSI hinweist, der im ResourceArn identifiziert wurde. Dies ist besonders wichtig, da sich die GSI-Partitionsverteilung erheblich von der Partitionsverteilung der Basistabelle unterscheiden kann, was ggf. zu kritischen Punkten im GSI führt, selbst wenn der Zugriff auf die Basistabelle gleichmäßig verteilt ist.

  • Die GSI-Kontolimits wurden überschritten: Wird ausgelöst, wenn Schreibvorgänge in einen bestimmten GSI die auf Kontoebene festgelegten regionalen Durchsatzgrenzen pro Tabelle (oder jedes einzelnen GSI innerhalb dieser Tabelle) überschreiten. DynamoDB gibt eine ThrottlingException mit dem Grund IndexWriteAccountLimitExceeded zurück und verweist auf den GSI, der die Nutzung über die Kontolimits hinaus verursacht hat. Diese Drosselung erfolgt unabhängig für jeden GSI, der das Limit überschreitet. Informationen zu Service Quotas pro Tabelle, Konto und Region finden Sie unter Kontingente in Amazon DynamoDB.