Como os internals de armazenamento do DynamoDB funcionam

O DynamoDB é uma tabela hash cujos valores são árvores ordenadas, espalhadas por máquinas em três Availability Zones. Duas estruturas de dados fazem quase todo o trabalho: um hash na partition key escolhe uma máquina, uma B-tree na sort key ordena os itens dentro dela.

Como o DynamoDB armazena dados?

O DynamoDB armazena seus dados como uma gigantesca tabela hash distribuída cujos valores são B-trees ordenadas. Um hash na partition key escolhe um nó de armazenamento; uma B-tree ordena os itens pela sort key dentro dele. Toda escrita replica sincronamente para três nós em três Availability Zones antes de confirmar.

• A partition key é hasheada, não buscada. O DynamoDB roda uma função de hash sobre sua PK para encontrar o único nó de armazenamento que guarda aquela partição — um salto O(1), independente do tamanho da tabela.
• A sort key vive em uma B-tree. Dentro de uma partição, os itens são guardados em uma B-tree ordenada lexicograficamente pela SK, e é por isso que leituras de faixa (begins_with, between) são baratas e Scan não é.
• Toda escrita atinge três nós antes de confirmar. Uma escrita vai para um líder, que replica sincronamente para dois pares em outras AZs — a durabilidade é paga antes de o seu PutItem retornar.
• É por isso que as regras de padrão de acesso existem. Hash-depois-árvore é rápido só quando você lê por chave. Sem chave, sem caminho rápido — você cai em varrer a árvore.

Comece pela estrutura de dados, não pela API

Vindo do SQL, você imagina uma tabela como linhas no disco com um query planner escolhendo índices. O DynamoDB não tem planner. O layout de armazenamento é o contrato — o que é rápido e o que é um footgun ambos saem direto de duas estruturas.

Imagine um mapa distribuído gigante. A chave é um hash da sua partition key. O valor não é um único item — é uma B-tree inteira de itens que compartilham aquela partition key, ordenada por sort key.

Todo o resto — semântica de query, os avisos de 10 GB, por que uma chave faltante força um Scan — é uma consequência dessa única frase.

Faça hash da partition key para encontrar o nó

Quando uma requisição chega, o DynamoDB aplica uma função de hash interna ao valor da partition key. O hash mapeia deterministicamente para um nó de armazenamento — a partição física que é dona daqueles itens. A AWS documenta isso como o mecanismo por trás das buscas de chave em tempo constante independente do tamanho da tabela.

Esse é o passo O(1). Uma tabela de 10 TB e uma de 10 KB custam o mesmo para localizar: hash, salto, pronto. Não há scan de índice para encontrar o nó, nem estatísticas, nem plano.

A pegadinha é o outro lado. Se você não fornece a partition key, o DynamoDB não tem nó para saltar — ele precisa percorrer toda partição. Isso é um Scan, e é a diferença entre O(1) e ler a tabela inteira.

A requisição faz hash para exatamente uma partição, depois desce a B-tree de sort key daquela partição até o item — dois passos baratos em vez de uma varredura de tabela.

Ordene os itens em uma B-tree por partição

Dentro de uma única partição, os itens não são um heap. Eles são mantidos em uma B-tree com chave pela sort key, ordenada lexicograficamente. Uma busca em B-tree é O(log n), e crucialmente esse n é o número de itens em uma partição, não na tabela inteira.

Essa é a razão inteira de leituras de faixa por sort key serem baratas. Pegue uma tabela de telemetria de frota onde as leituras de cada dispositivo vivem sob uma partition key:

Como a B-tree está ordenada, "todas as leituras entre 08:00 e 09:00" é uma descida na árvore até o valor inicial mais uma caminhada sequencial — não um filtro sobre toda leitura que o dispositivo já enviou. Você lê apenas a faixa correspondente.

Essa ordenação é também por que uma query begins_with(SK, "READING#2026-06-23") é rápida enquanto filtrar em um atributo não-chave não é. A árvore consegue buscar por SK; ela não consegue buscar por mais nada. Para compor essas condições de chave com segurança, monte-as no DynamoDB Expression Builder em vez de concatenar strings na mão:

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

Replique toda escrita para três AZs

Uma partição não é uma única máquina. Cada uma é replicada por três nós em três Availability Zones — uma linhagem de design que rastreia de volta ao modelo de replicação do paper Amazon Dynamo de 2007.

Um nó é o líder da partição. Uma escrita vai para o líder, que escreve localmente e replica para seus dois pares. O líder confirma a escrita assim que um quórum durável de nós a tem — então a durabilidade entre AZs é paga antes de o seu PutItem retornar.

As leituras têm uma escolha. Uma leitura fortemente consistente vai para o líder e enxerga a escrita comitada mais recente. Uma leitura eventualmente consistente pode ser servida por qualquer um dos três nós, um dos quais pode estar alguns milissegundos atrás — esse é o atraso que você troca por leituras mais baratas e mais disponíveis.

A mesma ideia de propagação assíncrona é por que a leitura de uma GSI pode estar defasada — veja GSIs são eventualmente consistentes.

Leia as regras direto da estrutura

Quase toda "regra" do DynamoDB é só física de armazenamento:

• Sempre forneça a partition key. Sem chave, sem alvo de hash — você está varrendo o mapa inteiro. Esse é o cerne de Query vs Scan.
• Coloque junto o que você lê junto sob uma partition key, para que um único hash + caminhada na árvore retorne a coleção de itens inteira. Essa é a fundação do single-table design.
• Mantenha as partições limitadas. Uma partição é uma B-tree em um conjunto finito de nós; uma hot key descontrolada ou o teto de 10 GB de uma LSI são ambos limites daquela partição física.

Uma vez que você vê o formato hash-depois-B-tree, a disciplina de padrão de acesso deixa de parecer arbitrária — você só está mantendo toda leitura no caminho rápido.

Próximos passos

Modele suas chaves para casar com a estrutura com sort key strategies e single-table design, depois monte as expressões de fato no DynamoDB Expression Builder. Experimente o DynoTable para observar essas leituras rodarem contra suas próprias tabelas e ver exatamente quais itens uma key condition traz de volta.