Ajouter un index pour le statut des commandes

Introduction

L'équipe d'emballage a besoin des commandes NEW de tous les clients. La clé primaire par client et par date ne permet pas ce mode d'accès avec une seule requête Query sur la table de base. Vous allez ajouter un index secondaire global, choisir une projection, interroger la file réelle et observer une commande emballée changer de partition d'index après une écriture dans la table de base.

Terminez d'abord Rechercher des commandes avec une clé de partition et de tri. Cette nouvelle VM prépare uniquement la table de base, les enregistrements synthétiques, la table de référence et le socle de l'application. La création de l'index et la configuration de sa recherche vous reviennent. Utilisez /home/labex/project, la CLI AWS officielle et AWS View.

Lien avec les certifications

Vue d’ensemble du laboratoire

Ajouter un autre mode d'accès

Dans cette étape, vous allez ajouter un index pour une file d'emballage qui doit réunir les commandes NEW de tous les clients. La table préparée utilise customer_id et order_key ; une requête Query sur la table de base ne peut pas sélectionner tous les clients par statut, car le statut n'est pas sa clé de partition. Un index secondaire global (GSI) offre une autre vue des mêmes éléments avec une clé de partition et une clé de tri.

La recherche par client et la file de préparation répondent à des besoins différents à partir des mêmes commandes. Le GSI permet à la file de sélectionner directement une partition de statut regroupant plusieurs clients. Un filtre de statut ajouté à la Query par client examinerait toujours uniquement la partition de ce client ; il ne créerait pas l’autre chemin d’accès requis.

La table de commandes et trois enregistrements synthétiques sont préparés indépendamment pour vous permettre de vous concentrer sur le nouveau mode d'accès. Inspectez-les d'abord ; conservez tous les enregistrements inchangés, à l'exception de la mise à jour de statut enseignée.

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

Ajoutez StatusDateIndex avec status comme clé de partition et order_key comme clé de tri. Une projection détermine les attributs stockés par l'index. INCLUDE ajoute amount ; les clés de la table et de l'index sont incluses automatiquement. L'attribut hors clé source restera uniquement dans la table de base. Le stockage et les écritures d'index ont un coût sur AWS.

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}'

Poursuivez uniquement lorsque StatusDateIndex indique ACTIVE. La création peut prendre du temps sur AWS ; répétez la commande de description tant que l'index est en cours de création. Une commande d'attente table-exists ne prouve pas qu'un nouvel index est prêt. AWS View affiche l'index dans la carte de la table une fois que le service le signale.

Interroger l'index par statut et inspecter sa projection

Dans cette étape, vous allez lire la file NEW avec les autres clés. --index-name sélectionne le GSI. La condition de clé utilise une égalité sur status ; un filtre appliqué à un scan de la table de base lirait d'abord des éléments sans rapport avec la recherche.

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"}}'

L'index renvoie O100 d'Ada et O200 de Bob, chacun avec amount. Leur attribut source est absent, car il n'a pas été projeté. Récupérer d'autres attributs de la table de base nécessiterait une lecture distincte par clé.

Les mises à jour de GSI sont asynchrones sur AWS et les lectures de GSI utilisent la cohérence éventuelle. N'ajoutez pas --consistent-read à une requête Query sur un GSI : cette requête est rejetée avec ValidationException. Attendez et répétez une lecture si une écriture récente n'a pas encore atteint l'index ; ne considérez pas un résultat périmé comme une preuve d'échec de l'écriture.

L'application order-lookup fournie, utilisée dans le laboratoire précédent, lit les paramètres ordinaires de lookup.json. Écrivez la requête pour choisir cet index et la file NEW. Un heredoc entre guillemets écrit littéralement le JSON ; ConsistentRead: false rend explicite le choix de lecture de l'index.

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

L'application renvoie les deux mêmes commandes. Développez StatusDateIndex dans AWS View et comparez la projection réelle avec le résultat de recherche. Conserver les deux clients est correct pour une file par statut, même si une vue propre à un client nécessiterait un autre modèle de clés.

Observer une commande changer de file de statut

Dans cette étape, vous allez emballer O100 et observer le déplacement de son entrée d'index. Un GSI suit les écritures de la table de base ; vous n'écrivez pas directement dans l'index. La mise à jour de status change la partition d'index de l'élément, tandis que sa clé primaire de base reste identique.

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

La file NEW ne contient maintenant que O200 de Bob. Interrogez PACKED pour confirmer que O100 apparaît aux côtés de O101 au lieu de disparaître du service.

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"}}'

Attendez-vous à trouver O100 et O101 d'Ada dans PACKED. Sur AWS, répétez ces lectures jusqu'à ce que la propagation dans l'index soit visible. La réponse de mise à jour et une lecture cohérente de la table de base font autorité sur l'état immédiat de l'élément ; le GSI est une vue dérivée à cohérence éventuelle. AWS View affiche le nouveau statut de O100 et la recherche NEW ne contenant que O200.

Supprimer l'index et la table de l'exercice

Dans cette étape, vous allez supprimer l'autre vue, puis la table de l'exercice. Supprimer un index conserve les éléments de la table de base ; supprimer une table supprime ses éléments et les index restants. Nommez uniquement les ressources de l'exercice.

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'

Poursuivez lorsque la liste des index est vide. Sur AWS, répétez DescribeTable pendant la suppression. La table contient encore trois éléments à ce stade.

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

La table de commandes et son index sont absents ; la note de référence reste keep unchanged. Un inventaire et des lectures de référence réussis distinguent le nettoyage d'une perte de connexion au service. AWS View conserve uniquement la référence sans rapport avec l'exercice. La connexion temporaire prend fin avec la VM.

Résumé

Vous avez ajouté un GSI pour une file par statut regroupant plusieurs clients, choisi les attributs projetés et utilisé les clés de l'index dans de véritables requêtes. Une mise à jour de statut dans la table de base a déplacé la commande entre les partitions de l'index sans changer sa clé primaire. Vous avez distingué l'état immédiat de la table de base de la propagation éventuelle dans l'index, puis supprimé uniquement l'index et la table de l'exercice.

Pour approfondir ce sujet, consultez la documentation AWS : Index secondaires globaux, projections et cohérence.