Cómo funcionan DynamoDB claves de partición

Su clave de partición es una dirección. DynamoDB aplica hash a esa clave y el hash decide qué máquina física almacena el artículo. Escoge bien la llave y diferenciales de carga; Recógelo mal y un servidor se lleva la peor parte.

¿Cómo funcionan las DynamoDB claves de partición?

DynamoDB ejecuta su partition key a través de una función hash interna, y ese hash decide qué partición física almacena el elemento. El hash decide la ubicación; la clave no está ordenada ni indexada como una columna SQL. Elija una clave de alta cardinalidad y cargue los diferenciales en muchas particiones; Elija uno de baja cardinalidad y una sola partición absorberá todo el calor.

• La clave está codificada, no ordenada. DynamoDB ejecuta su clave de partición a través de un hash interno para elegir una partición. Dos valores adyacentes no se acercan entre sí otro en el disco.
• Una partición es una unidad de almacenamiento real. Cada una tiene un límite de alrededor de 10 GB, 3000 unidades de lectura/seg y 1.000 unidades de escritura/seg. Su tráfico se divide por cuántos particiones en las que se distribuyen sus claves.
• Las teclas de acceso rápido son la pistola. Canalice la mayoría de las solicitudes en un valor de clave de partición y ejecutas esa partición mientras el resto de la tabla permanece inactiva.
• Las claves de alta cardinalidad ganan. Cuanto más distintas y uniformes sean las claves que valores cuanto más particiones absorban la carga.

Comience con lo que realmente hace la clave

Viniendo de SQL, una clave principal es una columna ordenada e indexada en la que JOIN y ORDER BY. En DynamoDB la clave de partición (a veces llamada clave hash) no algo diferente: decide ubicación.

DynamoDB introduce la clave de partición en una función hash interna. Los mapas de salida a un espacio de claves, y el espacio de claves se divide en rangos: cada rango es propiedad de un partición física. Esa partición es almacenamiento real en un node real.

Entonces, la clave de partición responde a una pregunta: ¿qué máquina contiene este elemento? sort key, si tienes una, solo pide artículos dentro de esa máquina. juega ninguna parte en la colocación.

Sigue una escritura a través del hash

Supongamos que ejecuta un SaaS que ingiere lecturas del dispositivo. Tu mesa SensorReadings usa una clave de partición deviceId y una clave de clasificación readingTs. Escribes una lectura para deviceId = "vac-7741".

Ruta que toma la escritura, desde su clave hasta el disco al que llega:

La escritura para vac-7741 tiene un hash hasta un punto en el espacio de claves, ese punto cae en rango de P2, y el artículo aterriza en P2, ordenado allí por readingTs.

Lo que hay que internalizar: "vac-7741" y "vac-7742" están separados por un carácter, pero sus hashes no están relacionados. Es casi seguro que viven en diferentes particiones. No hay ningún "cercano" en el espacio de claves de la partición.

Esta es la idea de hash consistente DynamoDB heredada del diseño original: el documento de Amazon Dynamo de 2007 ("Dynamo: valor clave de alta disponibilidad de Amazon Store") distribuye las claves entre node mediante hash exactamente para que ningún node se convierta en un bottlcuello.

Pegue una lista de valores de clave de partición a continuación para ver cómo un hash los distribuye cubos. Un conjunto de alta cardinalidad se distribuye uniformemente; reutiliza un valor y todo se acumula en un solo depósito: la partición caliente de la que trata la siguiente sección.

Este es un hash de enseñanza para la intuición, no el verdadero hash interno de DynamoDB: el La función real, el espacio de claves y los límites de partición son AWS internos. Úselo para desarrollar una idea de distribución versus sesgo, no para predecir qué partición física es una clave aterriza en.

Respeta los límites estrictos de la partición.

Una partición física es finita. Según la AWS DynamoDB Guía para desarrolladores, cada uno aguanta aproximadamente:

