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 Global Secondary 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, es kommt jedoch aufgrund von Kapazitätsbeschränkungen bei einem oder mehreren Indizes zu einer Drosselung.

Grundlegendes zur GSI-Gegendruckdrosselung

Wenn Sie in eine DynamoDB-Tabelle schreiben, werden alle globalen Sekundärindizes (GSIs) für diese Tabelle asynchron unter Verwendung eines eventuell konsistenten Modells aktualisiert. Wenn eine globale Datenbank nicht über genügend Kapazität verfügt, um diese Aktualisierungen zu verarbeiten, drosselt DynamoDB Schreibvorgänge in die Basistabelle, um die Datenkonsistenz aufrechtzuerhalten. Dies wird als GSI-Gegendruck bezeichnet. Weitere Informationen zur GSIs Funktionsweise finden Sie unter Globale Sekundärindizes 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 eine zugeordnete 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 jede GSI gelten — jede hat ihre eigene Partitionsstruktur und entsprechende Durchsatzgrenzen.

Die GSI-Partitionierung basiert auf dem Partitionsschlüssel der 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-Updates möglicherweise immer noch auf bestimmte Partitionen, wodurch Hotspots in der GSI entstehen. Allgemeine bewährte Methoden für das Design von Partitionsschlüsseln für beide Tabellen und GSIs finden Sie unter DynamoDB-Partitionsschlüsseldesign.

Wenn Ihre Basistabelle beispielsweise customerId als Partitionsschlüssel (gleichmäßig verteilt) verwendet, Ihre GSI jedoch status als Partitionsschlüssel verwendet (mit begrenzten möglichen Werten wie „aktiv“, „ausstehend“, „geschlossen“), können Aktualisierungen von Elementen mit beliebten 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 gedrosselt werden kann, obwohl sowohl die Basistabelle als auch die GSI über eine ausreichende Gesamtkapazität verfügen und das Zugriffsmuster der Basistabelle gut verteilt zu sein scheint.

Obwohl die Drosselungsausnahme auf die GSI (viaResourceArn) verweist, ist der eigentliche Vorgang, der gedrosselt wird, das Schreiben in die Basistabelle. Dies kann verwirrend sein, da Ihre Anwendung zwar in die Basistabelle schreibt, aber eine Ausnahme bezüglich der GSI erhält.

Arten der GSI-Drosselung

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