Indexes

Ein Secondary Index gibt dir ein zweites Zugriffsmuster über dieselben Daten — eine andere Partition key und Sort key. Wenn du von SQL kommst, ist die Falle, einen GSI wie einen B-tree-Index zu behandeln, den man kostenlos hinzufügt. Das ist er nicht: Ein GSI ist eine replizierte Kopie deiner Daten mit eigenen Keys, eigenen Kosten und eigenen Konsistenzregeln.

Dieser Abschnitt behandelt die Wahl des richtigen Index-Typs, das Günstighalten von Indexes und die Fallstricke, die in Produktion zubeißen — veraltete Reads und Write-Throttling, das sich auf einen Index zurückführen lässt, nicht auf die Tabelle.

0 von 7 gelesenQuiz

GSI vs LSI in DynamoDB

GSI vs LSI in DynamoDB — die Unterschiede bei Partition Key, Konsistenz, Kapazität und 10-GB-Grenze, und eine einfache Regel, zu welchem Sekundärindex du greifst.

Einsteiger3 Min. Lesezeit

DynamoDB-Index-Projektionen: KEYS_ONLY, INCLUDE und ALL

DynamoDB-Index-Projektionen — KEYS_ONLY, INCLUDE und ALL — was jede in einen GSI/LSI kopiert, der Trade-off bei Speicher- und Schreibkosten und warum ein fehlendes Attribut einen Basistabellen-Fetch erzwingt.

Fortgeschritten5 Min. Lesezeit

Sparse Indexes in DynamoDB

Sparse Indexes in DynamoDB lassen einen Global Secondary Index nur die Items halten, die seinen Key tragen — der günstigste Weg, eine kleine Teilmenge einer großen Tabelle abzufragen.

Fortgeschritten7 Min. Lesezeit

Key Overloading in DynamoDB

Key Overloading in DynamoDB — speichere viele Entitätstypen unter generischen PK/SK-Namen, kodiere den Typ in den Key-Wert und bediene jedes Zugriffsmuster aus einer Tabelle.