Cuando una partición ocupa más de 10 GB o su rendimiento aprovisionado necesita más espacio, DynamoDB lo divide: el rango del espacio de claves se divide y los elementos se redistribuyen a través de más particiones. Esto es automático; no lo activas.

Una división puede dividir la colección de elementos de una clave de partición en una clave de clasificación límite, por lo que la carga de una clave ocupada puede distribuirse en más particiones. que dividir No puedo rescue es un único elemento destacado, una clave de clasificación cada vez mayor o una tabla con un LSI: fijan la colección a una partición.

Nombra la trampa: la partición activa

Una partición caliente es la pistola clásica. Sucede cuando una clave de partición El valor (o un pequeño conjunto de ellos) absorbe una parte desproporcionada del tráfico.

Fallo concreto: cambias SensorReadings a una clave de partición region con valores como "us-east", "eu-west". Tres regiones significan tres valores clave: como máximo: tres particiones que hacen un trabajo real. Slam "us-east" con lecturas y Throttles a 3000 RCU mientras que la capacidad total aprovisionada de la tabla permanece sin uso.

La capacidad adaptativa de DynamoDB suaviza esto: puede cambiar el rendimiento no utilizado hacia una partición ocupada y aislar una única tecla muy activa en su propia partición. AWS detalló esto en re:Invent "Patrones de diseño avanzados para DynamoDB" sesiones de inmersión profunda. Pero la capacidad de adaptación gana tiempo, no inmunidad: un un solo elemento destacado, una clave de clasificación cada vez mayor o un LSI todavía limita una clave a la vez. partición única. Diseño para difusión; No te apoyes en la red de seguridad.

Elija una clave de alta cardinalidad

La solución es cardinalidad: el número de valores clave distintos y la uniformidad el tráfico los golpea.

• Baja cardinalidad (region, status, true/false): pocas particiones, el tráfico se concentra, llega temprano.
• Alta cardinalidad (deviceId, userId, un ID de pedido): hash de muchos valores A través de muchas particiones, la carga se distribuye, el espacio libre crece.

Viniendo de SQL, felizmente indexarías una columna status y la filtrarías. como un DynamoDB clave de partición que es una trampa: no se puede propagar. Mantener baja cardinalidad atributos como filtros o como clave de clasificación del índice secundario, nunca como lo que decide la colocación.

Cuando una clave natural de good todavía está sesgada: un puñado de inquilinos de ballenas superan rest: agregue un sufijo para distribuir un valor lógico en N particiones, p. tenantId#3 para una ruta de escritura fragmentada. Se vuelve a agregar al leer.

Para apuntar a elementos dentro de una partición una vez que su clave esté extendida, escribirá un KeyConditionExpression en la clave de clasificación. Puedes montar uno contra el tuyo. schema en el DynamoDB generador de expresiones antes de conectarlo al código:

deviceId = "vac-7741" AND readingTs BETWEEN "2026-06-01" AND "2026-06-30"

Eso lee la ventana de junio de un solo dispositivo desde una única partición: un Query, no un Scan. La clave de partición fija la máquina; la condición sobre la clave de clasificación acota las filas.

Escollos y próximos pasos

• No elijas una clave por lo bien que se lee en SQL. Elígela por cómo reparte. Primero la cardinalidad, la comodidad de query después.
• No des por hecho que la capacidad total de la tabla es tuya por clave. El rendimiento es por partición; un solo valor caliente puede sufrir throttling mientras la tabla parece inactiva.
• No pelees contra una división. Es automática y se guía por el hash: tu trabajo es darle suficientes claves distintas entre las que repartirse.

Una vez que tu clave reparte limpiamente, las siguientes decisiones son cómo colocar los elementos dentro de una partición — consulta diseño de tabla única — y cuándo un índice secundario es la herramienta adecuada para un segundo patrón de acceso.

Descarga DynoTable y ejecuta un GROUP BY sobre su clave de partición en el SQL Workbench para ver qué teclas acumulan elementos antes de que una se convierta en una partición activa.