Capacidad adaptativa de DynamoDB
DynamoDB reparte tu tabla a lo largo de particiones, pero tu tráfico rara vez se reparte de forma uniforme. La capacidad de ráfaga y la capacidad adaptativa son los dos mecanismos automáticos que impiden que una carga de trabajo sesgada throttlee — hasta que choca con un límite duro.
¿Qué es la capacidad adaptativa de DynamoDB?
La capacidad adaptativa de DynamoDB es un mecanismo automático que desplaza el throughput sin usar hacia una para que una clave sesgada no throttlee mientras el resto de la tabla está ociosa. Junto con la capacidad de ráfaga, absorbe picos y sesgo sostenido sin coste — pero no puede empujar una sola clave más allá del techo de partición.
- La capacidad de ráfaga te presta hasta 5 minutos (300 segundos) de throughput sin usar para aguantar picos cortos. Es un buffer, no una feature que ajustas.
- La capacidad adaptativa eleva automáticamente el throughput de una partición "caliente" — tirando del resto de la capacidad sin usar de tu tabla — para que una clave sesgada no throttlee.
- Incluso aislará un item caliente en su propia partición, dando a una sola clave hasta el techo de partición de 3.000 RCU / 1.000 WCU.
- No es licencia para ignorar el diseño de claves. Pasado el techo por partición no queda nada de donde pedir prestado — una clave verdaderamente caliente igual throttlea.
Conoce primero el techo de partición
Cada partición está topada de forma independiente: 3.000 unidades de lectura y 1.000 unidades de escritura por segundo. Ese límite es físico, no provisionado — se sostiene tanto en tablas provisionadas como bajo demanda. (AWS, Burst and adaptive capacity.)
Viniendo de SQL, razonas sobre la carga total del servidor. En DynamoDB la unidad que throttlea es la partición individual, y una sola clave sesgada puede fundirse mientras la tabla está al 90% ociosa. Esa es la brecha que ambos mecanismos existen para cerrar.
La capacidad de ráfaga absorbe el pico corto
Siempre que no uses por completo el throughput de una partición, DynamoDB guarda el sobrante. Hasta 300 segundos de esa capacidad sin usar se mantienen en reserva, y una ráfaga repentina puede drenarla más rápido de lo que tu tasa por segundo permitiría normalmente.
Es invisible y automática. No puedes dimensionarla, y DynamoDB puede gastar parte de ella en silencio en su propio trabajo de fondo. Trátala como un cojín para tráfico de ráfagas — nunca como margen contra el que puedas planificar.
La capacidad adaptativa impulsa la partición caliente
La capacidad de ráfaga maneja picos cortos. La capacidad adaptativa maneja el sesgo sostenido. Cuando una partición corre caliente mientras sus vecinas están ociosas, DynamoDB desplaza throughput hacia la caliente — hasta el total de la tabla y el techo de partición.
Digamos que ejecutas una tabla de telemetría de flota con clave VEHICLE#<id>
(partición) y TS#<epoch> (ordenación). Una furgoneta de reparto en una zona de
oferta flash emite 10× los pings de cualquier otra. Su partición está caliente; las
particiones de las otras 200 furgonetas están casi ociosas.
La capacidad adaptativa lo nota y eleva el throughput de esa única partición, tirando de la capacidad sin usar de las particiones frías. Sin config, sin coste, sin calentamiento — desde mayo de 2019 el impulso es efectivamente instantáneo. (AWS Database Blog, "How DynamoDB adaptive capacity accommodates uneven access patterns".)
La partición de la furgoneta caliente necesita 150 WCU pero su parte equitativa de 100 WCU throttlearía; la capacidad adaptativa pide prestada la WCU ociosa de las particiones frías para cubrirla.
Aislamiento: cuando un solo item es el problema
El sesgo no siempre es por clave — a veces un solo item está al rojo vivo. Si un
tráfico implacable conduce un item VEHICLE#HOT, el mecanismo split-for-heat de
DynamoDB reequilibra las particiones para que el item accedido con frecuencia
aterrice solo.
Una vez aislado, la clave de ese único item puede tirar del techo de partición completo: 3.000 RCU y 1.000 WCU. Ese es el tope absoluto para una clave — no hay mecanismo por encima de él. (AWS, Key range throughput exceeded.)
Una advertencia que merece fijarse: la capacidad adaptativa no dividirá una colección de items entre particiones cuando la tabla tiene un Local Secondary Index. Un LSI ata la colección a una partición — consulta GSI vs LSI para entender por qué.
Cuándo la capacidad adaptativa no puede salvarte
Esta es la trampa. Ambos mecanismos mueven throughput de un lado a otro; ninguno crea más de lo que una partición permite físicamente.
| Escenario | Ráfaga | Adaptativa | Resultado |
|---|---|---|---|
| Pico corto, la tabla tiene holgura | Lo cubre | — | Sin throttle |
| Sesgo sostenido, vecinas frías | — | Impulsa la caliente | Sin throttle |
| Un item, < 3K RCU / 1K WCU | — | Lo aísla | Sin throttle |
| Un item, > techo de partición | Drenada rápido | En el tope | Throttleado — rediseño necesario |
| Muchas claves calientes a la vez, tabla al máximo | Drenada rápido | Nada ocioso | Throttleado — rediseño necesario |
Si una sola clave legítimamente necesita más de 1.000 escrituras por segundo, ningún mecanismo automático te rescata — debes repartir la carga a través de más claves.
El sharding de escritura es la solución habitual: añade un sufijo
(VEHICLE#HOT#0 … #9) para que las escrituras se abaniquen a través de
particiones, luego abanica las lecturas de vuelta.
Ese abanico de vuelta es en sí un patrón de acceso a modelar deliberadamente, igual que planificarías un camino de query en diseño de tabla única — la capacidad adaptativa compra tiempo, no un pase libre en el diseño de claves.
Míralo en tu propia tabla
La capacidad adaptativa es invisible por diseño, así que razonas sobre ella a través
de un síntoma: qué claves están calientes. Cuando construyas el camino de escritura
fragmentado, el constructor de expresiones
genera la sintaxis de PutItem y Query para una clave con sufijo.
Para observar cómo una clave se distribuye realmente a lo largo de tus datos, descarga DynoTable e inspecciona el reparto de particiones en tus tablas reales antes de asumir que la capacidad adaptativa lo tiene cubierto. Para el lado de lectura del sesgo, consulta Query vs Scan.