DynamoDB Clave primaria compuesta: explicación de la clave de partición + clasificación
Una clave primaria compuesta consta de dos atributos: una clave de partición y una clave de clasificación. La clave de partición decide dónde reside un elemento; la clave de clasificación ordena artículos dentro de esa partición.
Viniendo de SQL, considérelo menos como una columna única id y más como
GROUP BY partition, ORDER BY sort horneado en la propia tabla.
¿Qué es una clave primaria compuesta DynamoDB?
Una clave primaria compuesta DynamoDB combina dos atributos: una clave de partición y una
Clave de clasificación. La clave de partición decide en qué partición física reside un elemento;
la clave de clasificación ordena los elementos dentro de esa partición. Juntos forman el elemento.
identidad única y dejar que un único Query devuelva un rango ordenado en lugar de uno
artículo.
- Dos partes, dos trabajos. La clave de partición dirige el elemento a una ubicación física. partición; la clave de clasificación ordena cada elemento que comparte esa clave de partición.
- La singularidad es el par. Dos elementos pueden compartir un valor de clave de partición siempre que ya que sus claves de clasificación difieren, así es como una partición contiene muchas filas.
- La clave de clasificación es el punto. Es lo que permite que un
Querydevuelva un rango (>=,between,begins_with) en lugar de un elemento, sinScan. - Las claves deben ser escalares. Las claves de partición y clasificación solo pueden ser cadenas, números, o binario: sin mapas, sin listas (AWS documentos).
Clave simple versus clave compuesta
Una clave primaria simple es solo una clave de partición. Identifica de forma única un
elemento, y lo vuelves a leer con GetItem. Eso es todo: sin lecturas de rango, no
"dame la N más nueva".
Una clave compuesta agrega la clave de clasificación, y esa única adición es lo que hace DynamoDB se siente como una base de datos en lugar de un mapa hash.
| Clave sencilla | Clave compuesta | |
|---|---|---|
| Atributos | Sólo clave de partición | Clave de partición + clave de clasificación |
| Unicidad | Valor de clave de partición | El par de valores |
| Varios artículos por partición | No | Sí |
Query un rango | No (GetItem solamente) | Sí (begins_with, between, >) |
| Ajuste natural | Búsqueda por identificación | Series de tiempo, uno a muchos, historia |
Modelar una tabla de lecturas de sensores
Supongamos que recopila muestras de temperatura de una flota de sensores de campo. el acceso El patrón es "obtener las lecturas de un dispositivo, el más nuevo primero, dentro de un tiempo". ventana". Esa es una clave compuesta de libro de texto.
Utilice la identificación del dispositivo como clave de partición y la marca de tiempo de lectura como clave de clasificación:
| deviceId | readingTs | tempC | humidity |
|---|---|---|---|
| DEV#a1b2 | 2026-06-23T08:00:00Z | 21.4 | 48 |
| DEV#a1b2 | 2026-06-23T08:05:00Z | 21.7 | 47 |
| DEV#a1b2 | 2026-06-23T08:10:00Z | 22.1 | 46 |
| DEV#c9d8 | 2026-06-23T08:00:00Z | 19.8 | 55 |
Las tres lecturas de DEV#a1b2 aterrizan en la misma partición, almacenadas físicamente
juntas y ordenadas por readingTs.
AWS llama a la clave de partición el atributo hash y a la clave de clasificación el rango atributo: la clave de clasificación es un rango que puede scan dentro (AWS documentos).
Los elementos se colapsan en una debajo de cada partición clave:
Un Query contra la clave de partición lee todas las lecturas de ese dispositivo,
ya en orden de marca de tiempo: sin clasificación en el client, sin segundo viaje de ida y vuelta.
Lo que cuesta esa ventana
Diez lecturas de 2 KB cada una en la partición suman 20 KB medidos. DynamoDB rondas
lee por bloque de 4 KB, por lo que un Query eventualmente consistente en esa ventana cuesta
3 unidades de solicitud de lectura (20 KB → cinco bloques de 4 KB × 0,5 RCU cada uno). un
la lectura fuertemente consistente en la misma ventana cuesta 5 unidades (una RCU por bloque).
Obtenga las mismas diez filas con diez llamadas GetItem separadas y el mínimo de un bloque
la regla se aplica por artículo → 5 unidades eventualmente consistentes, 10 fuertemente
consistente, antes de contar los viajes de ida y vuelta adicionales.
| Leer patrón | Artículos | Datos tocados | Unidades de lectura CE |
|---|---|---|---|
Un Query, readingTs entre inicio y fin | 10 | 20 KB | 3 |
10 × GetItem en clave compuesta completa | 10 | 20 KB | 5 |
Query partición solamente, filtra la humedad en la aplicación | 10 | 20 KB | 3 |
Scan tabla, filtro deviceId + ventana de tiempo | todos | tabla entera | tamaño de tabla |
Pase ReturnConsumedCapacity: TOTAL mientras crea prototipos; el
calculadora de precios convierte ese recuento de unidades en
una línea de pedido mensual una vez que conozca las solicitudes por segundo.
Query el rango, no lo scan
Debido a que readingTs es una cadena ISO-8601, ordena lexicográficamente la misma
forma en que se ordena cronológicamente. Entonces, una lectura de ventana de tiempo es un rango de condiciones clave,
no es un filtro:
Query
deviceId = "DEV#a1b2"
readingTs BETWEEN "2026-06-23T08:00:00Z" AND "2026-06-23T08:10:00Z"
Eso es una KeyConditionExpression: acota la lectura antes de que DynamoDB devuelva
datos, así que solo pagas por los elementos de la ventana. Una FilterExpression se ejecuta
después de la lectura y te factura todo lo que atravesó escaneando; es
la trampa del Scan en miniatura.
La expresión en sí, con marcadores de posición y valores tipados, es engorrosa de escribir a
mano. Constrúyela visualmente con el
Generador de expresiones de DynamoDB y copia la
KeyConditionExpression exacta en tu llamada al SDK.
Diseña la clave de clasificación a propósito
La clave de clasificación es la única palanca para las lecturas por rango, así que dale la forma de tus consultas.
- Usa una marca de tiempo ordenable. Las cadenas ISO-8601 o los números de época se ordenan bien; las fechas localizadas en bruto no.
- Ponle un prefijo para la uno-a-muchos. Una clave de
clasificación como
READING#2026-06-23T08:00:00Zte permite mezclar tipos de entidad bajo una misma partición y trocearlos conbegins_with. Ésa es la costura hacia el diseño de tabla única. - Pon la dimensión de alta cardinalidad en la clave de partición. El id de sensor tiene
miles de valores, así que reparte las escrituras uniformemente. Una clave de partición de
baja cardinalidad (digamos,
region) crea una .
Una clave de partición con solo cincuenta valores distintos sobre un flujo de 10.000 escrituras por segundo concentra unos 200 WCU por partición lógica antes de que DynamoDB divida: aceptable a escala de prototipo, doloroso a escala de producción. Prefiere identificadores que crezcan con tu flota (id de dispositivo, id de inquilino, id de sesión) frente a agrupaciones gruesas, salvo que quieras colocar deliberadamente un conjunto de datos acotado.
Cuándo te muerde una clave compuesta
Las claves compuestas son un compromiso. Eliges una clave de partición, publicas y después descubres un patrón de acceso que necesita una agrupación distinta: "todas las lecturas por encima de 30 °C de toda la flota".
La tabla base no puede responder a eso; la clave de partición es fija. Tus opciones son un índice secundario global con otra clave, o reestructurar.
Enumera tus lecturas antes de comprometerte con el schema de claves. Cambiar una clave
primaria significa una migración de tabla, no un ALTER TABLE.
En DynoTable, abre el navegador de tablas e inspecciona una tabla con clave compuesta junto a sus GSIs: el orden de la clave de clasificación se ve fila a fila, lo que hace evidentes los formatos de marca de tiempo mal alineados antes de que lleguen a producción.
Próximos pasos
Las claves compuestas son la base de las colecciones de elementos, las relaciones uno-a-muchos y la mayoría de los diseños de índice útiles: lee a continuación diseño de tabla única y GSI frente a LSI para ver adónde llevan.
Esboza tu KeyConditionExpression en el
Generador de expresiones de DynamoDB, emite la
paginated Query en el query constructor, luego
pruebe DynoTable para explorar sus particiones reales y observar la clasificación
ordene la línea contra sus propias tablas.