DynamoDB Particiones activas: cómo encontrarlas y repararlas

DynamoDB distribuye sus datos en muchas particiones físicas, cada una con su propia porción de rendimiento. Una partición activa es cuando una clave recibe muchas más lecturas o escrituras de las que su porción puede atender, por lo que las solicitudes a esa clave se limitan mientras el resto de la tabla permanece inactivo.

¿Qué es una partición activa DynamoDB?

Una partición activa DynamoDB es cuando una partition key absorbe muchas más lecturas o escrituras de las que su segmento de rendimiento puede atender, por lo que las solicitudes a esa clave se limitan mientras el resto de la tabla permanece inactiva. La causa es el diseño de la clave (un artículo de una celebridad, una clave de baja cardinalidad, la fecha de hoy), no el tamaño de la tabla. La cura consiste en distribuir las escrituras.

• La causa es el diseño de la clave, no el tamaño de la tabla. Una partition key concentrándose El tráfico (un usuario famoso, una bandera status="OPEN", la fecha de hoy) es la trampa.
• La capacidad adaptativa ayuda, pero no es una solución. DynamoDB reequilibra el calor automáticamente, sin embargo, un solo elemento o una sola clave aún puede exceder lo que uno la partición puede servir.
• La cura es difundir las escrituras. Agregar entropía a la clave (escribir fragmentación) o mueva la ruta de lectura activa a un patrón de acceso mejor distribuido.
• Viniendo de SQL, esto no tiene equivalente. Una tabla relacional no tiene noción de "el valor de índice de una fila es demasiado popular": modelo de rendimiento plano por clave de DynamoDB lo hace.

¿Por qué existen particiones?

DynamoDB es el heredero de la producción del papel Amazon Dynamo de 2007, que comercializaba el modelo único node SQL para uno dividido y de escala horizontal. Los datos están fragmentados mediante un hash de la clave de partición en el almacenamiento físico nodes.

Cada partición contiene una cantidad limitada de datos y sirve una cantidad limitada de rendimiento. AWS documenta un límite máximo de 3.000 RCU y 1.000 WCU por partición, por segundo: el mismo límite flexible en aprovisionado y bajo demanda en us-east-1 (AWS — comportamiento de la partición). El modo de facturación no aumenta el límite físico; solo cambia cómo se gasta a nivel de tabla está medido. Utilice la calculadora de precios para costo a nivel de tabla y Contributor Insights para ver si los throttles son limitado por partición versus limitado por tabla.

Ese techo es toda la historia. El rendimiento aprovisionado de su tabla es la suma en todas las particiones. La colección de elementos de una clave comienza en una partición y La división por calor puede dividirlo en varios límites de clave de clasificación, a menos que la tabla tiene un LSI o la clave de clasificación es cada vez mayor, lo que lo fija a uno.

Nombra la trampa: tráfico que se acumula en una clave

El rendimiento se comparte de manera uniforme solo si su acceso se distribuye uniformemente entre las claves. En el momento en que una clave recibe un tráfico desproporcionado, acelera sola mientras que la La capacidad total de la tabla queda sin utilizar.

Formas clásicas de teclas de acceso rápido:

• Un artículo de celebridad: un usuario, producto o inquilino que todos leen.
• Una clave de partición de baja cardinalidad: status, country, type. Pocos distintos valores significa pocas particiones haciendo todo el trabajo.
• Una clave de tiempo limitado: PK = "2026-06-23". Cada escritura hoy golpea a uno. partición; El ayer es frío para siempre.

Viniendo de SQL, nada de esto importaría. Un índice de árbol B sobre un valor popular es bien. En DynamoDB el valor popular es la unidad de ubicación física, por lo que la popularidad se convierte en un rendimiento cliff.

Un ejemplo resuelto: la clasificación de celebridades

Supongamos que dirige una tabla de clasificación de juegos global. Las puntuaciones se encuentran en una tabla escrita como esta:

PK = "BOARD#global"
SK = "PLAYER#<playerId>"

Las lecturas cogen el top N por puntuación; las escrituras suben el currentScore de un jugador después de cada partida. Cada fila del tablero global comparte una clave de partición — BOARD#global — así que cada lectura y cada escritura aterriza en una única partición.

Añade un streamer con dos millones de espectadores en directo machacando el botón de refrescar sobre su propio puesto, y esa única partición supera las 3.000 unidades de lectura. Recibes ProvisionedThroughputExceededException en el tablero global mientras todos los demás tableros de la tabla están inactivos.

La trampa es el colapso de BOARD#global: modelaste un único tablero lógico como una única clave física.

Reparte las escrituras: fragmentar la clave

La solución es fabricar cardinalidad. Añade un sufijo de fragmento a la clave de partición para que un tablero lógico se reparta entre N particiones físicas:

