Adaptive Capacity en DynamoDB: qué hace y qué no
DynamoDB reparte tu tabla entre 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 provoque throttling — hasta que alcanza un límite estricto.
¿Qué es la capacidad adaptativa de DynamoDB?
La capacidad adaptativa de DynamoDB es un mecanismo automático que desplaza el rendimiento sin usar hacia una para que una clave sesgada no provoque throttling mientras el resto de la tabla está ociosa. Junto con la capacidad de ráfaga, absorbe picos y sesgos sostenidos gratis — pero no puede empujar una sola clave más allá del techo de la partición.
- La capacidad de ráfaga te presta hasta 5 minutos (300 segundos) de rendimiento sin usar para sortear picos cortos. Es un colchón, no una función que ajustas.
- La capacidad adaptativa eleva automáticamente el rendimiento de una — tomándolo de la capacidad sin usar del resto de tu tabla — para que una clave sesgada no provoque throttling.
- Incluso aísla un Item caliente en su propia partición, dando a una sola clave hasta el techo de la partición de 3000 RCU / 1000 WCU.
- No es una licencia para ignorar el diseño de claves. Pasado el techo por partición no queda nada de donde tomar prestado — una clave realmente caliente sigue provocando throttling.
Conoce primero el techo de la partición
Cada partición tiene un tope independiente: 3000 unidades de lectura y 1000 unidades de escritura por segundo. Ese límite es físico, no aprovisionado — se mantiene tanto en tablas provisioned como on-demand. (AWS, Capacidad de ráfaga y adaptativa.)
Viniendo de SQL, razonas sobre la carga total del servidor. En DynamoDB la unidad que provoca throttling 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 del todo el rendimiento de una partición, DynamoDB guarda lo que sobra. Se mantienen en reserva hasta 300 segundos de esa capacidad sin usar, y una ráfaga repentina puede vaciarla 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 algo de ella en silencio en su propio trabajo en segundo plano. Trátala como un cojín para el tráfico irregular — nunca como margen con 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 se calienta mientras sus vecinas están ociosas, DynamoDB desplaza rendimiento hacia la caliente — hasta el total de la tabla y el techo de la 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 venta relámpago 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 detecta y eleva el rendimiento de esa partición, tomándolo de la capacidad sin usar de las particiones frías. Sin configuración, 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 reparto equitativo de 100 WCU provocaría throttling; la capacidad adaptativa toma prestadas las WCU ociosas de las particiones frías para cubrirlo.
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 golpea un Item VEHICLE#HOT, la división por calor 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 completo de la partición: 3000 RCU y 1000 WCU. Ese es el tope absoluto para una clave — no hay mecanismo por encima de él. (AWS, Rendimiento de rango de claves superado.)
Una advertencia que conviene fijar: la capacidad adaptativa no dividirá una entre particiones cuando la tabla tiene un . Un LSI ata la colección a una partición — consulta GSI frente a LSI para saber por qué.
Cuándo la capacidad adaptativa no puede salvarte
Esta es la trampa. Ambos mecanismos mueven el rendimiento de un sitio 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 throttling |
| Sesgo sostenido, vecinas frías | — | Impulsa la caliente | Sin throttling |
| Un Item, < 3K RCU / 1K WCU | — | Lo aísla | Sin throttling |
| Un Item, > techo de partición | Se vacía rápido | En el tope | Throttling — hace falta rediseño |
| Muchas claves calientes a la vez, tabla al máximo | Se vacía rápido | Nada ocioso | Throttling — hace falta rediseño |
Si una sola clave necesita legítimamente más de 1000 escrituras por segundo, ningún mecanismo automático te rescata — debes repartir la carga entre más claves.
El sharding de escritura es el arreglo habitual: añade un sufijo (VEHICLE#HOT#0 … #9)
para que las escrituras se abran en abanico entre particiones, y luego reúne las lecturas de
vuelta.
Esa reunión es en sí misma un patrón de acceso que hay que modelar deliberadamente, igual que planificarías una ruta de consulta en el diseño de tabla única — la capacidad adaptativa compra tiempo, no una vía 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 la ruta de escritura con sharding, el
generador de expresiones genera la sintaxis de PutItem
y Query para una clave con sufijo.
Para observar cómo se distribuye realmente una clave en tus datos, descarga DynoTable y ejecuta un GROUP BY sobre tu clave de partición en el SQL Workbench para ver cómo se apilan los Items por clave antes de dar por sentado que la capacidad adaptativa lo tiene cubierto. Para el lado de lectura del sesgo, consulta Query frente a Scan.