AWS DynamoDB

¿Qué es?

DynamoDB es la base de datos NoSQL serverless de AWS que ofrece latencia consistente de milisegundos sin importar el tamaño de los datos o el volumen de requests. No hay servidores que administrar, parches que aplicar ni capacidad que planificar manualmente.

A diferencia de las bases de datos relacionales, DynamoDB utiliza un modelo de datos flexible donde cada item puede tener diferentes atributos. Su arquitectura distribuida automáticamente particiona los datos usando la partition key, garantizando escalabilidad horizontal sin límites teóricos.

El diseño de DynamoDB prioriza la disponibilidad y la latencia sobre la consistencia fuerte, siguiendo el teorema CAP. Esto significa que las aplicaciones deben diseñarse considerando eventual consistency, aunque ofrece strong consistency como opción para reads específicos.

Modelo de datos y single-table design

DynamoDB utiliza un modelo de datos basado en tablas, items y atributos:

• Partition Key (PK): distribuye items across particiones físicas
• Sort Key (SK): opcional, ordena items dentro de una partición
• Atributos: campos con tipos de datos flexibles (String, Number, Binary, Boolean, List, Map, Set)

Ejemplo de single-table design

Consideremos un sistema de e-commerce con órdenes y clientes:

# Estructura de items en una sola tabla
{
  "PK": "CUSTOMER#123",
  "SK": "PROFILE",
  "name": "Juan Pérez",
  "email": "juan@example.com",
  "created": "2024-01-15"
}
 
{
  "PK": "CUSTOMER#123", 
  "SK": "ORDER#456",
  "total": 99.99,
  "status": "shipped",
  "items": ["product-a", "product-b"]
}
 
{
  "PK": "ORDER#456",
  "SK": "METADATA", 
  "customer_id": "123",
  "shipping_address": "...",
  "payment_method": "card"
}

Este patrón permite queries eficientes:

• Obtener perfil del cliente: PK = CUSTOMER#123 AND SK = PROFILE
• Obtener todas las órdenes del cliente: PK = CUSTOMER#123 AND SK begins_with ORDER#
• Obtener detalles de una orden: PK = ORDER#456 AND SK = METADATA

Índices secundarios

Global Secondary Index (GSI)

Permite queries por atributos diferentes a la primary key. Cada GSI tiene su propia partition key y sort key, con capacidad de throughput independiente.

Cuándo usar GSI:

• Necesitas query por atributos que no son la primary key
• Los patrones de acceso requieren diferentes distribuciones de datos
• Puedes tolerar eventual consistency (GSIs son eventually consistent)

Local Secondary Index (LSI)

Comparte la misma partition key que la tabla base pero usa una sort key diferente. Limitado a 10GB por partición.

Cuándo usar LSI:

• Necesitas strong consistency en queries alternativas
• Los datos por partición no exceden 10GB
• Quieres ordenar por un atributo diferente manteniendo la misma partition key

DynamoDB Streams y arquitecturas event-driven

DynamoDB Streams captura cambios en tiempo real (INSERT, MODIFY, DELETE) y los envía a AWS Lambda o Kinesis. Cada stream record contiene:

{
  "eventName": "INSERT",
  "dynamodb": {
    "Keys": {"PK": {"S": "ORDER#456"}},
    "NewImage": {"status": {"S": "created"}, "total": {"N": "99.99"}},
    "StreamViewType": "NEW_AND_OLD_IMAGES"
  }
}

Patrones comunes:

• Event sourcing: cada cambio genera eventos para otros servicios
• Cache invalidation: actualizar caches cuando cambian los datos
• Analytics: enviar cambios a data warehouses
• Notifications: trigger emails o push notifications

Patrones de acceso y optimización

Query vs Scan

• Query: acceso eficiente usando partition key (y opcionalmente sort key)
• Scan: examina todos los items — costoso y lento, evitar en producción

Filter expressions y paginación

import boto3
 
dynamodb = boto3.resource('dynamodb')
table = dynamodb.Table('ecommerce')
 
# Query con filtro
response = table.query(
    KeyConditionExpression=Key('PK').eq('CUSTOMER#123'),
    FilterExpression=Attr('status').eq('active'),
    Limit=10
)
 
# Paginación
while 'LastEvaluatedKey' in response:
    response = table.query(
        KeyConditionExpression=Key('PK').eq('CUSTOMER#123'),
        ExclusiveStartKey=response['LastEvaluatedKey'],
        Limit=10
    )

TTL y estrategias de backup

Time to Live (TTL): expira items automáticamente usando un timestamp Unix.

# Configurar TTL en un atributo
table.meta.client.update_time_to_live(
    TableName='sessions',
    TimeToLiveSpecification={
        'AttributeName': 'expires_at',
        'Enabled': True
    }
)

Estrategias de backup:

• Point-in-Time Recovery (PITR): restauración continua hasta 35 días
• On-demand backups: snapshots manuales para retención a largo plazo
• Cross-region replication: Global Tables para disaster recovery

Comparación de costos: on-demand vs provisioned

Factores clave:

• On-demand: 25% más caro por request, pero sin compromisos
• Provisioned: requiere planificación, pero 60-70% más barato para cargas estables
• Auto Scaling en provisioned puede mitigar picos, pero con latencia de ajuste

Ejemplo de código: creación con Terraform

resource "aws_dynamodb_table" "ecommerce" {
  name           = "ecommerce"
  billing_mode   = "PAY_PER_REQUEST"
  hash_key       = "PK"
  range_key      = "SK"
 
  attribute {
    name = "PK"
    type = "S"
  }
 
  attribute {
    name = "SK" 
    type = "S"
  }
 
  attribute {
    name = "GSI1PK"
    type = "S"
  }
 
  global_secondary_index {
    name     = "GSI1"
    hash_key = "GSI1PK"
    projection_type = "ALL"
  }
 
  stream_enabled   = true
  stream_view_type = "NEW_AND_OLD_IMAGES"
 
  point_in_time_recovery {
    enabled = true
  }
 
  tags = {
    Environment = "production"
    Service     = "ecommerce"
  }
}

¿Por qué importa?

DynamoDB representa un cambio fundamental en el diseño de bases de datos para aplicaciones serverless. Su modelo de pricing por request elimina la necesidad de provisionar capacidad, pero requiere un diseño cuidadoso del schema basado en patrones de acceso específicos.

Para equipos que migran desde bases de datos relacionales, DynamoDB exige repensar la normalización — el single-table design puede parecer contraintuitivo, pero es esencial para minimizar costos y latencia. La ausencia de JOINs significa que la desnormalización y la duplicación de datos son estrategias válidas.

El ecosistema de event-driven architecture se beneficia enormemente de DynamoDB Streams, permitiendo arquitecturas reactivas que escalan automáticamente sin gestión de infraestructura.

Referencias

• Amazon DynamoDB Developer Guide — AWS, 2024. Documentación oficial completa.
• The DynamoDB Book — Alex DeBrie, 2021. Guía definitiva de modelado de datos y patrones.
• DynamoDB Pricing — AWS, 2024. Calculadora de costos y comparación de modos.
• Best Practices for DynamoDB — AWS, 2024. Patrones de diseño y optimización.
• DynamoDB Streams and Lambda — AWS, 2024. Integración para arquitecturas event-driven.
• Single Table Design with DynamoDB — Alex DeBrie, 2019. Explicación detallada del patrón single-table.