Principiante8 min de lectura

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 Query devuelva un rango (>=, between, begins_with) en lugar de un elemento, sin Scan.
  • 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 sencillaClave compuesta
AtributosSólo clave de particiónClave de partición + clave de clasificación
UnicidadValor de clave de particiónEl par de valores
Varios artículos por particiónNo
Query un rangoNo (GetItem solamente)Sí (begins_with, between, >)
Ajuste naturalBúsqueda por identificaciónSeries 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:

deviceIdreadingTstempChumidity
DEV#a1b22026-06-23T08:00:00Z21.448
DEV#a1b22026-06-23T08:05:00Z21.747
DEV#a1b22026-06-23T08:10:00Z22.146
DEV#c9d82026-06-23T08:00:00Z19.855

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:

Partición: DEV#a1b2lecturaTs 08:00lecturaTs 08:05leyendoTs 08:10ID de consulta del dispositivo =DEV#a1b2

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ónArtículosDatos tocadosUnidades de lectura CE
Un Query, readingTs entre inicio y fin1020 KB3
10 × GetItem en clave compuesta completa1020 KB5
Query partición solamente, filtra la humedad en la aplicación1020 KB3
Scan tabla, filtro deviceId + ventana de tiempotodostabla enteratamañ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:00Z te permite mezclar tipos de entidad bajo una misma partición y trocearlos con begins_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.

Actualizado