No hay nada más frustrante en la gestión de una Base de datos AWS que ver métricas de ProvisionedThroughputExceededException inundando tus logs mientras tu tabla está apenas al 20% de su capacidad total provisionada. Si has escalado tus WCUs (Write Capacity Units) y el error persiste, no es un problema de capacidad global: tienes un Problema Hot Partition.
El Diagnóstico: Por qué falla el Auto-Scaling
En un Diseño DynamoDB estándar, confiamos en que el hash de la Partition Key (PK) distribuya la carga uniformemente. Sin embargo, en eventos de alto tráfico (como una venta flash o una cola de logs masiva), es común que miles de clientes intenten escribir sobre el mismo PK (ej: CAMPAIGN#101 o STATUS#PENDING) simultáneamente.
DynamoDB tiene un límite físico estricto por partición (aproximadamente 1,000 WCUs o 3,000 RCUs). Si todo tu tráfico golpea una sola partición lógica, ninguna cantidad de auto-scaling global te salvará. Esto es un fallo clásico de Modelado NoSQL.
La Solución: Implementando Write Sharding
Para solucionar esto, debemos romper la concentración de tráfico utilizando una técnica llamada Write Sharding. En lugar de escribir todo en PK=CAMPAIGN#101, añadimos un sufijo aleatorio o calculado al final de la clave para distribuirlo entre N particiones lógicas.
A continuación, muestro la implementación que utilizamos para mitigar un pico de 50k escrituras/segundo en nuestro sistema de ingestión de eventos:
import random
import boto3
from botocore.exceptions import ClientError
dynamodb = boto3.resource('dynamodb')
table = dynamodb.Table('HighVelocityEvents')
# Configuración de Sharding
SHARD_COUNT = 20 # Ajustar según el throughput estimado
def put_sharded_item(campaign_id, event_data):
# Generamos un sufijo aleatorio entre 1 y N
shard_suffix = random.randint(1, SHARD_COUNT)
# Construimos la Partition Key compuesta (Sharded Key)
# Antes: "CAMPAIGN#101" -> Hot Partition segura
# Ahora: "CAMPAIGN#101#14" -> Carga distribuida
partition_key = f"CAMPAIGN#{campaign_id}#{shard_suffix}"
try:
table.put_item(
Item={
'PK': partition_key,
'SK': event_data['timestamp'],
'Payload': event_data['payload'],
# Guardamos el ID original para GSI si es necesario
'OriginalCampaignId': f"CAMPAIGN#{campaign_id}"
}
)
except ClientError as e:
print(f"Error escribiendo en DynamoDB: {e}")
# Uso en producción
put_sharded_item("101", {"timestamp": "2023-10-27T10:00:00Z", "payload": "{...}"})Cómo leer los datos distribuidos (Scatter-Gather)
El Write Sharding resuelve la escritura, pero complica la lectura. Ya no puedes hacer un simple Query por el ID de la campaña. Tienes dos estrategias principales según la documentación de Best Practices de DynamoDB:
- Scatter-Gather: La aplicación lanza
Nqueries en paralelo (una para cada sufijo) y une los resultados en memoria. Es rápido pero costoso en términos de latencia de red. - Global Secondary Index (GSI): Usar un GSI con una clave de partición diferente para agregar los datos de manera asíncrona.
| Estrategia | Escritura (Throughput) | Complejidad de Lectura | Caso de Uso |
|---|---|---|---|
| PK Única | Limitada (~1000 WCU) | Baja | Baja concurrencia, catálogos |
| Write Sharding | Ilimitada (Lineal con N) | Alta (Scatter-Gather) | Logs, Votaciones, IoT Streams |
Conclusión
El Problema Hot Partition es un cuello de botella silencioso que no se resuelve lanzando dinero a la capacidad provisionada. La única salida viable en entornos de hiperescala es un rediseño del esquema. Implementar Write Sharding añade complejidad a la capa de aplicación, pero es absolutamente necesario para garantizar la resiliencia y evitar el throttling en una Base de datos AWS de alto rendimiento.
Post a Comment