Particiones calientes en DynamoDB

DynamoDB reparte tus datos entre muchas particiones físicas, cada una con su propia porción de rendimiento. Una partición caliente ocurre cuando una clave atrae muchas más lecturas o escrituras de las que su porción puede atender, así que las peticiones a esa clave se throttlean mientras el resto de la tabla está inactivo.

¿Qué es una partición caliente en DynamoDB?

Una partición caliente en DynamoDB ocurre cuando una clave de partición absorbe muchas más lecturas o escrituras de las que su porción de rendimiento puede atender, así que las peticiones a esa clave se throttlean mientras el resto de la tabla está inactivo. La causa es el diseño de la clave —un item famoso, una clave de baja cardinalidad, la fecha de hoy—, no el tamaño de la tabla. La cura es repartir las escrituras.

• La causa es el diseño de la clave, no el tamaño de la tabla. Una clave de partición que concentra el tráfico — un usuario famoso, un flag status="OPEN", la fecha de hoy — es la trampa.
• La capacidad adaptativa ayuda, pero no es una solución. DynamoDB reequilibra el calor automáticamente, pero un solo item o una sola clave puede superar lo que una partición es capaz de atender.
• La cura es repartir las escrituras. Añade entropía a la clave (write sharding) o mueve la ruta de lectura caliente a un patrón de acceso mejor distribuido.
• Si vienes de SQL, esto no tiene equivalente. Una tabla relacional no tiene la noción de "el valor de índice de una fila es demasiado popular" — el modelo plano de rendimiento por clave de DynamoDB sí.

Por qué existen las particiones

DynamoDB es el heredero en producción del paper Amazon Dynamo de 2007, que cambió el modelo SQL de un solo nodo por uno particionado y escalado horizontalmente. Los datos se reparten por un hash de la clave de partición entre los nodos de almacenamiento físicos.

Cada partición contiene una cantidad acotada de datos y atiende una cantidad acotada de rendimiento. AWS documenta un techo duro de 3.000 unidades de lectura y 1.000 unidades de escritura por partición, por segundo (AWS — comportamiento de las particiones).

Ese techo es toda la historia. El rendimiento aprovisionado de tu tabla es la suma entre todas las particiones — pero cualquier clave individual solo aterriza en una partición.

Pon nombre a la trampa: tráfico que se amontona sobre una clave

El rendimiento se comparte de forma equitativa solo si tu acceso se reparte de forma equitativa entre las claves. En el momento en que una clave recibe tráfico desproporcionado, se throttlea sola mientras la capacidad global de la tabla queda sin usar.

Formas clásicas de clave caliente:

• Un item famoso — un usuario, producto o tenant que todo el mundo lee.
• Una clave de partición de baja cardinalidad — status, country, type. Pocos valores distintos significan pocas particiones haciendo todo el trabajo.
• Una clave agrupada por tiempo — PK = "2026-06-23". Cada escritura de hoy martillea una partición; la de ayer queda fría para siempre.

Si vienes de SQL, nada de esto importaría. Un índice B-tree sobre un valor popular está bien. En DynamoDB el valor popular es la unidad de ubicación física, así que la popularidad se convierte en un precipicio de rendimiento.

Un ejemplo trabajado: el ranking del famoso

Supón que gestionas un ranking global de videojuegos. Las puntuaciones viven en una tabla con claves así:

PK = "BOARD#global"
SK = "PLAYER#<playerId>"

Las lecturas obtienen los N mejores por puntuación; las escrituras suben el currentScore de un jugador tras cada partida. Cada fila del ranking global comparte una sola clave de partición — BOARD#global — así que cada lectura y escritura aterriza en una única partición.

Añade un streamer con dos millones de espectadores en directo machacando el botón de refrescar sobre su propio puesto, y esa única partición sobrepasa las 3.000 unidades de lectura. Obtienes ProvisionedThroughputExceededException en el ranking global mientras todos los demás rankings de la tabla están inactivos.

El error de diseño es el colapso de BOARD#global: modelaste un único ranking lógico como una única clave física.

Reparte las escrituras: sharding de la clave

La solución es fabricar cardinalidad. Añade un sufijo de shard a la clave de partición para que un ranking lógico se abra en abanico entre N particiones físicas:

PK = "BOARD#global#<shard>"  -- shard = playerId mod 10
SK = "PLAYER#<playerId>"

Las escrituras ahora se dispersan entre diez particiones en lugar de una — diez veces el margen de escritura. El coste: una lectura de todo el ranking debe llegar a los diez shards y mezclarlos, porque ningún Query individual cruza los límites de shard. Cambias simplicidad de lectura por distribución de escritura.

AWS llama a esto write sharding y lo recomienda precisamente para claves de alta velocidad y baja cardinalidad (AWS — usar write sharding).

Este es el mismo instinto de key overloading que hay detrás del single-table design — moldeas la clave para el patrón de acceso, no para cómo se "asientan naturalmente" los datos.

Deja que la capacidad adaptativa haga la parte fácil

DynamoDB incluye capacidad adaptativa, tratada en la sesión de re:Invent 2018 "Amazon DynamoDB Under the Hood" (DAT401). Redistribuye continuamente el rendimiento de una tabla hacia las particiones que reciben el calor, y aislará una clave caliente de forma persistente en su propia partición (aislamiento a nivel de clave, AWS — bursting y capacidad adaptativa).

Es instantánea y gratuita — pero está acotada por la física. La capacidad adaptativa puede mover calor entre claves; no puede empujar una sola clave más allá del techo por partición. Una clave verdaderamente famosa sigue throttleándose. El sharding es lo que te lleva más allá de ese muro.

Aquí está la ruta de decisión una vez que ves throttling en una clave concurrida:

La mayoría de las particiones calientes se resuelven con "shardea la clave" o "deja que la capacidad adaptativa lo absorba" — el diagrama solo indica en qué rama estás.

Diagnostícala antes de rediseñar

No puedes arreglar lo que no puedes ver. El throttling aparece como ProvisionedThroughputExceededException (aprovisionado) o como ThrottledRequests y el ThrottleCount por partición en CloudWatch (AWS — métricas de CloudWatch).

Combínalo con CloudWatch Contributor Insights para DynamoDB, que clasifica tus claves más accedidas directamente — la forma más rápida de confirmar una clave famosa por su nombre (AWS — Contributor Insights).

Cuando estés probando la ruta de lectura shardeada, estarás construyendo a mano el KeyConditionExpression para cada shard. Genéralos sin erratas con el DynamoDB Expression Builder — emite la forma exacta PK = :pk AND begins_with(SK, :sk) por shard.

Trampas que evitar

• Claves autoincrementales o monótonas. Los IDs secuenciales y las marcas de tiempo como clave de partición enrutan escrituras consecutivas a la misma partición. Añade un prefijo de hash.
• Shardear la ruta intensiva en lecturas sin necesidad. Si las lecturas dominan y el item es pequeño, una caché o un GSI con una clave mejor distribuida a menudo gana al coste de lectura scatter-gather del sharding.
• Confundir una partición caliente con un Scan lento. Un Scan es lento porque lo lee todo; una partición caliente se throttlea porque una clave está sobrecargada. Problemas distintos — ver Query vs Scan.

Próximos pasos

Esboza las claves shardeadas, luego prueba la ruta de lectura contra datos reales. Construye las condiciones por shard en el DynamoDB Expression Builder, y descarga DynoTable para ejecutarlas contra tus propias tablas y observar qué particiones reciben realmente el calor.