PK = "BOARD#global#<shard>"  -- shard = playerId mod 10
SK = "PLAYER#<playerId>"

Ahora las escrituras se dispersan entre diez particiones en lugar de una: diez veces más margen de escritura. El coste: una lectura del tablero completo tiene que golpear los diez fragmentos y fusionarlos, porque ninguna Query cruza los límites de un fragmento. Cambias simplicidad de lectura por distribución de escritura.

Compruébalo tú mismo. Pega una sola clave repetida en el visualizador de abajo y todas las escrituras caen en un mismo cubo: la partición activa. Añade un sufijo de fragmento (BOARD#global#0 … #9) y las mismas escrituras se reparten uniformemente:

Esto es un hash didáctico para la intuición, no el hash interno real de DynamoDB: la función real y los límites de partición son internos de AWS. Léelo como "reparto uniforme frente a sesgo", no como una predicción de en qué partición física acaba una clave.

AWS llama a esto write sharding y lo recomienda precisamente para claves de alta velocidad y baja cardinalidad (AWS — uso de write sharding).

Es el mismo instinto de sobrecarga de claves que hay detrás del diseño de tabla única: das forma a la clave para el patrón de acceso, no para cómo "encajan naturalmente" los datos.

Deja que la capacidad adaptativa haga la parte fácil

DynamoDB incluye capacidad adaptativa, tratada en la sesión de re:Invent 2018 "Amazon DynamoDB Under the Hood" (DAT401). Redistribuye continuamente el rendimiento de una tabla hacia las particiones que reciben calor, y aislará una clave persistentemente caliente en su propia partición (aislamiento a nivel de clave, AWS — bursting & adaptive capacity).

Es instantánea y gratuita, pero la limita la física (cómo funciona la capacidad adaptativa). La capacidad adaptativa puede mover calor entre claves, y el split-for-heat incluso puede dividir una colección de elementos caliente por un límite de clave de clasificación. El techo por partición sigue siendo absoluto solo para un único elemento caliente, una clave de clasificación siempre creciente o una tabla con un LSI, donde una clave de celebridad sigue sufriendo throttling. Fragmentar es la solución determinista; el split-for-heat es lento y oportunista, así que no lo esperes.

Ruta de decisión cuando ves throttling en una clave concurrida:

La mayoría de las particiones activas se resuelven con "fragmenta la clave" o "deja que la capacidad adaptativa lo absorba": el diagrama solo indica en qué rama estás.

Diagnostícalo antes de rediseñar

No puedes arreglar lo que no puedes ver. El throttling aparece como ProvisionedThroughputExceededException (provisioned) or as ThrottledRequests, ReadThrottleEvents/WriteThrottleEvents, and ReadThrottleEventsForKeyRange/WriteThrottleEventsForKeyRange — los recuentos específicos del límite de partición — en CloudWatch (AWS — métricas de CloudWatch).

Combínalo con CloudWatch Contributor Insights for DynamoDB, que clasifica directamente tus claves más accedidas: la forma más rápida de confirmar una clave de celebridad por nombre (AWS — CloudWatch Contributor Insights). Y si todavía no tienes claro que una clave caliente sea la causa — DynamoDB aplica throttling por cuatro motivos distintos — empieza por la guía de throttling y deja que las métricas nombren el límite que has alcanzado de verdad.

Cuando pruebes la ruta de lectura fragmentada estarás construyendo a mano la KeyConditionExpression de cada fragmento. Genéralas sin erratas con el Generador de expresiones de DynamoDB: emite la forma exacta PK = :pk AND begins_with(SK, :sk) por fragmento.

Escollos a evitar

• Claves de clasificación siempre crecientes. Una clave de clasificación monótona (una marca de tiempo, un número de secuencia) fuerza cada escritura nueva al mismo extremo de una colección de elementos, y el split-for-heat no puede ayudar: la colección se queda limitada a 1.000 unidades de escritura. Añade entropía a la clave de clasificación o fragmenta la clave de partición.
• Fragmentar la ruta de lectura intensiva sin necesidad. Si dominan las lecturas y el elemento es pequeño, una caché o un GSI con una clave mejor distribuida suele ganar al coste de lectura scatter-gather de la fragmentación.
• Confundir una partición activa con un Scan lento. Un Scan es lento porque lee todo; una partición activa se acelera porque una clave está sobrecargada. Diferentes problemas: consulte Query frente a Scan.

Próximos pasos

Dibuje las claves fragmentadas y luego pruebe la ruta de lectura con datos reales. Construye el condiciones por fragmento en el DynamoDB Generador de expresiones, y descargue DynoTable para ejecutarlos en sus propias tablas y ver qué Las particiones realmente absorben el calor.