Introducción
Una herramienta de asistencia de pedidos debe mostrar los pedidos del cliente correcto para un mes elegido. Consultar un solo elemento o detenerse en una página filtrada vacía puede omitir registros válidos. Crearás una tabla de clave compuesta, consultarás los pedidos de octubre de Ada y configurarás una aplicación proporcionada para seguir claves de continuación en una vista de pedidos empaquetados.
Completa primero Crea una tabla DynamoDB para pedidos, incluidos los elementos tipados y las actualizaciones. Esta unidad empieza de forma independiente con una conexión desechable nueva, archivos de datos sintéticos y una aplicación normal. Utiliza /home/labex/project, AWS CLI oficial y AWS View; no se reutilizan recursos de VM anteriores.
Relación con las certificaciones
Este laboratorio ofrece práctica para los siguientes temas de examen.
- Solutions Architect – Associate (SAA-C03) · Tarea 3.3: Patrones de acceso DynamoDB, consultas por clave y paginación.
- Developer – Associate (DVA-C02) · Tarea 1.3: Patrones de acceso DynamoDB, consultas por clave y paginación.
- Data Engineer – Associate (DEA-C01) · Tarea 2.1: Práctica de fundamentos: Patrones de acceso DynamoDB, consultas por clave y paginación.
Diseña las claves según el patrón de acceso
En este paso, prepararás pedidos que necesitan una consulta por cliente y fecha. Una clave primaria compuesta tiene una clave de partición y una clave de ordenación. La clave de partición agrupa los pedidos de un cliente; la clave de ordenación identifica cada pedido dentro de ese grupo y ordena los resultados de consulta. Ambos valores juntos identifican un elemento.
Las fechas utilizan cadenas de anchura fija YYYY-MM-DD seguidas de # y un ID de pedido. Las claves de ordenación de tipo cadena comparan bytes UTF-8, así que este formato mantiene estas fechas en orden cronológico. Es un pequeño modelo de pedidos, no un diseño universal de tabla única.
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
El archivo orders.json preparado contiene cinco pedidos sintéticos, no credenciales. cat muestra la solicitud normal de API para que puedas inspeccionar cada cliente, fecha y estado antes de cargarla.
cat orders.json
aws dynamodb batch-write-item --cli-input-json file://orders.json
BatchWriteItem carga estas claves distintas. Confirma que UnprocessedItems es {}. En AWS, un lote sin procesar necesita un reintento; una respuesta por sí sola no garantiza que todas las escrituras terminaran. El ejemplo incluye los pedidos de septiembre, octubre y noviembre de Ada, además del pedido de octubre de Bob, lo que permite probar límites en lugar de un único caso favorable.
Consulta un cliente y un intervalo de fechas
En este paso, seleccionarás los pedidos de octubre de Ada mediante condiciones de clave. Query requiere igualdad en una clave de partición y puede limitar la clave de ordenación. Scan examina la tabla en lugar de elegir primero una partición de clave. El siguiente paso añade un filtro; primero elige el cliente y el intervalo de fechas mediante las claves.
La clave de cliente selecciona la partición de Ada; el intervalo de fechas selecciona sus pedidos de octubre.
Primero inspecciona los cinco registros para comprender el alcance de un scan.
aws dynamodb scan --table-name labex-d02-orders --consistent-read --query 'Items'
Una aplicación de consulta de pedidos proporcionada lee lookup.json y llama a la API Query de DynamoDB. Su ejecutable es order-lookup; su código fuente está disponible para inspeccionarlo y no se requiere escribir Python. Configurarás campos normales de solicitudes Query e inspeccionarás resultados reales de la aplicación, no el historial de comandos.
BETWEEN incluye ambos extremos. Una clave de pedido contiene la fecha seguida de # y su ID. El inicio 2026-10-01# va antes de los ID de ese día; 2026-10-31#~ va después porque ~ se ordena después de las letras y los dígitos utilizados aquí. Este límite es específico de este formato de clave.
El heredoc entre comillas escribe JSON literalmente en lookup.json. request contiene los campos de Query. paginate: false solicita una página de aplicación por ahora; activarás la continuación en el siguiente paso.
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
Los valores de Query utilizan cadenas tipadas, como en GetItem. El archivo de aplicación también contiene su propio ajuste paginate, así que compáralo con una solicitud directa de CLI para las mismas claves.
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
Ambos resultados contienen únicamente O100 y O101 de Ada, en orden ascendente de clave de ordenación. Se excluyen O200 de Bob y los pedidos de Ada de otros meses. Abre AWS View para ver el resultado real de Order lookup junto a los elementos almacenados de la tabla. Estas lecturas no cambian ningún registro.
El ejemplo de Console oficial siguiente muestra una Query por clave de partición. Sus Artist y songTitle tienen las mismas funciones de clave que customer_id y order_key aquí. Utilízalo para reconocer la interfaz; continúa este ejercicio en Terminal y AWS View.
Fuente: Tutorial de AWS DynamoDB.
Sigue la paginación incluso cuando una página filtrada esté vacía
En este paso, recuperarás pedidos de octubre empaquetados sin detenerte en una primera página vacía. DynamoDB aplica Limit a los elementos evaluados antes del filtro. Las respuestas Query pueden incluir LastEvaluatedKey incluso cuando Items está vacío. Esa clave de continuación, no el número de elementos, indica a una aplicación si debe solicitar otra página. Un filtro no reduce el trabajo de lectura ya realizado.
El archivo packed-page.json preparado mantiene las mismas claves, añade un filtro de estado PACKED y establece Limit: 1. Este límite pequeño hace visible el límite entre páginas. --no-paginate impide que la CLI recupere páginas adicionales para que puedas inspeccionar una respuesta del servicio.
cat packed-page.json
aws dynamodb query --cli-input-json file://packed-page.json --no-paginate
El primer pedido evaluado es NEW, así que espera Items: [], Count: 0, ScannedCount: 1 y una LastEvaluatedKey de O100. No es el final del conjunto de resultados.
Primeras dos páginas: el filtrado deja vacía la página 1, pero su clave de continuación lleva al pedido empaquetado.
Escribe la configuración de la aplicación para seguir esa clave hasta que la API deje de devolverla. #state evita la palabra reservada status y :state contiene el valor del filtro.
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
La aplicación devuelve únicamente O101 de Ada con estado PACKED, Count: 1 y Evaluated: 2. En este conjunto de datos, Pages: 3 incluye una solicitud final vacía que establece el final de la consulta. Una clave de continuación marca un límite de lectura; no garantiza más elementos coincidentes. La aplicación sigue ExclusiveStartKey hasta que el servicio deja de devolverla. En AWS View cambia el resultado de la consulta mientras todos los registros almacenados permanecen sin cambios.
Verifica el inventario y elimina la tabla propia
En este paso, limpiarás los recursos después de demostrar el comportamiento de la consulta. Primero comprueba que la tabla objetivo todavía contiene los cinco registros originales. Las lecturas y los cambios de configuración no deberían modificar los datos de pedidos.
aws dynamodb scan --table-name labex-d02-orders --consistent-read --select COUNT
Espera Count: 5. Elimina únicamente labex-d02-orders y después espera a su ausencia. La tabla de referencia pertenece al entorno y debe permanecer.
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
El inventario conserva solo labex-d02-reference, cuya nota sigue siendo keep unchanged. AWS View elimina la tabla propia y el resultado de consulta. Las respuestas correctas del servicio demuestran la eliminación; una conexión no disponible no lo haría. La conexión desechable termina con esta VM.
Resumen
Agrupaste pedidos por cliente y los ordenaste con claves de ordenación basadas en fechas. Query seleccionó la partición y el intervalo previstos mientras Scan examinó la tabla más amplia. Observaste que los filtros se ejecutan después de la evaluación y que una página vacía todavía puede requerir continuación. La aplicación proporcionada utilizó solicitudes Query reales para recoger el pedido empaquetado a través de solicitudes paginadas; después eliminaste únicamente los recursos propios.
