DynamoDB

``

  • Databases
  • Aws
  • Keyvalues
  • múltiples db en api
  • Top Use Cases for DynamoDB in 2024-dynamodb-use-cases
  • Claves primarias en DynamoDB

Visión General

DynamoDB es un servicio NoSQL completamente gestionado por AWS, orientado a Key-Value y Documentos, diseñado para ofrecer baja latencia, escalabilidad automática y alta disponibilidad sin intervención operativa. Su arquitectura distribuida lo convierte en una opción ideal para cargas de trabajo de alto rendimiento.

Arquitectura y Componentes

Modelo de Datos

  • Tablas: contenedores lógicos que almacenan ítems.
  • Ítems: objetos individuales dentro de la tabla (equivalentes a “filas”).
  • Atributos: campos dentro de cada ítem.
  • Primary Key: compuesta (Partition Key + Sort Key) o simple (solo Partition Key).
  • Índices Secundarios:
    • GSI (Global Secondary Index)
    • LSI (Local Secondary Index)

Particionamiento y Escalabilidad

  • DynamoDB distribuye automáticamente los datos en particiones físicas.
  • La Partition Key determina la distribución de los datos. Buen diseño = buen rendimiento.
  • Auto-escalado basado en RCU/WCU (Read/Write Capacity Units) o modo On-Demand.

Rendimiento

  • Consistencia eventual o consistencia fuerte (solo en lecturas).
  • DAX (DynamoDB Accelerator): caché en memoria para latencia de microsegundos.

Características Clave

Modos de Capacidad

  • Provisionado: control manual de RCU/WCU, óptimo para cargas estables.
  • On-Demand: escalado automático para cargas impredecibles.

Transacciones

  • Lecturas/escrituras ACID en múltiples ítems y tablas.
  • Ideal para operaciones críticas.

Streams

  • Registro de cambios en tiempo real.
  • Integración con Lambda para patrones event-driven.

TTL (Time to Live)

  • Eliminación automática de elementos basada en un atributo de expiración.

Backup & Restore

  • Backups continuos y restauraciones point-in-time (PITR).

Diseño de Claves y Acceso

  • Ver nota: Claves primarias en DynamoDB

Estrategias

  • Uso de claves compuestas para modelar relaciones y consultas con rangos.
  • “Single Table Design”: múltiples entidades y relaciones en una sola tabla para optimizar queries.
  • Predecir queries antes de modelar los datos (Query-First).

Patrones Avanzados de Modelado

Single Table Design

  • Unifica múltiples “tipos de entidades” en una sola tabla.
  • Requiere un diseño de claves muy cuidado.
  • Reduce la necesidad de joins y múltiples queries.

Distribución Uniforme

  • Estrategias como key sharding, random suffix/prefix, o bucketing.
  • Minimiza hot partitions.

Patrones comunes

  • Adjacency List: modelado de relaciones 1-N o N-N.
  • Materialized Aggregates: agregados precalculados para mejorar rendimiento.
  • Time-series data: patrones con Sort Keys ordenadas cronológicamente.

Integración con APIs y Microservicios

  • DynamoDB es común en arquitecturas serverless (API Gateway + Lambda).
  • Permite múltiples “bases de datos lógicas” dentro de una sola tabla, útil en api.
  • Versionado y multi-entorno mediante prefijos o claves partición.

Seguridad y Cumplimiento

  • IAM para control fino de acceso.
  • Cifrado en reposo con KMS.
  • Cifrado en tránsito mediante TLS.
  • Auditoría con CloudTrail.

Casos de Uso

  • Ver nota: Top Use Cases for DynamoDB in 2024-dynamodb-use-cases

Algunos casos generales

  • Sesiones y tokens.
  • Carritos de compra.
  • Chat en tiempo real.
  • IoT time-series.
  • Juegos online con puntuaciones en tiempo real.
  • Control de inventarios.
  • Sistemas de login y autenticación.

Comparativa con otros Modelos

Key-Value vs Documentos

  • DynamoDB combina ambos: accesos por clave y documentos heterogéneos.

    DynamoDB vs RDBMS

  • Sin joins y sin transacciones complejas.
  • Modelo basado en particiones y escalado horizontal.

    DynamoDB vs Otros NoSQL

  • Totalmente gestionado, HA por defecto.
  • Latencia muy baja y escalado predecible.

Buenas Prácticas

  • Diseñar las queries primero.
  • Evitar hot partitions.
  • Evitar lecturas de tabla completa (usar índices y claves bien diseñadas).
  • Usar DAX si la latencia es crítica.
  • Emplear TTL para datos temporales.
  • Separar lógica de agregados/computos complejos (usar Lambda).