Partições físicas do DynamoDB

Uma partição física é a unidade na qual o DynamoDB de fato armazena seus dados: uma fatia de SSD, replicada entre Availability Zones, guardando uma fatia do seu espaço de chaves. Sua tabela é uma coisa lógica. As partições são onde os bytes — e os limites de throughput — realmente vivem.

Como funcionam as partições do DynamoDB?

O DynamoDB distribui sua tabela entre partições físicas — fatias de SSD replicadas entre Availability Zones. Cada uma tem teto de ~10 GB, 3.000 unidades de leitura/s e 1.000 unidades de escrita/s. O hash da sua partition key decide em qual partição um item cai, e o DynamoDB divide partições automaticamente conforme elas crescem ou ficam quentes.

Toda partição satura em ~10 GB de armazenamento, 3.000 unidades de leitura/s e 1.000 unidades de escrita/s. Esses tetos são por partição, não por tabela.
O hash da sua partition key escolhe a partição. Itens com a mesma chave caem juntos; uma hot key significa uma hot partition.
O DynamoDB divide partições por você — por tamanho e por calor sustentado — mas ele não consegue consertar uma chave que funila todo o tráfego para um único lugar.
Throttling com capacidade de sobra é o sinal. Um erro ProvisionedThroughputExceeded enquanto sua tabela fica em 5% de uso significa que uma única partição está no máximo.

Como um item encontra sua partição

O DynamoDB passa o valor da sua partition key por uma função de hash interna. A saída do hash escolhe a partição física. Mesma chave entrando, mesma partição saindo — toda vez.

Vindo do SQL, não há análogo. Não há B-tree de índice que você ajusta, nem shard key que você atribui na mão. O posicionamento é um hash que você não controla e nunca vê.

Itens que compartilham uma partition key formam uma coleção de itens, guardados juntos e ordenados por sort key. É isso que torna um Query em uma chave barato — ele lê uma corrida contígua em uma partição. (Veja Query vs Scan.)

Pegue um armazenamento de eventos de partida para um jogo. As chaves da tabela são arenaId (partição) e eventKey (sort):

# Item
arenaId    = "ARENA#7f3a"
eventKey   = "EVT#1719100800#a91c"
playerTag  = "Nightjar"
dmgDealt   = 412

Todo evento da arena 7f3a faz hash para a mesma partição e se empilha em ordem de sort key. Ótimo para "ler a timeline desta partida". Um passivo se essa única arena recebe todo o tráfego.

Os três tetos que toda partição impõe

Uma única partição é projetada para entregar no máximo:

Limite	Por partição	Contado como
Armazenamento	~10 GB	bytes crus do item
Capacidade de leitura	3.000 unidades de leitura/s	1 RU = uma leitura fortemente consistente de 4 KB
Capacidade de escrita	1.000 unidades de escrita/s	1 WU = uma escrita de 1 KB

Fonte: o guia AWS Best practices for designing partition keys.

O tamanho do item escala a conta. Um item de 20 KB custa 5 unidades de leitura por leitura fortemente consistente, então uma partição serve ~600 dessas leituras/s antes de sofrer throttling — não 3.000. Arredonde o custo de escrita para cima por 1 KB, o custo de leitura para cima por 4 KB.

A armadilha: esses são limites de partição, não de tabela. Sua tabela pode estar provisionada para 40.000 WCU e ainda sofrer throttling, porque todas as escritas estão martelando uma partição que satura em 1.000.

Como as partições se dividem

O DynamoDB adiciona partições automaticamente em dois casos. Você nunca roda um comando.

Divisão por tamanho. Quando uma partição enche em direção a ~10 GB, o DynamoDB divide sua faixa de chaves em duas e move metade dos itens para uma nova partição. O armazenamento cresce de forma transparente; suas leituras e escritas continuam funcionando o tempo todo.

Divisão por calor. Quando uma partição recebe tráfego sustentado próximo ao seu teto de throughput, o DynamoDB divide a faixa de chaves quente para que cada metade aterrisse na própria partição. A AWS chama isso de mecanismo split-for-heat. Rajadas curtas de throttling que param sozinhas geralmente significam que uma divisão acabou de acontecer.

Dividir compra espaço entre muitas chaves, mas o nó de baixo é a pegadinha: uma divisão divide uma faixa de chaves, nunca uma única chave.

Por que uma hot key vence o divisor

Aqui está o footgun. Dividir redistribui faixas de partition keys. Se seu tráfego concentra em um único valor de chave, toda requisição faz hash para a mesma partição, e não sobra faixa para dividir.

Se a arena 7f3a é uma final de torneio puxando 4.000 escritas/s enquanto toda outra arena fica ociosa, você sofrerá throttling em 1.000 — e uma divisão não consegue ajudar, porque todas as 4.000 compartilham uma chave. A razão de throttling mais nova KeyRangeThroughputExceeded nomeia exatamente isso: a faixa de chaves de uma partição, não a tabela, está acima do limite.

A correção está no modelo de dados, não no controle deslizante de capacidade. Write-shard a hot key: anexe um pequeno sufixo para que uma arena lógica se espalhe por N partições físicas.

arenaId = "ARENA#7f3a#3"   # shard 0..9, escolhido por escrita

As leituras então se distribuem pelos shards e fazem merge no cliente. Você pode prototipar os formatos de chave e o Query para cada shard com o DynamoDB Expression Builder antes de tocar uma linha de código de aplicação.

Uma nuance: a exceção da LSI

Há um caso onde o armazenamento é limitado por partition key. Sem um Local Secondary Index, uma coleção de itens se divide automaticamente por quantas partições precisar — bilhões de valores de sort key são tranquilos.

Adicione uma LSI, e a coleção inteira de uma partition key precisa caber em uma única partição de 10 GB, porque a LSI a compartilha. Esse é o penhasco por-PK coberto em GSI vs LSI — mais uma razão pela qual a maioria dos times apela para GSIs.

Projetando para que as partições fiquem frias

A alavanca que você de fato controla é a partition key. Escolha uma com muitos valores distintos em relação à contagem de linhas, para que o tráfego se espalhe uniformemente. (Mais padrões em single-table design.)

Chave de alta cardinalidade. Uma chave por usuário ou por tenant vence uma chave por dia ou por status que todos martelam ao mesmo tempo.
Fique de olho em hot keys conhecidas. Um valor "torneio atual" ou "hoje" é um risco de concentração antes de você lançar, não depois.
Fragmente a hot key inevitável. Quando uma chave precisa receber tráfego desproporcional, um sufixo é a saída de emergência padrão.

Throttling com capacidade de sobra é seu sinal de que uma partição está quente. Inspecione os itens ofensores e ensaie um layout de chave fragmentado no DynoTable — aponte-o para sua própria tabela, encontre a chave sobrecarregada e modele a correção antes que ela te chame de madrugada.