Cómo funciona DynamoDB Solicitar enrutamiento

Cada lectura o escritura que envía llega primero a una flota de enrutadores de solicitudes sin estado. Un enrutador codifica su partition key, asigna el hash al almacenamiento node que posee los datos de esa clave y reenvíerds la solicitud allí. Ese salto es el motivo de una búsqueda clave Cuesta lo mismo si la tabla contiene mil artículos o mil millones.

¿Cómo funciona el enrutamiento de solicitudes DynamoDB?

DynamoDB enruta cada solicitud a través de una flota de enrutadores de solicitudes sin estado que codifica su partition key, asigna el hash al almacenamiento único node que posee esa partición y reenvíards la lectura o escritura allí. El enrutamiento es una función pura del hash de la clave, por lo que una búsqueda cuesta lo mismo si la tabla contiene mil elementos o mil millones.

• El enrutador de solicitudes es la puerta de entrada. Es una flota sin estado que lleva su solicitud, codifica la clave de partición y la enruta al almacenamiento node que contiene esa partición: no es necesario scanning, no se necesitan conocimientos completos de la tabla.
• La clave de partición lo decide todo. El enrutamiento es una función pura del hash de la clave de partición: la misma clave siempre se dirige a la partición propietaria, por lo que GetItem es O(1), no O(tamaño de tabla).
• Uno primario, dos secundarios. Una escritura llega al primario node de la partición, que reconoce una vez que un quórum (dos de las tres réplicas) lo ha persistido.
• Las claves incorrectas anulan el diseño. Un embudo de claves de baja cardinalidad o partición "caliente" tráfico a un node: la ruta está bien, su clave es el problema.

Comience con el problema que resuelve el enrutamiento

Viniendo de SQL, te imaginas un planificador query: lee estadísticas, elige un índice, tal vez scans. El costo aumenta con la cantidad de datos que toca. ese modelo no encaja un almacén de valores clave que tiene que responder en milisegundos de un solo dígito en cualquier tamaño.

La respuesta de DynamoDB es hacer que la búsqueda de un solo elemento sea una dirección directa, no una buscar. La clave de partición es la entrada a una función hash que calcula dónde está los datos viven físicamente, no una columna por la que usted filtra. Sin estadísticas, sin planificador.

Ése es el intercambio que aceptas cuando abandonas el pensamiento relacional: te rindes flexibilidad ad-hoc query y obtenga a cambio direccionamiento en tiempo constante.

Conoce el enrutador solicitado

Cuando llega una solicitud, no go directamente al almacenamiento. Llega a una solicitud enrutador: una flota sin estado y de escala horizontal que encabeza todo el servicio. (El USENIX ATC '22 DynamoDB documento desc se adapta a esta flota de enrutadores de solicitudes.)

El enrutador hace tres cosas y no guarda datos propios:

• Autentica y autoriza la solicitud contra IAM.
• Hashes la clave de partición para encontrar la partición propietaria.
• Reenviarrds la solicitud al almacenamiento node para esa partición.

Debido a que los enrutadores no tienen estado, el servicio agrega más bajo carga. Ninguno de ellos es un cuello de botella y ninguno es un único punto de falla: la misma propiedad que Documento de Amazon Dynamo de 2007 construyó el sistema original.

Siga una lectura a través del enrutador

Tomemos como ejemplo una tabla de telemetría para una flota de drones. Los elementos están codificados por DroneId (partición clave) y ReadingTs (clave de clasificación), con atributos como BatteryPct y AltitudeM.

Solicitas lecturas de un dron a partir del 23 de junio:

PK = "DRONE#A19F"
SK begins_with "2026-06-23"

El diagrama de abajo traza la solicitud de arriba abajo: léelo como un único flujo descendente.

El enrutador aplica un hash a DRONE#A19F, lo asigna a la partición propietaria de esa clave y reenvía la lectura al node de almacenamiento primario de esa partición, que devuelve el elemento.

El hash apunta a una partición de todas las que tenga la tabla. El enrutador nunca mira las demás particiones, así que añadir drones — y particiones — no ralentiza esta búsqueda.

Qué es realmente una partición

Una partición es una unidad de almacenamiento y de rendimiento. Cada una tiene un tope (unos 10 GB y una porción fija de capacidad de lectura/escritura), y DynamoDB divide una partición cuando supera cualquiera de los dos límites. Todos los elementos con una misma clave de partición empiezan en una sola partición; el split-for-heat puede luego trocear esa colección por rango de clave de clasificación (salvo que un LSI o una clave de clasificación monótona la fijen), que es lo que sigue haciendo barata una Query sobre una clave de partición.

Cada partición se replica en tres nodes de almacenamiento repartidos entre zonas de disponibilidad: uno primario y dos secundarios.

Una escritura va al primario, que la confirma en cuanto un quórum (dos de las tres réplicas) la ha persistido. Una lectura fuertemente consistente se enruta al primario, así que refleja la última escritura. Una lectura eventualmente consistente puede servirla un secundario que todavía no se ha puesto al día: la mitad de coste, posiblemente obsoleta.

Nombra la trampa: una clave de partición caliente

El enrutamiento solo es tan bueno como tu clave de partición. El hash reparte las claves uniformemente, así que si tus claves tienen cardinalidad alta y el tráfico es parejo, la carga se reparte entre todos los nodes. Rompe cualquiera de las dos propiedades y obtienes una partición activa.

Supón que claves esa telemetría por Region en lugar de por DroneId. Ahora todos los drones de us-east-1 comparten una clave de partición, así que sus lecturas y escrituras hashean a la misma ranura del espacio de claves y se amontonan en una sola colección de elementos. El enrutador está haciendo su trabajo a la perfección; simplemente has embudado toda la flota hacia la capacidad de una única partición.

No puedes ver al enrutador elegir un node, pero sí puedes diseñar claves que se enruten bien. Cuando construyes una condición de clave en el Generador de expresiones, la clave de partición que pones a la izquierda de PK = … es exactamente el valor al que el enrutador aplicará el hash: mantener ese valor con cardinalidad alta es lo que mantiene las lecturas en nodes distintos.

Cómo enlaza esto con tus patrones de acceso

El enrutamiento de solicitudes es el mecanismo que hace innegociables las reglas del diseño de tabla única: modelas alrededor de la clave de partición porque la clave de partición es la dirección. También es la razón de que una Query gane a un Scan: una Query golpea una sola partición a través del enrutador, mientras que un Scan recorre todas las particiones en secuencia.

Los índices secundarios tienen sus propias particiones y su propio enrutamiento: un GSI se enruta por su propia clave de partición, independiente de la de la tabla base, y por eso un GSI puede estar caliente aunque la tabla no lo esté.

Próximos pasos

Diseña claves que se enruten a muchos nodes, no a uno. Esboza la condición PK = … en el Generador de expresiones para ver exactamente qué valor obtiene hash, luego descarga DynoTable para ejecutar esas consultas en tu propias tablas y ver exactamente lo que devuelve cada condición clave.