Como funciona o roteamento de solicitação DynamoDB

Cada leitura ou gravação que você envia atinge primeiro uma frota de roteadores de solicitação sem estado. Um roteador faz o hash do seu partition key, mapeia o hash para o nó de armazenamento que possui os dados dessa chave e encaminha a solicitação para lá. Esse salto é o motivo de uma pesquisa chave custa o mesmo quer a mesa contenha mil itens ou um bilhão.

Como funciona o roteamento de solicitações DynamoDB?

O DynamoDB roteia cada solicitação por meio de uma frota de roteadores de solicitação sem estado que faz hash em seu partition key, mapeia o hash para o único nó de armazenamento que possui essa partição e encaminha a leitura ou gravação para lá. O roteamento é uma função pura do hash da chave, portanto, uma consulta custa o mesmo, independentemente de a tabela conter mil itens ou um bilhão.

• O roteador de solicitação é a porta da frente. É uma frota sem estado que leva seu solicitação, faz o hash da chave de partição e a roteia para o nó de armazenamento que contém essa partição — sem varredura, sem necessidade de conhecimento completo da tabela.
• A chave de partição decide tudo. O roteamento é uma função pura do hash da chave de partição — a mesma chave sempre é encaminhada para a partição que a possui, então GetItem é O(1), não O(tamanho da tabela).
• Um primário, dois secundários. Uma gravação chega ao nó primário da partição, que reconhece uma vez que um quorum (duas das três réplicas) persistiu.
• Chaves ruins anulam o design. Funis de chave de baixa cardinalidade ou "hot" partition tráfego para um nó – o roteamento está bom, sua chave é o problema.

Comece com a solução do problema de roteamento

Vindo do SQL, você imagina um planejador de consultas: ele lê estatísticas, escolhe um índice, talvez digitalizações. O custo aumenta de acordo com a quantidade de dados que ele toca. Esse modelo não cabe um armazenamento de valores-chave que deve responder em milissegundos de um dígito em qualquer tamanho.

A resposta do DynamoDB é fazer com que uma pesquisa de item único seja um endereço direto, não um pesquisa. A chave de partição é a entrada para uma função hash que calcula onde o os dados vivem fisicamente - não uma coluna que você filtra. Sem estatísticas, sem planejador.

Essa é a troca que você aceita quando abandona o pensamento relacional: você desiste flexibilidade de consulta ad-hoc e, em troca, obtenha endereçamento em tempo constante.

Conheça o roteador de solicitação

Quando chega uma solicitação, ela não vai direto para o armazenamento. Atinge um pedido roteador — uma frota sem estado e dimensionada horizontalmente que atende todo o serviço. (O documento USENIX ATC '22 DynamoDB descreve esta frota de roteadores de solicitação.)

O roteador faz três coisas e não contém dados próprios:

• Autentica e autoriza a solicitação no IAM.
• Faça um hash na chave da partição para encontrar a partição que a possui.
• Encaminha a solicitação para o nó de armazenamento dessa partição.

Como os roteadores não têm estado, o serviço adiciona mais deles sob carga. Nenhum dos eles são um gargalo e nenhum é um ponto único de falha - a mesma propriedade que o Artigo do Amazon Dynamo de 2007 construiu o sistema original.

Siga uma leitura através do roteador

Pegue uma tabela de telemetria para uma frota de drones. Os itens são codificados por DroneId (partição chave) e ReadingTs (chave de classificação), com atributos como BatteryPct e AltitudeM.

Você pede leituras de um drone a partir de 23 de junho:

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

O diagrama abaixo traça a solicitação de cima para baixo – leia-a como um fluxo descendente.

O roteador faz o hash do DRONE#A19F, mapeia-o para a partição que possui essa chave e encaminha a leitura para o nó de armazenamento primário dessa partição, que retorna o item.

O hash aponta para uma partição de quantas tabelas tem. O roteador nunca olha para outras partições, portanto, adicionar drones – e partições

• não retarda essa pesquisa.

Saiba o que realmente é uma partição

Uma partição é uma unidade de armazenamento e rendimento. Cada um é limitado (aproximadamente 10 GB e uma fatia fixa de capacidade read/write), e DynamoDB divide uma partição quando ultrapassa qualquer um dos limites. Cada item com uma determinada chave de partição começa em um partição; split-for-heat pode posteriormente dividir essa coleção por intervalo de chaves de classificação (a menos que um LSI ou uma chave de classificação monotônica fixa-o), que é o que ainda faz um Query superar uma chave de partição barata.

Cada partição é replicada para três nós de armazenamento espalhados pela Disponibilidade Zonas: uma primária e duas secundárias.

Uma gravação vai para o primário, que reconhece a gravação uma vez que um quorum (dois dos três réplicas) persistiu. Uma leitura strongly consistent é roteada para o primário portanto, reflete a última gravação. Uma leitura eventually consistent pode ser veiculada por um secundário que ainda não alcançou — metade do custo, possivelmente obsoleto.

Dê um nome à arma de fogo: uma chave de partição ativa

O roteamento é tão bom quanto a sua chave de partição. O hash espalha as chaves uniformemente, então se suas chaves têm alta cardinalidade e até mesmo tráfego, carga espalhada por todos nós. Quebre qualquer uma das propriedades e você obterá uma partição ativa.

Digamos que você digite essa telemetria por Region em vez de DroneId. Agora cada drone em us-east-1 compartilha uma chave de partição – portanto, seu hash de leitura e gravação é o mesmo slot keyspace e empilhe em uma coleção de itens. O roteador está fazendo seu trabalho perfeitamente; você acabou de canalizar toda a frota com a capacidade de uma única partição.

Você não pode observar o roteador escolhendo um nó, mas pode projetar chaves que roteem bem. Quando você cria uma condição-chave no Expression Builder, a chave de partição que você colocou à esquerda de PK = … está o valor exato que o roteador fará o hash - mantendo isso valor de alta cardinalidade é o que mantém leituras em nós separados.

Como isso está relacionado aos seus padrões de acesso

O roteamento de solicitação é o mecanismo que torna o design de tabela única regras não negociáveis: você modela em torno da chave de partição porque a chave de partição é o endereço. É também por isso que um Query vence um Scan - um Query atinge uma partição através do roteador, enquanto um Scan percorre cada partição em sequência.

Os índices secundários obtêm suas próprias partições e seu próprio roteamento: um GSI é roteado por sua própria chave de partição, independente do tabela base, e é por isso que um GSI pode estar quente mesmo quando a mesa não está.

Próximos passos

Projete chaves que roteem para muitos nós, não para um. Esboce a condição PK = … no Expression Builder para ver exatamente qual valor recebe hash, então baixe DynoTable para executar essas consultas em seu próprias tabelas e veja exatamente o que cada condição chave retorna.