Amazon DVA-C02: Amazon DynamoDB y diseño NoSQL — Guía de estudio
Forma parte de la AWS Developer Associate DVA-C02 — Guía de estudio. Practica con respuestas verificadas en el centro de exámenes de Amazon, o realiza tests cronometrados en ExamRoll.io.
Modelado de datos y patrones de acceso
El diseño de DynamoDB comienza con los patrones de acceso: cada consulta debe corresponder a una clave principal, un índice secundario global (GSI) o un índice secundario local (LSI); el diseño de la tabla se basa en cómo la aplicación lee y escribe los elementos, no en cómo se estructuraría un esquema relacional. Elija una clave de partición de alta cardinalidad para evitar particiones calientes (hot partitions) y use una clave principal compuesta (clave de partición + clave de ordenación) cuando necesite consultas de rango; las operaciones Query requieren igualdad en la clave de partición y una KeyConditionExpression opcional en la clave de ordenación. Para los SDK, prefiera las abstracciones de documentos de DynamoDB: use DynamoDBDocumentClient con el AWS SDK for JavaScript v3 (el marshall/unmarshall se gestiona por usted) o el DynamoDB Enhanced Client en Java para mapear objetos a atributos. Implemente patrones de tabla única solo cuando los patrones de lectura compartan claves y pueda codificar los tipos de elementos mediante un atributo de tipo; use GSI dispersos (sparse GSIs) para exponer rutas de acceso secundarias escribiendo atributos solo en los elementos que los necesitan. Un error común es el uso excesivo de Scan: escanear tablas grandes es costoso y paginado (LastEvaluatedKey); prefiera Query con ProjectionExpression para reducir el uso de RCU. Para escrituras condicionales, use UpdateItem con ConditionExpression o TransactWriteItems para atomicidad de múltiples elementos; gestione ConditionalCheckFailedException y aplique un retroceso exponencial con fluctuación (back off with jitter).
Índices, consultas y patrones transaccionales
Los índices secundarios locales (LSI) se crean solo al momento de la creación de la tabla, comparten la misma clave de partición que la tabla base y consumen la capacidad de lectura de la tabla para las consultas, mientras que los GSI se pueden agregar después de la creación de la tabla, tienen capacidad independiente o facturación bajo demanda, y permiten claves de partición diferentes. Las llamadas Query usan KeyConditionExpression y ExpressionAttributeNames/Values; las expresiones de proyección (projection expressions) reducen la transferencia de datos. Los GSI son eventualmente consistentes por defecto e incurren en un costo de escritura adicional porque cada escritura en la tabla base que proyecta atributos indexados crea las escrituras correspondientes en el GSI — planifique las WCU en consecuencia y monitoree ConsumedWriteCapacityUnits para el índice. Para una consistencia alta (strong consistency), use GetItem o Query con ConsistentRead=true en la tabla base (los GSI no admiten lecturas de consistencia alta). Las transacciones (TransactWriteItems y TransactGetItems) garantizan la atomicidad en hasta 25 elementos o una carga útil de 4 MB; use ReturnValuesOnConditionCheckFailure para inspeccionar los fallos. BatchWriteItem y BatchGetItem están limitados a 25 y 100 elementos respectivamente y no son transaccionales; el código debe gestionar los UnprocessedItems reintentando con retroceso exponencial (exponential backoff). Un problema frecuente es olvidar el costo y las implicaciones de la consistencia eventual de los GSI al migrar uniones relacionales (relational joins) a índices.
Modos de capacidad, ajuste de rendimiento y solución de problemas
Decida entre la capacidad aprovisionada y bajo demanda según la previsibilidad: la aprovisionada con Auto Scaling (Application Auto Scaling para DynamoDB) da control sobre las RCU/WCU y el costo para cargas de trabajo estables, mientras que la de bajo demanda simplifica el tráfico en ráfagas sin planificación de capacidad, pero con un precio por solicitud más alto. Habilite Auto Scaling con una utilización objetivo y múltiples políticas de escalado; monitoree las métricas de CloudWatch como ConsumedReadCapacityUnits, ConsumedWriteCapacityUnits, ThrottledRequests, SuccessfulRequestLatency, SystemErrors y ConditionalCheckFailedRequests para detectar puntos calientes (hotspots) y estrangulamiento (throttling). Use la capacidad adaptativa para mitigar el estrangulamiento de una sola clave, pero evite depender de ella — diseñe para una distribución de claves uniforme. Para cargas de trabajo con uso intensivo de lectura, considere DAX para lecturas de microsegundos o una caché con Amazon ElastiCache; para un uso intensivo de escritura, use fragmentación de escritura (write sharding) (prefijos o buckets) para distribuir las escrituras entre las particiones. Para solucionar problemas, inspeccione ProvisionedThroughputExceededException e implemente un retroceso exponencial con fluctuación (exponential backoff with jitter) en los clientes del SDK, habilite CloudWatch Contributor Insights para encontrar claves calientes (hot keys) y use Parallel Scan para análisis grandes y únicos con trabajadores segmentados. Recuerde los límites de tamaño de los elementos (400 KB) y que los elementos grandes aumentan las RCU/WCU; divida los blobs grandes en S3 con los metadatos en DynamoDB cuando sea necesario.
Streams, integraciones, backups y mejores prácticas operativas
DynamoDB Streams captura los cambios a nivel de ítem (INSERT, MODIFY, REMOVE) en orden por clave de partición y se integra directamente con Lambda a través de un mapeo de origen de eventos (configura startingPosition como TRIM_HORIZON o LATEST, establece batchSize y maximumBatchingWindowInSeconds, y ajusta bisectBatchOnError y maximumRetryAttempts). Para un procesamiento robusto, usa Lambda con una cola de mensajes fallidos (SQS o SNS) o enruta los registros del stream a Kinesis o Kinesis Data Firehose para análisis. Habilita Time To Live (TTL) para la expiración automática de ítems; ten en cuenta que las eliminaciones por TTL se procesan eventualmente y no se debe depender de ellas para una consistencia inmediata. Usa la recuperación a un momento dado (PITR) y backups bajo demanda para la recuperación ante desastres; para disponibilidad multirregional, usa Global Tables para replicar los cambios entre regiones. Aplica roles de IAM con privilegios mínimos a los servicios y concede solo las acciones necesarias dynamodb:Query, dynamodb:PutItem, dynamodb:UpdateItem, dynamodb:GetItem, dynamodb:DescribeStream y dynamodb:ListStreams para las funciones Lambda. Los errores operativos comunes incluyen la falta de lógica de reintentos/backoff en los consumidores, una planificación inadecuada de la capacidad de los GSI y no monitorear el IteratorAge de los Streams para la detección de retrasos; instrumenta con CloudWatch Logs y X-Ray para rastrear la latencia de extremo a extremo.
Problema práctico: Escenario de caso de uso
Escenario: AcmeMedia gestiona un catálogo de metadatos en una única tabla de DynamoDB en us-east-1 que contiene decenas de millones de ítems. Un pipeline de procesamiento de imágenes recién lanzado necesita una consulta de baja latencia por photographerId y un rango de uploadTimestamp, y los consumidores Lambda posteriores deben procesar los cambios de forma fiable.
Desafío: Añadir una ruta de consulta eficiente para photographerId + rango de timestamp sin rediseñar la tabla, asegurar que los procesos Lambda posteriores procesen los registros del stream con semántica de al menos una vez, y evitar particiones calientes para fotógrafos prolíficos.
Enfoque recomendado:
- Crear un GSI llamado
photographer-gsicon la clave de particiónphotographerIdy la clave de ordenaciónuploadTimestamp; usar la APIUpdateTableo la consola para añadir el GSI y especificar la facturaciónProvisionedThroughputoOn-Demanda través deUpdateTabley establecer el monitoreo deIndexStatus. - Al escribir ítems, incluir los atributos
photographerIdyuploadTimestamppara que la proyección del índice sea dispersa; eligeProjectionType=INCLUDEcon los atributos que no son clave necesarios para las consultas para reducir los costos de almacenamiento y escritura. - Configurar DynamoDB Streams como
ENABLEDen la tabla y crear un mapeo de origen de eventos de Lambda constartingPosition=TRIM_HORIZON, unbatchSizeajustado (p. ej., 100),bisectBatchOnError=true,maximumRetryAttempts=2, y establecer una cola SQS como destino de mensajes fallidos en la configuración de la función Lambda. - Implementar reintentos del cliente SDK con jitter (usar la estrategia de reintentos integrada del SDK de AWS) y aplicar sharding de escritura si un único
photographerIdsigue causando throttling (prefijar elphotographerIdcon N buckets en la escritura y eliminar el prefijo en el lado del cliente al leer).
Justificación: Añadir un GSI expone el patrón de acceso requerido sin cambiar la clave primaria base; proyectar solo los atributos necesarios reduce el costo de escritura del GSI. Streams + Lambda con una DLQ y controles de reintento proporcionan un procesamiento fiable de al menos una vez, mientras que el sharding protege contra las particiones calientes generadas por tráfico de alta cardinalidad.
← Amazon API Gateway e integración de aplicaciones · Todos los dominios · CloudFormation e infraestructura como código (SAM →
Practica estas preguntas → · Práctica cronometrada en ExamRoll.io →
Pass the whole exam — not just this question
You found this answer. Get every verified question and explanation in one place, and save hours of prep. Free to start.
Aprueba tu examen →