Globale und lokale sekundäre Indizes

Der Primärschlüssel von DynamoDB definiert den einzigen effizienten Abfragepfad einer Tabelle. Wenn Sie Elemente anhand eines anderen Attributs abfragen müssen – beispielsweise alle Bestellungen für eine Produkt-ID finden möchten, während der Partition Key der Tabelle CustomerId lautet –, müssten Sie ohne Secondary Index einen teuren Scan ausführen.

Secondary Indexes lösen dieses Problem, indem sie eine separate, automatisch aktualisierte Kopie der Daten verwalten, die nach einem anderen Schlüssel strukturiert ist. DynamoDB bietet zwei Typen: Global Secondary Indexes (GSI) und Local Secondary Indexes (LSI), die jeweils unterschiedliche Vor- und Nachteile haben.

Mit einem Global Secondary Index können Sie einen vollständig anderen Partition Key (und optional einen Sort Key) als in der Basistabelle definieren. Der GSI ist tatsächlich global und erstreckt sich über alle Partitionen der Basistabelle. Sie können einen GSI abfragen, um Elemente anhand jedes Attributs zu finden, das Sie als Partition Key des GSI definiert haben.

GSIs verfügen über einen eigenen bereitgestellten Durchsatz (oder übernehmen den On-Demand-Modus), unabhängig von der Basistabelle. Sie können bis zu 20 GSIs pro Tabelle erstellen und GSIs jederzeit zu einer bestehenden Tabelle hinzufügen oder daraus löschen.

Ein Local Secondary Index verwendet denselben Partition Key wie die Basistabelle, aber einen anderen Sort Key. LSIs sind „lokal“, weil sie nur innerhalb einer einzelnen Partition abfragen (also Elemente mit demselben Partition Key). Dadurch eignen sich LSIs ideal, um die Bestellungen eines bestimmten Kunden nach unterschiedlichen Attributen zu sortieren und abzufragen.

LSIs müssen zum Zeitpunkt der Tabellenerstellung definiert werden – später können Sie sie weder hinzufügen noch entfernen. Jede Tabelle kann bis zu 5 LSIs enthalten. LSIs teilen sich die bereitgestellte Kapazität der Basistabelle (kein separater Durchsatz) und unterliegen dem Speicherlimit von 10 GB pro Partition Key für die Kombination aus Basistabellen- und LSI-Daten.

Hier ist ein direkter Vergleich für eine klare Prüfungsvorbereitung:

• Partitionsschlüssel: GSI kann sich von der Basistabelle unterscheiden; LSI muss mit der Basistabelle übereinstimmen
• Sortierschlüssel: Beide unterstützen einen anderen Sortierschlüssel als die Basistabelle
• Erstellungszeitpunkt: GSI jederzeit; LSI nur bei der Tabellenerstellung
• Durchsatz: GSI verfügt über einen eigenen Durchsatz; LSI teilt den Durchsatz der Basistabelle
• Konsistenz: GSI-Lesevorgänge sind nur eventual consistent; LSI-Lesevorgänge können strongly consistent sein
• Limits: bis zu 20 GSIs; bis zu 5 LSIs pro Tabelle

Beim Erstellen eines Index wählen Sie aus, welche Attribute in ihn projiziert (kopiert) werden:

• KEYS_ONLY: nur der Primärschlüssel der Basistabelle und der Indexschlüssel – kleinster Index, erfordert zusätzliche GetItem-Aufrufe für Nichtschlüsselattribute
• INCLUDE: Schlüsselattribute sowie eine bestimmte Liste zusätzlicher Attribute, die Sie angeben – ausgewogenes Verhältnis zwischen Größe und Zugriffsmuster
• ALL: alle Attribute werden in den Index projiziert – größte Flexibilität, höhere Speicher- und Schreibkosten

Wählen Sie den Projektionstyp danach aus, welche Attribute Ihre Abfragen tatsächlich benötigen. Eine Überprojektion verschwendet bei jedem Schreibvorgang WCUs; eine Unterprojektion erzwingt zusätzliche GetItem-Aufrufe, um nicht im Index enthaltene Attribute abzurufen.

Das Abfragen einer GSI verwendet dieselbe Query-API, gibt jedoch den Parameter --index-name an. Die Abfrage wird anhand des Schlüsselschemas der GSI und nicht anhand des Schlüsselschemas der Basistabelle ausgeführt. GSI-Abfragen sind immer eventual consistent – die GSI wird nach Schreibvorgängen in der Basistabelle asynchron aktualisiert, sodass es zu einer kurzen Verzögerung kommt.

Wenn ein Element in der Basistabelle nicht über das Partitionsschlüsselattribut der GSI verfügt, wird es überhaupt nicht in die GSI aufgenommen (Muster eines sparsamen Index). Dies ist eine leistungsstarke Technik, um nur eine Teilmenge von Elementen zu indizieren, beispielsweise alle Bestellungen mit dem Status PENDING, wenn der GSI-Partitionsschlüssel Status lautet.

