Cómo funcionan las claves de partición de DynamoDB
Tu clave de partición no es una columna — es una dirección. DynamoDB hashea esa clave y el hash decide qué máquina física almacena el item. Elige bien la clave y la carga se reparte; elígela mal y un servidor se lleva todo el calor.
¿Cómo funcionan las claves de partición de DynamoDB?
DynamoDB pasa tu clave de partición por una función hash interna, y ese hash decide qué partición física almacena el item. La clave no se ordena ni indexa como una columna SQL — es una dirección. Elige una clave de alta cardinalidad y la carga se reparte entre muchas particiones; elige una de baja cardinalidad y una sola partición absorbe todo el tráfico.
- La clave se hashea, no se ordena. DynamoDB pasa tu clave de partición por un hash interno para elegir una partición. Dos valores adyacentes aterrizan en sitios lejanos en disco.
- Una partición es una unidad de almacenamiento real. Cada una tope alrededor de 10 GB, 3.000 unidades de lectura/s y 1.000 unidades de escritura/s. Tu tráfico se divide por cuántas particiones cubren tus claves.
- Las hot keys son el footgun. Canaliza la mayoría de las peticiones a un solo valor de clave de partición y throttleas en esa partición mientras el resto de la tabla está ociosa.
- Las claves de alta cardinalidad ganan. Cuantos más valores de clave distintos y golpeados uniformemente tengas, más particiones absorben la carga.
Empieza por lo que realmente hace la clave
Viniendo de SQL, una clave primaria es una columna ordenada e indexada sobre la que
haces JOIN y ORDER BY. En DynamoDB la clave de partición (a veces llamada
hash key) hace algo distinto: decide la colocación.
DynamoDB alimenta la clave de partición a una función hash interna. La salida mapea a un espacio de claves, y el espacio de claves se corta en rangos — cada rango propiedad de una partición física. Esa partición es almacenamiento real en un nodo real.
Así que la clave de partición responde a una pregunta: ¿qué máquina guarda este item? La clave de ordenación, si la tienes, solo ordena los items dentro de esa máquina. No juega ningún papel en la colocación.
Sigue una escritura a través del hash
Digamos que ejecutas un SaaS que ingiere lecturas de dispositivos. Tu tabla
SensorReadings usa una clave de partición deviceId y una clave de ordenación
readingTs. Escribes una lectura para deviceId = "vac-7741".
Aquí está el camino que toma esa escritura — desde tu clave hasta el disco en el que aterriza:
La escritura para vac-7741 se hashea a un punto del espacio de claves, ese punto
cae en el rango de P2, y el item aterriza en P2 — ordenado allí por readingTs.
Lo que hay que interiorizar: "vac-7741" y "vac-7742" están a un carácter de
distancia, pero sus hashes no tienen relación. Casi con certeza viven en particiones
diferentes. No hay "cerca" en el espacio de claves de partición.
Esta es la idea de hashing consistente que DynamoDB heredó del diseño original — el paper de Amazon Dynamo de 2007 ("Dynamo: Amazon's Highly Available Key-value Store") repartía claves entre nodos hasheando exactamente para que ningún nodo se convirtiera en cuello de botella.
Respeta los límites duros de la partición
Una partición física es finita. Según la AWS DynamoDB Developer Guide, cada una contiene hasta aproximadamente:
| Límite | Por partición |
|---|---|
| Almacenamiento | ~10 GB |
| Throughput de lectura | 3.000 unidades de lectura/s |
| Throughput de escritura | 1.000 unidades de escritura/s |
Cuando una partición se llena más allá de 10 GB, o tu throughput provisionado necesita más espacio, DynamoDB la divide — el rango del espacio de claves se divide y los items se redistribuyen a lo largo de más particiones. Esto es automático; tú no lo disparas.
La trampa: una división reparte items por su hash. Si cada petición caliente apunta a un solo valor de clave de partición, dividir no ayuda — todo ese tráfico sigue hasheando al mismo punto. No puedes dividir la carga de una sola clave entre particiones.
Nombra la trampa: la partición caliente
Una partición caliente es el footgun clásico. Ocurre cuando un valor de clave de partición (o un conjunto diminuto de ellos) absorbe una porción desproporcionada del tráfico.
Fallo concreto: cambias SensorReadings a una clave de partición region con
valores como "us-east", "eu-west". Tres regiones significa tres valores de clave
significa — como mucho — tres particiones haciendo trabajo real. Aporrea "us-east"
con lecturas y throttlea a 3.000 RCU mientras la capacidad total provisionada de la
tabla queda sin usar.
La capacidad adaptativa de DynamoDB suaviza esto — puede desplazar throughput sin usar hacia una partición ocupada, y aislar una sola clave muy caliente en su propia partición. AWS lo detalló en las sesiones de profundización "Advanced Design Patterns for DynamoDB" de re:Invent. Pero la capacidad adaptativa compra tiempo, no inmunidad: no puede subdividir la carga de una clave individual. Diseña para el reparto; no te apoyes en la red de seguridad.
Elige una clave de alta cardinalidad
La solución es la cardinalidad — el número de valores de clave distintos, y cuán uniformemente los golpea el tráfico.
- Baja cardinalidad (
region,status,true/false): pocas particiones, el tráfico se concentra, throttleas pronto. - Alta cardinalidad (
deviceId,userId, un order ID): muchos valores hasheando a través de muchas particiones, la carga se reparte, el margen crece.
Viniendo de SQL indexarías felizmente una columna status y filtrarías por ella.
Como clave de partición de DynamoDB eso es una trampa — no puede repartir.
Mantén los atributos de baja cardinalidad como filtros o como la clave de ordenación
de un índice secundario, nunca como lo que decide la
colocación.
Cuando una clave naturalmente buena igual se sesga — un puñado de tenants ballena
superando al resto — añade un sufijo para abanicar un valor lógico a través de N
particiones, p. ej. tenantId#3 para un camino de escritura fragmentado. Vuelves a
agregar en la lectura.
Para apuntar a items dentro de una partición una vez que tu clave se reparte,
escribirás una KeyConditionExpression sobre la clave de ordenación. Puedes
ensamblar una contra tu propio esquema en el
constructor de expresiones de DynamoDB antes de
cablearla en el código:
deviceId = "vac-7741" AND readingTs BETWEEN "2026-06-01" AND "2026-06-30"Eso lee la ventana de junio de un dispositivo desde una sola partición — una Query,
no un Scan. La clave de partición fija la máquina; la
condición sobre la clave de ordenación acota las filas.
Trampas y próximos pasos
- No elijas una clave por lo que se lee bien en SQL. Elígela por lo que reparte. Cardinalidad primero, comodidad de query después.
- No asumas que la capacidad total de la tabla es tuya por clave. El throughput es por partición; un valor caliente puede throttlear mientras la tabla parece ociosa.
- No pelees contra una división. Es automática y guiada por hash — tu trabajo es darle suficientes claves distintas para repartir.
Una vez que tu clave se reparte de forma limpia, las siguientes decisiones son cómo disponer los items dentro de una partición — consulta diseño de tabla única — y cuándo un índice secundario es la herramienta correcta para un segundo patrón de acceso.
Descarga DynoTable para explorar tus particiones reales y la distribución de claves, y detectar una hot key antes de que te despierte de madrugada.