Einen Index für den Bestellstatus hinzufügen

Einführung

Das Verpackungsteam benötigt Bestellungen mit dem Status NEW über alle Kunden hinweg. Der Primärschlüssel aus Kunde und Datum kann dieses Zugriffsmuster nicht mit einer einzigen Query auf die Basistabelle bedienen. Du ergänzt einen globalen sekundären Index, wählst eine Projektion aus, fragst die tatsächliche Warteschlange ab und beobachtest, wie eine verpackte Bestellung nach einem Schreibvorgang in der Basistabelle zwischen Indexpartitionen wechselt.

Schließe zuerst „Bestellungen mit einem Partitions- und Sortierschlüssel abfragen“ ab. Diese neue VM bereitet nur die Basistabelle, synthetische Datensätze, die Referenztabelle und das Anwendungsgerüst vor. Den Index zu erstellen und seine Abfrage zu konfigurieren ist deine Aufgabe. Verwende /home/labex/project, die offizielle AWS CLI und AWS View.

Bezug zu Zertifizierungen

Lab-Überblick

Ein alternatives Zugriffsmuster hinzufügen

In diesem Schritt ergänzt du einen Index für eine Verpackungswarteschlange, die Bestellungen mit dem Status NEW über alle Kunden hinweg benötigt. Die vorbereitete Tabelle verwendet customer_id und order_key; eine Query auf die Basistabelle kann nicht alle Kunden nach Status auswählen, weil der Status nicht ihr Partitionsschlüssel ist. Ein globaler sekundärer Index (GSI) stellt eine weitere Ansicht derselben Elemente mit Partitions- und Sortierschlüssel bereit.

Kundensuche und Verpackungswarteschlange beantworten unterschiedliche Geschäftsfragen zu denselben Bestellungen. Über den GSI kann die Warteschlange direkt eine Statuspartition über mehrere Kunden auswählen. Ein Statusfilter in der Kunden-Query untersucht weiterhin nur diese Kundenpartition und schafft nicht den alternativen Zugriffspfad der Warteschlange.

Die Bestelltabelle und drei synthetische Datensätze werden unabhängig vorbereitet, damit du dich auf das neue Zugriffsmuster konzentrieren kannst. Prüfe sie zunächst; lasse alle Datensätze bis auf die hier gezeigte Statusänderung unverändert.

cd /home/labex/project

aws dynamodb describe-table --table-name labex-d03-orders --query 'Table.KeySchema'

aws dynamodb scan --table-name labex-d03-orders --consistent-read

Füge StatusDateIndex mit status als Partitionsschlüssel und order_key als Sortierschlüssel hinzu. Eine Projektion legt fest, welche Attribute der Index speichert. INCLUDE ergänzt amount; Tabellen- und Indexschlüssel werden automatisch aufgenommen. Das Attribut source, das kein Schlüssel ist, bleibt ausschließlich in der Basistabelle. Indexspeicherung und Schreibvorgänge verursachen in AWS Kosten.

aws dynamodb update-table \
  --table-name labex-d03-orders \
  --attribute-definitions AttributeName=status,AttributeType=S AttributeName=order_key,AttributeType=S \
  --global-secondary-index-updates '[{"Create":{"IndexName":"StatusDateIndex","KeySchema":[{"AttributeName":"status","KeyType":"HASH"},{"AttributeName":"order_key","KeyType":"RANGE"}],"Projection":{"ProjectionType":"INCLUDE","NonKeyAttributes":["amount"]}}}]'

aws dynamodb describe-table \
  --table-name labex-d03-orders \
  --query 'Table.GlobalSecondaryIndexes[].{Name:IndexName,State:IndexStatus,Keys:KeySchema,Projection:Projection}'

Fahre erst fort, wenn StatusDateIndex den Zustand ACTIVE meldet. Die Erstellung kann in AWS Zeit benötigen; wiederhole den describe-Befehl, solange der Index noch erstellt wird. Ein table-exists-Waiter belegt nicht, dass ein neuer Index bereit ist. AWS View zeigt den Index innerhalb der Tabellenkarte an, sobald der Dienst ihn meldet.

Den Statusindex abfragen und seine Projektion prüfen

In diesem Schritt liest du die NEW-Warteschlange über die alternativen Schlüssel. --index-name wählt den GSI aus. Die Schlüsselbedingung verwendet einen Gleichheitsvergleich für den Status; ein Filter bei einem Scan der Basistabelle würde zunächst unbeteiligte Elemente lesen.

aws dynamodb query \
  --table-name labex-d03-orders \
  --index-name StatusDateIndex \
  --key-condition-expression '#state = :state' \
  --expression-attribute-names '{"#state":"status"}' \
  --expression-attribute-values '{":state":{"S":"NEW"}}'

Der Index gibt Adas O100 und Bobs O200 zurück, jeweils mit amount. Ihr Attribut source fehlt, weil es nicht projiziert wurde. Um zusätzliche Attribute aus der Basistabelle abzurufen, wäre ein separater Lesevorgang anhand des Schlüssels nötig.

GSI-Aktualisierungen laufen in AWS asynchron ab, und GSI-Lesevorgänge sind letztendlich konsistent. Ergänze eine GSI-Query nicht um --consistent-read: Diese Anfrage wird mit ValidationException abgelehnt. Warte und wiederhole den Lesevorgang, wenn ein kürzlich ausgeführter Schreibvorgang den Index noch nicht erreicht hat; betrachte ein veraltetes Ergebnis nicht als Beleg für einen fehlgeschlagenen Schreibvorgang.

