Como funcionam os componentes internos do armazenamento DynamoDB

DynamoDB é uma tabela hash cujos valores são árvores ordenadas, espalhadas pelas máquinas em três zonas de disponibilidade. Duas estruturas de dados fazem quase todo o trabalho: um hash no partition key escolhe uma máquina, uma árvore B no sort key ordena itens dentro dele.

Como o DynamoDB armazena dados?

O DynamoDB armazena seus dados como uma tabela hash gigante distribuída cujos valores são classificados em árvores B. Um hash no partition key escolhe um nó de armazenamento; uma árvore B ordena os itens por chave de classificação dentro dela. Cada gravação vai para um líder que replica para dois pares em três zonas de disponibilidade, reconhecendo assim que um quorum (duas das três réplicas) a tiver.

• A chave de partição é hash, não pesquisada. DynamoDB executa uma função hash sobre seu PK para encontrar o nó de armazenamento (ou nós, uma vez que uma grande coleção se divide) mantendo essa partição — um salto O(1), independentemente do tamanho da tabela.
• A chave de classificação reside em uma árvore B. Dentro de uma partição, os itens são armazenados em um Árvore B ordenada por chave de classificação - ordem de bytes UTF-8 para strings, ordem numérica para Teclas numéricas - é por isso que as leituras de intervalo (begins_with, between) são baratas e Scan não é.
• Cada gravação é confirmada em um quórum antes de ser confirmada. Uma gravação vai para um líder, que replica para dois pares em outras AZs e reconhece uma vez que um quorum (dois dos três réplicas) tem – a durabilidade é adquirida antes do retorno do seu PutItem.
• É por isso que existem regras de padrão de acesso. Hash-then-tree é rápido apenas quando você lê por chave. Sem chave, sem caminho rápido – você volta a examinar a árvore.

Comece com a estrutura de dados, não com o API

Vindo do SQL, você imagina uma tabela como linhas no disco com uma seleção do planejador de consultas índices. DynamoDB não tem planejador. O layout de armazenamento é o contrato - o que é rápido e o que é uma arma de pé caem direto de duas estruturas.

Imagine um mapa distribuído gigante. A chave é um hash da sua chave de partição. O valor é uma árvore B inteira de itens que compartilham esse chave de partição, ordenada por chave de classificação.

Todo o resto - semântica de consulta, avisos de 10 GB, por que uma chave faltante força um Scan – é uma consequência dessa frase.

Faça hash da chave de partição para encontrar o nó

Quando uma solicitação chega, o DynamoDB aplica uma função hash interna ao valor da chave de partição. O hash é mapeado deterministicamente para um nó de armazenamento — a partição física que possui esses itens. AWS documenta isso como o mecanismo por trás de pesquisas de chave em tempo constante, independentemente do tamanho da tabela.

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

O problema é o outro lado. Se você não fornecer a chave de partição, o DynamoDB terá nenhum nó para onde pular - ele precisa percorrer todas as partições. Esse é um Scan e é a diferença entre O(1) e a leitura de toda a tabela.

A solicitação faz hash para exatamente uma partição e, em seguida, desce o valor dessa partição árvore B da chave de classificação para o item - duas etapas baratas em vez de uma caminhada pela mesa.

Ordena itens em uma árvore B por partição

Dentro de uma única partição, os itens não são uma pilha. Eles são mantidos em uma chave B-tree pela chave de classificação , ordenada lexicograficamente. Uma pesquisa em árvore B é O (log n), e É crucial que n sejam os itens em uma partição, não a tabela inteira.

Esse é o motivo pelo qual as leituras de intervalo de chaves de classificação são baratas. Faça uma telemetria de frota tabela onde as leituras de cada dispositivo residem em uma chave de partição:

Como a árvore B é classificada, "todas as leituras entre 8h e 9h" são uma árvore descida até o valor inicial mais uma caminhada sequencial - não um filtro sobre cada lendo o dispositivo já enviado. Você lê apenas o intervalo correspondente.

Essa ordem também é a razão pela qual uma consulta begins_with(SK, "READING#2026-06-23") é rápida enquanto a filtragem em um atributo não-chave não é. A árvore pode buscar por SK; isso não posso procurar por mais nada. Para compor essas condições-chave com segurança, construa-as no DynamoDB Expression Builder em vez do que concatenar strings manualmente:

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

Replique cada gravação em três AZs

Uma partição não é uma máquina. Cada um é replicado em três nós em três zonas de disponibilidade — o design de quórum baseado em líder detalhado no 2022 Artigo USENIX ATC DynamoDB (o artigo Amazon Dynamo de 2007 é o nome e ancestral da filosofia, não este modelo de replicação).

Um nó é o líder da partição. Uma gravação vai para o líder, que escreve localmente e replica para seus dois pares. O líder reconhece a gravação uma vez por o quorum durável de nós tem isso - então a durabilidade entre AZs é paga antes seu PutItem retorna.

As leituras têm uma escolha. Uma leitura strongly consistent vai até o líder e vê a última gravação confirmada. Uma leitura eventually consistent pode ser veiculada por qualquer um dos três nós, um dos quais pode estar alguns milissegundos atrás - isso é o atraso que você troca por leituras mais baratas e mais disponíveis.

No faturamento on-demand, uma leitura de item de 2 KB custa fortemente 1 RCU; o mesmo leia custos eventualmente consistentes 0,5 RCU. Classifique seus caminhos quentes no calculadora de preços.

A mesma ideia de propagação assíncrona é a razão pela qual uma leitura GSI pode ficar obsoleta - consulte GSIs são eventualmente consistentes.

Leia as regras da estrutura

Quase todas as "regras" do DynamoDB são apenas físicas de armazenamento:

• Sempre forneça a chave de partição. Sem chave, sem alvo de hash — você está verificando todo o mapa. Este é o núcleo de Consulta vs Varredura.
• Coloque o que você lê junto em uma chave de partição, de modo que um único hash + tree-walk retorna toda a coleção de itens. Essa é a base design de mesa única.
• Mantenha as partições limitadas. Uma partição é uma árvore B em um conjunto finito de nós; uma tecla de atalho descontrolada ou um limite de 10 GB do LSI são ambos limites desse físico partição.

Depois de ver a forma hash-então-árvore B, a disciplina do padrão de acesso para parecendo arbitrário - você está apenas mantendo cada leitura no caminho mais rápido.

Próximos passos

Modele suas chaves para corresponder à estrutura com estratégias de classificação de chaves e design de mesa única, depois monte o real expressões no Construtor de Expressões DynamoDB. Experimente DynoTable para ver essas leituras executadas em suas próprias tabelas e veja exatamente quais itens uma condição-chave retira.