Cómo funcionan los componentes internos del almacenamiento DynamoDB

DynamoDB es una tabla hash cuyos valores son árboles ordenados, distribuidos entre máquinas. en tres zonas de disponibilidad. Dos estructuras de datos hacen casi todo el trabajo: un hash en la clave de partición elige una máquina, un árbol B en la clave de clasificación ordena los artículos dentro de él.

¿Cómo almacena datos DynamoDB?

DynamoDB almacena sus datos como una tabla hash distribuida gigante cuyos valores son árboles B ordenados. Un hash en la clave de partición elige un almacenamiento node; un árbol B ordena los elementos por clave de clasificación dentro de él. Cada escritura se envía a un líder que replica a dos pares en tres zonas de disponibilidad, reconociendo una vez que un quórum (dos de las tres réplicas) lo tiene.

• La clave de partición está codificada, no buscada. DynamoDB ejecuta una función hash sobre tu PK para encontrar el almacenamiento node (o node s, una vez que se divide una gran colección) sosteniendo esa partición: un salto O(1), independientemente del tamaño de la tabla.
• La clave de clasificación se encuentra en un árbol B. Dentro de una partición, los elementos se almacenan en un Árbol B ordenado por clave de clasificación: UTF-8 orden de bytes para cadenas, orden numérico para Teclas numéricas, razón por la cual las lecturas de rango (begins_with, between) son baratas y Scan no lo es.
• Cada escritura se confirma en un quórum antes de confirmar. Una escritura go se dirige a un líder, que se replica a dos pares en otras AZ y reconoce una vez un quórum (dos de los tres réplicas) lo tiene: la durabilidad se compra antes de que regrese su PutItem.
• Esta es la razón por la que existen las reglas de patrón de acceso. Hash-then-tree es rápido sólo cuando lees por clave. Sin clave, sin camino rápido: vuelves a scanfinar el árbol.

Comience con la estructura de datos, no con el API

Viniendo de SQL, imaginas una tabla como filas en el disco con un planificador de query seleccionando índices. DynamoDB no tiene planificador. El diseño del almacenamiento es el contrato: ¿qué es? rápido y lo que es una pistola caen directamente de dos estructuras.

Imagínese un mapa gigante distribuido. La clave es un hash de su clave de partición. el El valor es un árbol B completo de elementos que comparten eso. clave de partición, ordenada por clave de clasificación.

Todo lo demás: query semántica, los 10 GB con arn cosas, por qué una clave faltante obliga a Scan - es una consecuencia de esa oración.

Hash de la clave de partición para encontrar el node

Cuando llega una solicitud, DynamoDB aplica una función hash interna al valor de clave de partición. El hash se asigna de manera determinista a un almacenamiento node — la partición física propietaria de esos elementos. AWS documenta esto como el Mecanismo detrás de las búsquedas de claves en tiempo constante, independientemente del tamaño de la tabla.

Ese es el paso O(1). Una tabla de 10 TB y una tabla de 10 KB cuestan lo mismo para ubicar: hash, salta, listo. No hay índice scan para encontrar el node, ni estadísticas, ni plan.

El problema es la otra cara. Si no proporciona la clave de partición, DynamoDB tiene no hay node al que saltar: tiene que recorrer cada partición. Eso es un Scan, y es la diferencia entre O(1) y leer la tabla completa.

La solicitud se dirige exactamente a una partición, luego descfinaliza la partición de esa partición. árbol B de clave de clasificación para el elemento: dos pasos económicos en lugar de un recorrido por la mesa.

Ordenar elementos en un árbol B por partición

Dentro de una única partición, los elementos no son un montón. Están retenidos en un árbol B con clave por clave de clasificación, ordenados lexicográficamente. Una búsqueda de árbol B es O(log n), y Es crucial que n sean los elementos de una partición, no toda la tabla.

Esta es la única razón por la que las lecturas de rango de clave de clasificación son baratas. Tome una telemetría de flota tabla donde las lecturas de cada dispositivo se encuentran bajo una clave de partición:

Debido a que el árbol B está ordenado, "todas las lecturas entre las 08:00 y las 09:00" es un árbol descent al valor inicial más una caminata secuencial, no un filtro sobre cada leyendo el dispositivo alguna vez enviado. Solo lees el rango coincidente.

Ese orden también es la razón por la que un begins_with(SK, "READING#2026-06-23") query es rápido mientras que filtrar por un atributo que no es clave no lo es. El árbol puede buscar por SK; eso No puedo buscar por nada más. Para componer esas condiciones clave de forma segura, constrúyalas en el DynamoDB Generador de expresiones en lugar que cadenas concatenadas manualmente:

KeyConditionExpression  PK = :pk AND begins_with(SK, :day)

Replicate every write to three AZs

Una partición no es una sola máquina. Cada una se replica en tres nodes en tres zonas de disponibilidad: el diseño de quórum basado en líder que detalla el artículo de DynamoDB de USENIX ATC 2022 (el artículo de Amazon Dynamo de 2007 es el ancestro del nombre y la filosofía, no de este modelo de replicación).

Un node es el líder de la partición. Una escritura va al líder, que escribe localmente y replica a sus dos pares. El líder confirma la escritura en cuanto un quórum duradero de nodes la tiene, así que la durabilidad entre zonas de disponibilidad se paga antes de que tu PutItem retorne.

Las lecturas pueden elegir. Una lectura fuertemente consistente va al líder y ve la última escritura confirmada. Una lectura eventualmente consistente puede servirla cualquiera de los tres nodes, uno de los cuales puede ir unos milisegundos por detrás: ése es el retraso que cambias por lecturas más baratas y más disponibles.

En la facturación bajo demanda, un elemento de 2 KB leído cuesta fuertemente 1 RCU; lo mismo lea costos eventualmente consistentes 0.5 RCU. Califica en línea tus rutas calientes en el calculadora de precios.

La misma idea de propagación asíncrona explica por qué una lectura GSI puede estar obsoleta; consulte GSIs eventualmente son consistentes.

Leer las reglas de la estructura.

Casi todas las DynamoDB "reglas" son simplemente físicas de almacenamiento:

• Proporcione siempre la clave de partición. Sin clave, sin objetivo hash: está scanfinando todo el mapa. Este es el núcleo de Query vs Scan.
• Coubique lo que leen juntos bajo una clave de partición, de modo que una sola hash + tree-walk devuelve toda la colección de elementos. Esa es la base de diseño de mesa única.
• Mantenga las particiones delimitadas. Una partición es un árbol B en un conjunto finito de nodes; una tecla de acceso rápido fuera de control o el límite de 10 GB de un LSI son límites de esa capacidad física. partición.

Una vez que vea la forma de hash y luego de árbol B, la disciplina del patrón de acceso se detiene Sintiéndote arbitrario: simplemente estás manteniendo cada lectura en el camino rápido.

Próximos pasos

Modele sus claves para que coincidan con la estructura con estrategias de clave de clasificación y diseño de mesa única, luego ensamble el diseño real expresiones en el DynamoDB Generador de expresiones. Pruebe DynoTable para ver cómo se ejecutan estas lecturas en sus propias tablas y vea exactamente qué elementos retira una condición clave.