Ein sparsamer Index nutzt die Tatsache, dass DynamoDB Elemente nur dann in eine GSI projiziert, wenn sie einen Wert für den Partitionsschlüssel der GSI besitzen. Indem Sie den Partitionsschlüssel der GSI für ein Attribut definieren, das nur bei einigen Elementen vorhanden ist, erstellen Sie einen Index, der nur diese Teilmenge enthält.

Beispiel: In einer Orders-Tabelle besitzen nur noch nicht versendete Bestellungen ein Attribut PendingShipmentDate. Eine GSI für PendingShipmentDate enthält daher automatisch nur noch nicht versendete Bestellungen. So lassen sich alle ausstehenden Bestellungen äußerst effizient abfragen, ohne die gesamte Tabelle zu durchsuchen.

GSI-Überladung ist eine fortgeschrittene Technik für das Single-Table-Design. Dabei speichern Sie verschiedene Entitätstypen in einer Tabelle und verwenden ein generisches GSI-Schlüsselattribut (z. B. GSI1PK und GSI1SK), das abhängig vom Elementtyp mit unterschiedlichen Mustern befüllt wird. Dadurch erhält jeder Entitätstyp über eine einzige GSI einen eigenen effizienten Abfragepfad.

Beispiel: Für User-Elemente setzen Sie GSI1PK = 'COUNTRY#US' und GSI1SK = username; für Order-Elemente setzen Sie GSI1PK = 'STATUS#PENDING' und GSI1SK = orderDate. Wenn Sie die GSI mit dem passenden Präfix abfragen, wird der gewünschte Entitätstyp effizient abgerufen.

Die Drosselung einer GSI erfolgt unabhängig von der Basistabelle. Wenn die bereitgestellten WCUs der GSI zu niedrig sind, werden Schreibvorgänge für Elemente, die in die GSI projiziert werden, gedrosselt – selbst wenn die Basistabelle über ausreichend Kapazität verfügt. Überwachen Sie ConsumedWriteCapacityUnits und ThrottledRequests für jede GSI separat.

Ein häufiger Fehler besteht darin, für die GSI eine geringere Kapazität als für die Basistabelle bereitzustellen und anschließend eine Drosselung zu erleben, wenn ein Schreibmuster die Schreibrate der GSI plötzlich erhöht. Verwenden Sie Auto Scaling für GSIs oder wählen Sie den On-Demand-Modus, um dies zu vermeiden.

Entscheidungshilfen für die SAA-C03-Prüfung:

• Sie müssen nach einem völlig anderen Attribut abfragen → GSI
• Sie müssen innerhalb derselben Partition abfragen, aber anders sortieren, und kennen diese Anforderung bereits bei der Erstellung → LSI
• Sie benötigen stark konsistente Lesevorgänge für einen alternativen Sortierschlüssel → LSI (einzige Option, da GSIs eventual consistent sind)
• Sie haben zehn oder mehr unterschiedliche Abfragemuster → Ziehen Sie ein Single-Table-Design mit GSI-Überladung statt vieler separater Tabellen in Betracht
• Sie müssen lediglich alle Elemente zur Analyse abrufen → Überdenken Sie, ob DynamoDB die geeignete Datenbank ist

Sie können eine GSI jederzeit löschen, ohne die Basistabelle zu beeinträchtigen. Wenn Sie einer bestehenden Tabelle eine neue GSI hinzufügen, befüllt DynamoDB den Index asynchron nach, indem die Basistabelle durchsucht wird – bei großen Tabellen kann dies Minuten bis Stunden dauern. Während dieses Vorgangs bleibt die Basistabelle für Lese- und Schreibvorgänge vollständig verfügbar.

Sie können den Fortschritt des Nachfüllens in der Konsole oder über die DescribeTable-API überwachen, indem Sie das Feld IndexStatus des Index prüfen. Während des Vorgangs lautet es CREATING, nach Abschluss ACTIVE. Fragen Sie die GSI erst ab, wenn sie den Status ACTIVE hat.

Testen Sie Ihr Verständnis der AWS-Solutions-Architect-Konzepte (SAA-C03) aus dieser Lektion.

In dieser Lektion haben Sie gelernt: GSIs stellen alternative Partitionsschlüssel bereit und können jederzeit hinzugefügt werden, LSIs verwenden denselben Partitionsschlüssel wie die Basistabelle und müssen bei der Erstellung definiert werden und Projektionstypen bestimmen, welche Attribute in den Index kopiert werden. GSIs unterstützen für fortgeschrittene Flexibilität bei Abfragen Muster wie sparsame Indizes und Überladung. Als Nächstes befassen wir uns mit DynamoDB Streams und Global Tables.