Particiones físicas de DynamoDB

Una partición física es la unidad sobre la que DynamoDB almacena realmente tus datos: un trozo de SSD, replicado a través de zonas de disponibilidad, que contiene un trozo de tu espacio de claves. Tu tabla es algo lógico. Las particiones son donde los bytes — y los límites de throughput — realmente viven.

¿Cómo funcionan las particiones de DynamoDB?

DynamoDB distribuye tu tabla en particiones físicas: trozos de SSD replicados entre zonas de disponibilidad. Cada partición tiene un tope de ~10 GB, 3.000 unidades de lectura/s y 1.000 unidades de escritura/s. El hash de tu clave de partición decide en qué partición cae cada item, y DynamoDB divide las particiones automáticamente a medida que crecen o se calientan.

• Cada partición tope en ~10 GB de almacenamiento, 3.000 unidades de lectura/s y 1.000 unidades de escritura/s. Esos techos son por partición, no por tabla.
• El hash de tu clave de partición elige la partición. Los items con la misma clave aterrizan juntos; una hot key significa una partición caliente.
• DynamoDB divide las particiones por ti — por tamaño, y por calor sostenido — pero no puede arreglar una clave que canaliza todo el tráfico a un solo sitio.
• Throttlear con capacidad de sobra es la señal. Un error ProvisionedThroughputExceeded mientras tu tabla está al 5% de uso significa que una sola partición está al máximo.

Cómo un item encuentra su partición

DynamoDB pasa el valor de tu clave de partición por una función hash interna. La salida del hash elige la partición física. Misma clave dentro, misma partición fuera — cada vez.

Viniendo de SQL, no hay analogía. No hay B-tree de índice que ajustes, ni shard key que asignes a mano. La colocación es un hash que no controlas y nunca ves.

Los items que comparten una clave de partición forman una colección de items, almacenados juntos y ordenados por clave de ordenación. Eso es lo que hace barata una Query sobre una clave — lee una serie contigua en una partición. (Consulta Query vs Scan.)

Toma un almacén de eventos de partida para un juego. Las claves de la tabla son arenaId (partición) y eventKey (ordenación):

# Item
arenaId    = "ARENA#7f3a"
eventKey   = "EVT#1719100800#a91c"
playerTag  = "Nightjar"
dmgDealt   = 412

Cada evento de la arena 7f3a hashea a la misma partición y se apila en orden de clave de ordenación. Genial para "leer la línea de tiempo de esta partida". Un riesgo si esa única arena recibe todo el tráfico.

Los tres techos que cada partición impone

Una sola partición está diseñada para entregar como mucho:

Fuente: la guía de AWS Best practices for designing partition keys.

El tamaño del item escala el cálculo. Un item de 20 KB cuesta 5 unidades de lectura por lectura fuertemente consistente, así que una partición sirve ~600 de esas lecturas/s antes de throttlear — no 3.000. Redondea el coste de escritura hacia arriba por cada 1 KB, el coste de lectura por cada 4 KB.

La trampa: estos son límites de partición, no de tabla. Tu tabla puede estar provisionada para 40.000 WCU y aún throttlear, porque todas las escrituras están aporreando una partición que tope en 1.000.

Cómo se dividen las particiones

DynamoDB añade particiones automáticamente en dos casos. Nunca ejecutas un comando.

División por tamaño. Cuando una partición se llena hacia ~10 GB, DynamoDB divide su rango de claves en dos y mueve la mitad de los items a una nueva partición. El almacenamiento crece de forma transparente; tus lecturas y escrituras siguen funcionando todo el tiempo.

División por calor. Cuando una partición recibe tráfico sostenido cerca de su techo de throughput, DynamoDB divide el rango de claves caliente de forma que cada mitad aterrice en su propia partición. AWS llama a esto el mecanismo split-for-heat. Ráfagas cortas de throttling que se detienen solas suelen significar que una división acaba de ocurrir.

Dividir compra espacio a través de muchas claves, pero el nodo de abajo es la pega: una división divide un rango de claves, nunca una sola clave.

Por qué una hot key vence al divisor

Aquí está el footgun. Dividir redistribuye rangos de claves de partición. Si tu tráfico se concentra en un valor de clave, cada petición hashea a la misma partición, y no queda rango que dividir.

Si la arena 7f3a es una final de torneo que tira de 4.000 escrituras/s mientras todas las demás arenas están ociosas, throttlearás a 1.000 — y una división no puede ayudar, porque las 4.000 comparten una clave. La razón de throttle más reciente, KeyRangeThroughputExceeded, nombra exactamente esto: el rango de claves de una partición, no la tabla, está por encima de su límite.

La solución está en el modelo de datos, no en el deslizador de capacidad. Fragmenta la escritura de la hot key: añade un pequeño sufijo de forma que una arena lógica se reparta a través de N particiones físicas.

arenaId = "ARENA#7f3a#3"   # shard 0..9, chosen per write

Las lecturas entonces se abanican a través de los shards y se mezclan en cliente. Puedes prototipar las formas de clave y la Query para cada shard con el constructor de expresiones de DynamoDB antes de tocar una línea de código de aplicación.

Un matiz: la excepción del LSI

Hay un caso donde el almacenamiento sí está topado por clave de partición. Sin un Local Secondary Index, una colección de items se auto-divide a través de tantas particiones como necesite — miles de millones de valores de clave de ordenación están bien.

Añade un LSI, y toda la colección de una clave de partición debe caber en una sola partición de 10 GB, porque el LSI la comparte. Ese es el precipicio por-PK cubierto en GSI vs LSI — otra razón por la que la mayoría de equipos recurre a los GSIs.

Diseñar para que las particiones se mantengan frescas

La palanca que de verdad controlas es la clave de partición. Elige una con muchos valores distintos respecto al conteo de filas, de forma que el tráfico se reparta uniformemente. (Más patrones en diseño de tabla única.)

• Clave de alta cardinalidad. Una clave por usuario o por tenant le gana a una clave por día o por estado que todos aporrean a la vez.
• Vigila las hot keys conocidas. Un valor de "torneo actual" o "hoy" es un riesgo de concentración antes de que envíes, no después.
• Fragmenta la hot key inevitable. Cuando una clave debe llevar tráfico desmesurado, un sufijo es la vía de escape estándar.

Throttlear con capacidad de sobra es tu señal de que una partición está caliente. Inspecciona los items ofensivos y ensaya una disposición de clave fragmentada en DynoTable — apúntalo a tu propia tabla, encuentra la clave que está sobrecargada y modela la solución antes de que te despierte de madrugada.