Introduction
Un outil d'assistance aux commandes doit afficher les commandes du bon client pour un mois choisi. Rechercher un seul élément ou s'arrêter à une page filtrée vide peut faire manquer des enregistrements valides. Vous allez construire une table à clé composite, rechercher les commandes d'octobre d'Ada et configurer une application fournie pour suivre les clés de continuation dans une vue des commandes emballées.
Terminez d'abord Créer une table DynamoDB pour les commandes, notamment les éléments typés et les mises à jour. Cette unité démarre indépendamment avec une nouvelle connexion temporaire, des fichiers de données synthétiques et une application ordinaire. Utilisez /home/labex/project, la CLI AWS officielle et AWS View ; aucune ressource d'une VM précédente n'est réutilisée.
Lien avec les certifications
Ce laboratoire propose une pratique des sujets d’examen suivants.
- Solutions Architect – Associate (SAA-C03) · Tâche 3.3: Modèles d’accès DynamoDB, requêtes par clé et pagination.
- Developer – Associate (DVA-C02) · Tâche 1.3: Modèles d’accès DynamoDB, requêtes par clé et pagination.
- Data Engineer – Associate (DEA-C01) · Tâche 2.1: Pratique des fondamentaux : Modèles d’accès DynamoDB, requêtes par clé et pagination.
Construire les clés selon le mode d'accès
Dans cette étape, vous allez préparer des commandes nécessitant une recherche par client et par date. Une clé primaire composite comprend une clé de partition et une clé de tri. La clé de partition regroupe les commandes d'un client ; la clé de tri identifie chaque commande dans ce groupe et ordonne les résultats de requête. Les deux valeurs identifient ensemble un élément.
Les dates utilisent des chaînes de largeur fixe YYYY-MM-DD, suivies de # et d'un identifiant de commande. Les clés de tri de type chaîne comparent les octets UTF-8 ; ce format maintient donc ces dates dans l'ordre chronologique. Il s'agit d'un petit modèle de commandes, pas d'une conception universelle à table unique.
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
Le fichier préparé orders.json contient cinq commandes synthétiques, pas des identifiants d'accès. cat affiche la requête API ordinaire pour vous permettre d'inspecter chaque client, date et statut avant le chargement.
cat orders.json
aws dynamodb batch-write-item --cli-input-json file://orders.json
BatchWriteItem charge ces clés distinctes. Confirmez que UnprocessedItems vaut {}. Sur AWS, un lot non traité nécessite une nouvelle tentative ; une réponse seule ne garantit pas que toutes les écritures sont terminées. L'exemple comprend les commandes de septembre, octobre et novembre d'Ada, ainsi que la commande d'octobre de Bob, pour vous permettre de tester les limites au-delà du seul cas attendu.
Rechercher un client et une plage de dates
Dans cette étape, vous allez sélectionner les commandes d'octobre d'Ada avec des conditions de clé. Query exige une égalité sur une clé de partition et peut restreindre la clé de tri. Scan examine la table au lieu de choisir d'abord une partition par sa clé. La prochaine étape ajoute un filtre ; commencez par choisir le client et la plage de dates avec les clés.
La clé du client sélectionne la partition d'Ada ; la plage de dates sélectionne ses commandes d'octobre.
Inspectez d'abord les cinq enregistrements pour comprendre le périmètre d'un scan.
aws dynamodb scan --table-name labex-d02-orders --consistent-read --query 'Items'
Une application de recherche de commandes fournie lit lookup.json et appelle l'API Query de DynamoDB. Son exécutable est order-lookup ; son code source est fourni pour inspection et vous n'avez pas à écrire de Python. Vous allez configurer des champs ordinaires de requête Query et inspecter les résultats réels de l'application plutôt que l'historique des commandes.
BETWEEN inclut les deux bornes. Une clé de commande contient la date suivie de # et de son identifiant. La borne de début 2026-10-01# précède les identifiants de ce jour ; 2026-10-31#~ les suit, car ~ se classe après les lettres et chiffres utilisés ici. Cette borne est propre à ce format de clé.
Le heredoc entre guillemets écrit littéralement le JSON dans lookup.json. request contient les champs Query. paginate: false demande pour l'instant une seule page applicative ; vous activerez la continuation à la prochaine étape.
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
Les valeurs Query utilisent des chaînes typées, comme dans GetItem. Le fichier applicatif contient également son propre paramètre paginate ; comparez donc ses résultats avec une requête CLI directe sur les mêmes clés.
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
Les deux résultats contiennent uniquement O100 et O101 d'Ada, dans l'ordre croissant de la clé de tri. O200 de Bob et les commandes d'Ada hors du mois sont exclues. Ouvrez AWS View pour voir le résultat réel Order lookup à côté des éléments stockés dans la table. Ces lectures ne modifient aucun enregistrement.
L'exemple de la console officielle ci-dessous montre une requête Query par clé de partition. Ses attributs Artist et songTitle jouent les mêmes rôles de clé que customer_id et order_key ici. Utilisez-le pour reconnaître l'interface ; poursuivez cet exercice dans Terminal et AWS View.
Source : Tutoriel AWS DynamoDB.
Poursuivre la pagination même si une page filtrée est vide
Dans cette étape, vous allez récupérer les commandes emballées d'octobre sans vous arrêter à une première page vide. DynamoDB applique Limit aux éléments évalués avant le filtre. Les réponses Query peuvent inclure LastEvaluatedKey même si Items est vide. Cette clé de continuation, et non le nombre d'éléments, indique à une application si elle doit demander une autre page. Un filtre ne réduit pas le travail de lecture déjà effectué.
Le fichier préparé packed-page.json conserve les mêmes clés, ajoute un filtre de statut PACKED et définit Limit: 1. Cette petite limite rend la frontière entre pages visible. --no-paginate empêche la CLI de récupérer des pages supplémentaires, pour vous permettre d'inspecter une seule réponse du service.
cat packed-page.json
aws dynamodb query --cli-input-json file://packed-page.json --no-paginate
La première commande évaluée a le statut NEW : attendez-vous à obtenir Items: [], Count: 0, ScannedCount: 1 et une LastEvaluatedKey pour O100. Ce n'est pas la fin de l'ensemble des résultats.
Deux premières pages : le filtrage laisse la page 1 vide, mais sa clé de continuation mène à la commande emballée.
Écrivez la configuration applicative pour suivre cette clé jusqu'à ce que l'API cesse de la renvoyer. #state évite le mot réservé status et :state porte la valeur du filtre.
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
L'application renvoie uniquement O101 d'Ada avec le statut PACKED, Count: 1 et Evaluated: 2. Dans ce jeu de données, Pages: 3 comprend une dernière requête vide qui établit la fin de la recherche. Une clé de continuation marque une frontière de lecture ; elle ne garantit pas qu'il reste des éléments correspondant au filtre. L'application suit ExclusiveStartKey jusqu'à ce que le service cesse de la renvoyer. Dans AWS View, le résultat de recherche change, tandis que tous les enregistrements stockés restent inchangés.
Vérifier l'inventaire et supprimer la table de l'exercice
Dans cette étape, vous allez nettoyer les ressources après avoir prouvé le comportement de recherche. Vérifiez d'abord que la table cible contient toujours les cinq enregistrements d'origine. Les lectures et modifications de configuration ne doivent pas modifier les données des commandes.
aws dynamodb scan --table-name labex-d02-orders --consistent-read --select COUNT
Attendez-vous à obtenir Count: 5. Supprimez uniquement labex-d02-orders, puis attendez son absence. La table de référence appartient à l'environnement et doit rester.
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
L'inventaire ne conserve que labex-d02-reference, dont la note reste keep unchanged. AWS View retire la table de l'exercice et le résultat de recherche. Des réponses réussies du service établissent la suppression ; une connexion indisponible ne le ferait pas. La connexion temporaire prend fin avec cette VM.
Résumé
Vous avez regroupé les commandes par client et les avez ordonnées avec des clés de tri fondées sur les dates. Query a sélectionné la partition et la plage voulues, tandis que Scan a examiné la table plus largement. Vous avez constaté que les filtres s'appliquent après l'évaluation et qu'une page vide peut tout de même nécessiter une continuation. L'application fournie a utilisé de véritables requêtes Query pour récupérer la commande emballée à travers les pages, puis vous avez supprimé uniquement les ressources de l'exercice.