Die bereitgestellte Anwendung order-lookup aus dem vorherigen Lab liest die gewöhnlichen Einstellungen in lookup.json. Schreibe die Anfrage so, dass sie diesen Index und die NEW-Warteschlange auswählt. Ein Heredoc mit Anführungszeichen schreibt JSON unverändert; ConsistentRead: false macht die Entscheidung für den Index-Lesevorgang ausdrücklich sichtbar.

cat > lookup.json <<'JSON'
{
  "paginate": true,
  "request": {
    "TableName": "labex-d03-orders",
    "IndexName": "StatusDateIndex",
    "KeyConditionExpression": "#state = :state",
    "ExpressionAttributeNames": {
      "#state": "status"
    },
    "ExpressionAttributeValues": {
      ":state": {
        "S": "NEW"
      }
    },
    "ConsistentRead": false
  }
}
JSON

./order-lookup

Die Anwendung gibt dieselben zwei Bestellungen zurück. Klappe StatusDateIndex in AWS View auf und vergleiche die tatsächliche Projektion mit dem Abfrageergebnis. Für eine Statuswarteschlange ist es richtig, beide Kunden einzubeziehen, auch wenn eine kundenspezifische Ansicht ein anderes Schlüsselmuster erfordern würde.

Den Wechsel einer Bestellung zwischen Statuswarteschlangen beobachten

In diesem Schritt verpackst du O100 und beobachtest, wie ihr Indexeintrag wechselt. Ein GSI folgt den Schreibvorgängen in der Basistabelle; du schreibst nicht direkt in den Index. Eine Statusänderung ändert die Indexpartition des Elements, während sein primärer Basisschlüssel gleich bleibt.

aws dynamodb update-item \
  --table-name labex-d03-orders \
  --key '{"customer_id":{"S":"ada"},"order_key":{"S":"2026-10-01#O100"}}' \
  --update-expression 'SET #state = :state' \
  --expression-attribute-names '{"#state":"status"}' \
  --expression-attribute-values '{":state":{"S":"PACKED"}}' \
  --return-values ALL_NEW

./order-lookup

Die NEW-Warteschlange enthält jetzt nur Bobs O200. Frage PACKED ab, um zu bestätigen, dass O100 neben O101 erscheint, statt aus dem Dienst zu verschwinden.

aws dynamodb query \
  --table-name labex-d03-orders \
  --index-name StatusDateIndex \
  --key-condition-expression '#state = :state' \
  --expression-attribute-names '{"#state":"status"}' \
  --expression-attribute-values '{":state":{"S":"PACKED"}}'

Erwarte Adas O100 und O101 in PACKED. Wiederhole diese Lesevorgänge in AWS, bis die Übernahme der Änderung in den Index sichtbar ist. Die Aktualisierungsantwort und ein konsistenter Lesevorgang auf die Basistabelle zeigen den maßgeblichen unmittelbaren Zustand des Elements; der GSI ist eine daraus abgeleitete, letztendlich konsistente Ansicht. AWS View zeigt den neuen Status von O100 und die NEW-Abfrage, die nur O200 enthält.

Den eigenen Index und die Tabelle entfernen

In diesem Schritt entfernst du die alternative Ansicht und danach die eigene Tabelle. Beim Löschen eines Index bleiben die Elemente der Basistabelle erhalten; beim Löschen einer Tabelle werden die Elemente und ihre verbleibenden Indizes entfernt. Gib nur die eigenen Ressourcen an.

aws dynamodb update-table \
  --table-name labex-d03-orders \
  --global-secondary-index-updates '[{"Delete":{"IndexName":"StatusDateIndex"}}]'

aws dynamodb describe-table \
  --table-name labex-d03-orders \
  --query 'Table.GlobalSecondaryIndexes'

Fahre fort, sobald die Indexliste leer ist. Wiederhole in AWS DescribeTable, solange die Löschung noch läuft. Die Tabelle enthält zu diesem Zeitpunkt weiterhin drei Elemente.

aws dynamodb scan --table-name labex-d03-orders --consistent-read --select COUNT

aws dynamodb delete-table --table-name labex-d03-orders

aws dynamodb wait table-not-exists --table-name labex-d03-orders

aws dynamodb list-tables

aws dynamodb get-item \
  --table-name labex-d03-reference \
  --key '{"id":{"S":"platform"}}' \
  --consistent-read

Die Bestelltabelle und ihr Index sind nicht mehr vorhanden; die Referenznotiz lautet weiterhin keep unchanged. Erfolgreiche Bestands- und Referenzabfragen unterscheiden eine Bereinigung von einem getrennten Dienst. AWS View zeigt nur noch die unbeteiligte Referenz. Die temporäre Verbindung endet mit der VM.

Zusammenfassung

Du hast einen GSI für eine kundenübergreifende Statuswarteschlange ergänzt, projizierte Attribute ausgewählt und die Indexschlüssel in tatsächlichen Abfragen verwendet. Eine Statusänderung in der Basistabelle verschob die Bestellung zwischen Indexpartitionen, ohne ihren Primärschlüssel zu ändern. Du hast den unmittelbaren Zustand der Basistabelle von der zeitversetzten Übernahme in den Index unterschieden und anschließend nur den eigenen Index und die Tabelle gelöscht.

Weitere Informationen bietet die AWS-Dokumentation: Globale Sekundärindizes, Projektionen und Konsistenz.