Einführung
Ein Werkzeug für den Bestellkundendienst muss die Bestellungen des richtigen Kunden für einen ausgewählten Monat anzeigen. Wenn es nur ein Element abruft oder bei einer leeren gefilterten Seite aufhört, kann es gültige Datensätze übersehen. Du erstellst eine Tabelle mit zusammengesetztem Schlüssel, fragst Adas Oktoberbestellungen ab und konfigurierst eine bereitgestellte Anwendung so, dass sie für eine Ansicht verpackter Bestellungen den Fortsetzungsschlüsseln folgt.
Schließe zuerst „Eine DynamoDB-Tabelle für Bestellungen erstellen“ ab, einschließlich typisierter Elemente und Aktualisierungen. Diese Einheit startet unabhängig mit einer neuen temporären Verbindung, synthetischen Datendateien und einer gewöhnlichen Anwendung. Verwende /home/labex/project, die offizielle AWS CLI und AWS View; Ressourcen früherer VMs werden nicht wiederverwendet.
Bezug zu Zertifizierungen
Dieses Lab bietet praktische Übungen zu den folgenden Prüfungsthemen.
- Solutions Architect – Associate (SAA-C03) · Aufgabe 3.3: DynamoDB-Zugriffsmuster, Schlüsselabfragen und Paginierung.
- Developer – Associate (DVA-C02) · Aufgabe 1.3: DynamoDB-Zugriffsmuster, Schlüsselabfragen und Paginierung.
- Data Engineer – Associate (DEA-C01) · Aufgabe 2.1: Grundlagenübung: DynamoDB-Zugriffsmuster, Schlüsselabfragen und Paginierung.
Schlüssel am Zugriffsmuster ausrichten
In diesem Schritt bereitest du Bestellungen vor, die nach Kunde und Datum abgerufen werden müssen. Ein zusammengesetzter Primärschlüssel besteht aus einem Partitionsschlüssel und einem Sortierschlüssel. Der Partitionsschlüssel gruppiert die Bestellungen eines Kunden; der Sortierschlüssel identifiziert jede Bestellung innerhalb dieser Gruppe und ordnet die Abfrageergebnisse. Beide Werte zusammen identifizieren ein Element.
Die Datumsangaben verwenden Zeichenketten fester Breite im Format YYYY-MM-DD, gefolgt von # und einer Bestell-ID. Zeichenketten als Sortierschlüssel werden anhand ihrer UTF-8-Bytes verglichen. Deshalb hält dieses Format die Datumsangaben in chronologischer Reihenfolge. Dies ist ein kleines Bestellmodell, kein universeller Entwurf mit einer einzigen Tabelle.
cd /home/labex/project
aws sts get-caller-identity
aws dynamodb create-table --table-name labex-d02-orders --attribute-definitions AttributeName=customer_id,AttributeType=S AttributeName=order_key,AttributeType=S --key-schema AttributeName=customer_id,KeyType=HASH AttributeName=order_key,KeyType=RANGE --billing-mode PAY_PER_REQUEST
aws dynamodb wait table-exists --table-name labex-d02-orders
Die vorbereitete Datei orders.json enthält fünf synthetische Bestellungen, keine Zugangsdaten. cat gibt die gewöhnliche API-Anfrage aus, damit du vor dem Laden Kunde, Datum und Status jeder Bestellung prüfen kannst.
cat orders.json
aws dynamodb batch-write-item --cli-input-json file://orders.json
BatchWriteItem lädt diese unterschiedlichen Schlüssel. Prüfe, dass UnprocessedItems den Wert {} hat. In AWS muss ein unverarbeiteter Stapel erneut versucht werden; eine Antwort allein garantiert nicht, dass alle Schreibvorgänge abgeschlossen wurden. Das Beispiel enthält Adas September-, Oktober- und Novemberbestellungen sowie Bobs Oktoberbestellung. So kannst du die Grenzen der Abfrage prüfen, statt nur einen erfolgreichen Standardfall zu testen.
Einen Kunden und Datumsbereich abfragen
In diesem Schritt wählst du Adas Oktoberbestellungen mit Schlüsselbedingungen aus. Query verlangt einen Gleichheitsvergleich für einen Partitionsschlüssel und kann den Sortierschlüssel eingrenzen. Scan untersucht die Tabelle, statt zuerst eine Schlüsselpartition auszuwählen. Im nächsten Schritt kommt ein Filter hinzu; wähle zunächst Kunde und Datumsbereich anhand der Schlüssel aus.
Der Kundenschlüssel wählt Adas Partition aus; der Datumsbereich wählt ihre Oktoberbestellungen aus.
Prüfe zunächst alle fünf Datensätze, um den Umfang eines Scans zu verstehen.
aws dynamodb scan --table-name labex-d02-orders --consistent-read --query 'Items'
Eine bereitgestellte Anwendung zum Nachschlagen von Bestellungen liest lookup.json und ruft die DynamoDB-API Query auf. Ihre ausführbare Datei heißt order-lookup; der Quellcode steht zur Einsicht bereit, und du musst kein Python schreiben. Du konfigurierst gewöhnliche Query-Anfragefelder und prüfst echte Anwendungsergebnisse statt des Befehlsverlaufs.
BETWEEN schließt beide Endpunkte ein. Ein Bestellschlüssel enthält das Datum, gefolgt von # und seiner ID. Der Anfang 2026-10-01# liegt vor den IDs dieses Tages; 2026-10-31#~ liegt nach ihnen, weil ~ nach den hier verwendeten Buchstaben und Ziffern sortiert wird. Diese Grenze gilt speziell für dieses Schlüsselformat.
Das Heredoc mit Anführungszeichen schreibt JSON unverändert in lookup.json. request enthält die Query-Felder. paginate: false fordert zunächst eine Anwendungsseite an; im nächsten Schritt aktivierst du die Fortsetzung.
cat > lookup.json <<'JSON'
{
"paginate": false,
"request": {
"TableName": "labex-d02-orders",
"KeyConditionExpression": "customer_id = :customer AND order_key BETWEEN :start AND :end",
"ExpressionAttributeValues": {
":customer": {
"S": "ada"
},
":start": {
"S": "2026-10-01#"
},
":end": {
"S": "2026-10-31#~"
}
},
"ConsistentRead": true
}
}
JSON
Die Query-Werte verwenden typisierte Zeichenketten wie bei GetItem. Die Anwendungsdatei enthält außerdem ihre eigene Einstellung paginate. Vergleiche sie deshalb mit einer direkten CLI-Anfrage für dieselben Schlüssel.
aws dynamodb query --table-name labex-d02-orders --key-condition-expression 'customer_id = :customer AND order_key BETWEEN :start AND :end' --expression-attribute-values '{":customer":{"S":"ada"},":start":{"S":"2026-10-01#"},":end":{"S":"2026-10-31#~"}}' --consistent-read
./order-lookup
Beide Ergebnisse enthalten nur Adas O100 und O101, aufsteigend nach Sortierschlüssel geordnet. Bobs O200 und Adas Bestellungen außerhalb des Monats werden ausgeschlossen. Öffne AWS View, um das tatsächliche Ergebnis unter Order lookup neben den gespeicherten Tabellenelementen zu sehen. Diese Lesevorgänge ändern keine Datensätze.
Das folgende Beispiel aus der offiziellen Konsole zeigt eine Query mit Partitionsschlüssel. Artist und songTitle übernehmen dieselben Schlüsselrollen wie hier customer_id und order_key. Nutze es, um die Oberfläche zu erkennen; setze diese Übung im Terminal und in AWS View fort.
Quelle: AWS-DynamoDB-Tutorial.
Der Paginierung auch bei einer leeren gefilterten Seite folgen
In diesem Schritt rufst du verpackte Oktoberbestellungen ab, ohne bei einer leeren ersten Seite aufzuhören. DynamoDB wendet Limit auf die ausgewerteten Elemente vor dem Filter an. Query-Antworten können LastEvaluatedKey enthalten, selbst wenn Items leer ist. Dieser Fortsetzungsschlüssel zeigt der Anwendung, ob sie eine weitere Seite anfordern muss; die Anzahl der Elemente tut das nicht. Ein Filter verringert die bereits ausgeführte Lesearbeit nicht.
Die vorbereitete Datei packed-page.json behält dieselben Schlüssel bei, ergänzt einen Statusfilter für PACKED und setzt Limit: 1. Dieses kleine Limit macht die Seitengrenze sichtbar. --no-paginate verhindert, dass die CLI weitere Seiten abruft, damit du eine einzelne Dienstantwort untersuchen kannst.
cat packed-page.json
aws dynamodb query --cli-input-json file://packed-page.json --no-paginate
Die erste ausgewertete Bestellung hat den Status NEW. Erwarte deshalb Items: [], Count: 0, ScannedCount: 1 und einen LastEvaluatedKey für O100. Das ist noch nicht das Ende der Ergebnismenge.
Die ersten beiden Seiten: Der Filter lässt Seite 1 leer, aber ihr Fortsetzungsschlüssel führt zur verpackten Bestellung.
Schreibe die Anwendungskonfiguration so, dass sie diesem Schlüssel folgt, bis die API ihn nicht mehr zurückgibt. #state umgeht das reservierte Wort status, und :state enthält den Filterwert.
cat > lookup.json <<'JSON'
{
"paginate": true,
"request": {
"TableName": "labex-d02-orders",
"KeyConditionExpression": "customer_id = :customer AND order_key BETWEEN :start AND :end",
"ExpressionAttributeValues": {
":customer": {
"S": "ada"
},
":start": {
"S": "2026-10-01#"
},
":end": {
"S": "2026-10-31#~"
},
":state": {
"S": "PACKED"
}
},
"ConsistentRead": true,
"ExpressionAttributeNames": {
"#state": "status"
},
"FilterExpression": "#state = :state",
"Limit": 1
}
}
JSON
./order-lookup
Die Anwendung gibt nur Adas O101 mit dem Status PACKED, Count: 1 und Evaluated: 2 zurück. In diesem Datensatz umfasst Pages: 3 eine abschließende leere Anfrage, die das Ende der Abfrage feststellt. Ein Fortsetzungsschlüssel kennzeichnet eine Lesegrenze; er garantiert keine weiteren passenden Elemente. Die Anwendung folgt ExclusiveStartKey, bis der Dienst ihn nicht mehr zurückgibt. In AWS View ändert sich das Abfrageergebnis, während alle gespeicherten Datensätze unverändert bleiben.
Den Bestand prüfen und die eigene Tabelle entfernen
In diesem Schritt räumst du auf, nachdem du das Abfrageverhalten nachgewiesen hast. Prüfe zuerst, dass die Zieltabelle weiterhin die ursprünglichen fünf Datensätze enthält. Lesevorgänge und Konfigurationsänderungen sollten keine Bestelldaten verändern.
aws dynamodb scan --table-name labex-d02-orders --consistent-read --select COUNT
Erwarte Count: 5. Lösche nur labex-d02-orders und warte anschließend, bis die Tabelle nicht mehr vorhanden ist. Die Referenztabelle gehört zur Umgebung und muss erhalten bleiben.
aws dynamodb delete-table --table-name labex-d02-orders
aws dynamodb wait table-not-exists --table-name labex-d02-orders
aws dynamodb list-tables
aws dynamodb get-item --table-name labex-d02-reference --key '{"id":{"S":"platform"}}' --consistent-read
Im Bestand bleibt nur labex-d02-reference, deren Notiz weiterhin keep unchanged lautet. AWS View entfernt die eigene Tabelle und das Abfrageergebnis. Erfolgreiche Dienstantworten belegen die Löschung; eine nicht verfügbare Verbindung würde sie nicht belegen. Die temporäre Verbindung endet mit dieser VM.
Zusammenfassung
Du hast Bestellungen nach Kunden gruppiert und mit datumsbasierten Sortierschlüsseln geordnet. Query wählte die vorgesehene Partition und den Bereich aus, während Scan die umfassendere Tabelle untersuchte. Du hast gesehen, dass Filter nach der Auswertung ausgeführt werden und auch eine leere Seite eine Fortsetzung erfordern kann. Die bereitgestellte Anwendung verwendete tatsächliche Query-Anfragen, um die verpackte Bestellung über mehrere Seiten hinweg abzurufen. Anschließend hast du nur eigene Ressourcen entfernt.
