DynamoDB particiones físicas

Una partición física es la unidad DynamoDB que realmente almacena sus datos en: un segmento de SSD, replicadas en zonas de disponibilidad, que contienen una porción de su espacio clave. Tu mesa es algo lógico. Las particiones son el lugar donde se encuentran los bytes y el rendimiento. límites, vivir de verdad.

¿Cómo funcionan las DynamoDB particiones?

DynamoDB almacena su tabla en particiones físicas: segmentos SSD replicados en zonas de disponibilidad. Cada uno tiene un límite de ~10 GB, 3000 unidades de lectura/seg y 1000 unidades de escritura/seg. El hash de su clave de partición decide en qué partición aterriza un elemento, y DynamoDB divide las particiones automáticamente a medida que crecen o se calientan.

• Cada partición tiene un límite de ~10 GB de almacenamiento, 3000 unidades de lectura/seg y 1000 escriba unidades/seg. Esos límites son por partición, no por tabla.
• El hash de tu partition key selecciona la partición. Elementos con la misma clave aterrizar juntos; una sola elemento activo activo, o una clave de clasificación monótona, es lo que fija una partición.
• DynamoDB divide las particiones por usted, según el tamaño y el calor sostenido, incluido dividir la colección de elementos de una clave en un límite de clave de clasificación, a menos que una clave de clasificación LSI o una clave de clasificación cada vez mayor la bloquee.
• Throttling con capacidad de sobra es lo que indica. A ProvisionedThroughputExceeded El error mientras su mesa tiene un uso del 5% significa que una sola partición está al máximo.

Cómo un elemento encuentra su partición

DynamoDB alimenta el valor de su clave de partición a través de una función hash interna. el hachís la salida elige la partición física. La misma clave de entrada, la misma partición de salida, siempre.

Viniendo de SQL, no hay análogo. No hay un árbol B de índice que usted ajuste, ni una clave de fragmento usted asigna a mano. La ubicación es un hash que no controlas y nunca ves.

Los elementos que comparten una clave de partición forman una item collection, almacenados juntos y ordenados por clave de clasificación. Eso es lo que hace que un Query en una tecla sea barato: lee una ejecución contigua en una partición. (Ver Query frente a Scan.)

Tome una tienda de eventos de partidos para un juego. Las claves de la tabla son arenaId (partición) y eventKey (ordenar):

# Item
arenaId    = "ARENA#7f3a"
eventKey   = "EVT#1719100800#a91c"
playerTag  = "Nightjar"
dmgDealt   = 412

Todos los eventos de la arena 7f3a hashean a la misma partición y se apilan en orden de clave de clasificación. Estupendo para "lee la cronología de esta partida". Un lastre si esa única arena se lleva todo el tráfico.

Los tres techos que impone cada partición

Una sola partición está diseñada para entregar como máximo:

Fuente: la guía de AWS Best practices for designing partition keys.

El tamaño del elemento escala la aritmética. Un elemento de 20 KB cuesta 5 unidades de lectura por cada lectura fuertemente consistente, así que una partición sirve unas 600 lecturas de ese tipo por segundo antes de aplicar throttling, no 3.000. El coste de escritura se redondea hacia arriba por cada 1 KB, y el de lectura por cada 4 KB.

Esos topes son por partición, no por tabla. Tu tabla puede estar aprovisionada con 40.000 WCU y aun así sufrir throttling, porque todas las escrituras están machacando una única partición cuyo tope son 1.000.

Cómo se dividen las particiones

DynamoDB añade particiones automáticamente en dos casos. Nunca ejecutas un comando.

División por tamaño. Cuando una partición se acerca a los ~10 GB, DynamoDB parte su rango de claves en dos y mueve la mitad de los elementos a una partición nueva. El almacenamiento crece de forma transparente; tus lecturas y escrituras siguen funcionando durante todo el proceso.

División por calor. Cuando una partición recibe tráfico sostenido cerca de su techo de rendimiento, DynamoDB divide el rango de claves caliente para que cada mitad caiga en su propia partición. AWS llama a esto el mecanismo split-for-heat. Las ráfagas cortas de throttling que cesan solas suelen significar que entró en juego el split-for-heat, aunque los picos breves también pueden ser simplemente la capacidad de ráfaga agotándose.

La división gana espacio entre muchas claves, y el split-for-heat incluso puede trocear la colección de elementos de una clave por un corte de clave de clasificación. Lo que no puede repartir es un único elemento caliente, una clave de clasificación siempre creciente o una colección fijada por un LSI.

Por qué una clave caliente gana al divisor

La división redistribuye rangos de claves de partición. Si tu tráfico se concentra en un único valor de clave, todas las peticiones hashean a la misma partición y no queda rango que dividir.

Si la arena 7f3a es una final de torneo que atrae 4.000 escrituras/seg mientras el resto de arenas están inactivas, sufrirás throttling en 1.000, y el split-for-heat no puede rescatarte aquí, porque el eventKey con prefijo de marca de tiempo es monótono, así que cada escritura nueva aterriza en el borde delantero de un rango estrecho de clave de clasificación sin nada que recortar. El motivo de throttling más reciente, KeyRangeThroughputExceeded, nombra exactamente esto: el rango de claves de una partición, no la tabla, está por encima de su límite.

La solución está en el modelo de datos, no en el deslizador de capacidad. Aplica write sharding a la clave caliente: añade un pequeño sufijo para que una arena lógica se reparta entre N particiones físicas.

arenaId = "ARENA#7f3a#3"   # shard 0..9, chosen per write

Las lecturas se abren entonces en abanico por los fragmentos y se fusionan en el lado del client. Puedes prototipar las formas de clave y la Query para cada fragmento con el DynamoDB Generador de expresiones antes de tocar una línea de código de aplicación.

Un matiz: la excepción LSI

Hay un caso en el que el almacenamiento está limitado por clave de partición. Sin un Índice secundario local, una colección de elementos se divide en tantas particiones como sea posible. necesita servir tanto a sus bytes almacenados como a su rendimiento: miles de millones de valores de clave de clasificación están bien.

Agregue un LSI y toda la colección de una clave de partición debe caber en una sola Partición de 10 GB, porque la LSI la comparte. Ese es el cliff por PK cubierto en GSI vs LSI: otra razón por la que la mayoría de los equipos optan por GSIs.

Diseñar para que las particiones se mantengan frescas

La palanca que realmente controlas es la clave de partición. Elija uno con muchos distintos valores relativos al recuento de filas, de modo que el tráfico se distribuya uniformemente. (Más patrones en diseño de una sola mesa.)

• Clave de alta cardinalidad. Una clave por usuario o por inquilino supera a una por día o clave por estado que todos presionan a la vez.
• Esté atento a las teclas de acceso rápido conocidas. Un valor de "torneo actual" o "hoy" es un riesgo de concentración antes del envío, no después.
• Fragmentar la inevitable tecla de acceso rápido. Cuando una tecla debe soportar un tráfico descomunal, una El sufijo es el sombreado de forma estándar esc.

Trabajar con capacidad de sobra es una señal de que una partición está activa. inspeccionar la colección de elementos sesgados y ensayar un diseño de clave fragmentada en DynoTable: apúntalo a tu propia mesa, GRUPO POR la clave de partición en el SQL Workbench para ver qué teclas dominan y modelar la solución antes de que lo avise.