Partições Quentes no DynamoDB

O DynamoDB espalha seus dados por muitas partições físicas, cada uma com sua própria fatia de throughput. Uma partição quente acontece quando uma chave atrai muito mais leituras ou escritas do que sua fatia consegue atender — então as requisições para essa chave sofrem throttling enquanto o resto da tabela fica ocioso.

O que é uma partição quente no DynamoDB?

Uma partição quente no DynamoDB acontece quando uma chave de partição absorve muito mais leituras ou escritas do que sua fatia de throughput consegue atender, então as requisições para essa chave sofrem throttling enquanto o resto da tabela fica ocioso. A causa é o design da chave — um item celebridade, uma chave de baixa cardinalidade, a data de hoje — e não o tamanho da tabela. A cura é distribuir as escritas.

• A causa é o design da chave, não o tamanho da tabela. Uma chave de partição concentrando tráfego — um usuário celebridade, uma flag status="OPEN", a data de hoje — é a armadilha.
• A capacidade adaptativa ajuda, mas não é uma solução. O DynamoDB rebalanceia o calor automaticamente, mas um único item ou uma única chave ainda pode exceder o que uma partição consegue atender.
• A cura é distribuir as escritas. Adicione entropia à chave (write sharding) ou mova o caminho de leitura quente para um padrão de acesso melhor distribuído.
• Vindo do SQL, isso não tem equivalente. Uma tabela relacional não tem a noção de "o valor de índice de uma linha é popular demais" — o modelo plano de throughput-por-chave do DynamoDB tem.

Por que partições existem afinal

O DynamoDB é o herdeiro em produção do paper Amazon Dynamo de 2007, que trocou o modelo SQL de nó único por um modelo particionado e escalado horizontalmente. Os dados são fragmentados por um hash da chave de partição entre os nós físicos de armazenamento.

Cada partição armazena uma quantidade limitada de dados e atende uma quantidade limitada de throughput. A AWS documenta um teto rígido de 3.000 unidades de leitura e 1.000 unidades de escrita por partição, por segundo (AWS — comportamento da partição).

Esse teto é a história toda. O throughput provisionado da sua tabela é a soma de todas as partições — mas qualquer chave individual só cai em uma partição.

Nomeie a armadilha: tráfego que se amontoa em uma chave

O throughput é compartilhado uniformemente apenas se o seu acesso estiver espalhado uniformemente entre as chaves. No momento em que uma chave recebe tráfego desproporcional, ela sofre throttling sozinha enquanto a capacidade geral da tabela fica sem uso.

Formas clássicas de chave quente:

• Um item celebridade — um usuário, produto ou tenant que todo mundo lê.
• Uma chave de partição de baixa cardinalidade — status, country, type. Poucos valores distintos significam poucas partições fazendo todo o trabalho.
• Uma chave em balde temporal — PK = "2026-06-23". Toda escrita de hoje martela uma partição; a de ontem fica fria para sempre.

Vindo do SQL, nada disso importaria. Um índice B-tree sobre um valor popular está ok. No DynamoDB o valor popular é a unidade de posicionamento físico, então a popularidade vira um precipício de throughput.

Um exemplo prático: o leaderboard celebridade

Digamos que você administre um leaderboard global de jogos. Os scores vivem em uma tabela com chaves assim:

PK = "BOARD#global"
SK = "PLAYER#<playerId>"

As leituras pegam os top N por score; as escritas atualizam o currentScore de um jogador após cada partida. Toda linha do board global compartilha uma chave de partição — BOARD#global — então toda leitura e escrita cai em uma única partição.

Adicione um streamer com dois milhões de espectadores ao vivo martelando o botão de atualizar no próprio ranking, e essa única partição ultrapassa as 3.000 unidades de leitura. Você recebe ProvisionedThroughputExceededException no board global enquanto todos os outros boards da tabela estão ociosos.

A cilada é o colapso BOARD#global: você modelou um único board lógico como uma única chave física.

Distribua as escritas: fazendo sharding da chave

A correção é fabricar cardinalidade. Acrescente um sufixo de shard à chave de partição para que um board lógico se espalhe por N partições físicas:

PK = "BOARD#global#<shard>"  -- shard = playerId mod 10
SK = "PLAYER#<playerId>"

As escritas agora se dispersam por dez partições em vez de uma — dez vezes mais folga de escrita. O custo: uma leitura do board inteiro precisa acertar todos os dez shards e mesclar, porque nenhum Query único atravessa os limites de shard. Você troca a simplicidade de leitura pela distribuição de escrita.

A AWS chama isso de write sharding e recomenda precisamente para chaves de alta velocidade e baixa cardinalidade (AWS — usando write sharding).

Esse é o mesmo instinto de sobrecarga de chave por trás do single-table design — você molda a chave para o padrão de acesso, não para como os dados "naturalmente" ficam.

Deixe a capacidade adaptativa fazer a parte fácil

O DynamoDB traz a capacidade adaptativa, abordada na sessão re:Invent 2018 "Amazon DynamoDB Under the Hood" (DAT401). Ela redistribui continuamente o throughput de uma tabela em direção às partições que recebem calor, e vai isolar uma chave persistentemente quente em sua própria partição (isolamento em nível de chave, AWS — bursting & capacidade adaptativa).

É instantânea e gratuita — mas é limitada pela física. A capacidade adaptativa pode mover calor entre chaves; ela não consegue empurrar uma única chave além do teto por partição. Uma verdadeira chave celebridade ainda sofre throttling. O sharding é o que te leva além desse muro.

Eis o caminho de decisão assim que você vê throttles em uma chave movimentada:

A maioria das partições quentes se resolve em "faça sharding da chave" ou "deixe a capacidade adaptativa absorver" — o diagrama é só sobre qual ramo você está.

Diagnostique antes de redesenhar

Você não pode consertar o que não consegue ver. O throttling aparece como ProvisionedThroughputExceededException (provisionado) ou como ThrottledRequests e o ThrottleCount por partição no CloudWatch (AWS — métricas do CloudWatch).

Combine isso com o CloudWatch Contributor Insights for DynamoDB, que ranqueia suas chaves mais acessadas diretamente — o jeito mais rápido de confirmar uma chave celebridade pelo nome (AWS — Contributor Insights).

Quando você estiver testando o caminho de leitura com sharding, vai montar à mão a KeyConditionExpression para cada shard. Gere-as sem erros de digitação com o DynamoDB Expression Builder — ele emite a forma exata PK = :pk AND begins_with(SK, :sk) por shard.

Ciladas a evitar

• Chaves auto-incrementais ou monotônicas. IDs sequenciais e timestamps como chave de partição roteiam escritas consecutivas para a mesma partição. Adicione um prefixo de hash.
• Fazer sharding do caminho pesado de leitura sem necessidade. Se as leituras dominam e o item é pequeno, um cache ou um GSI com uma chave melhor distribuída muitas vezes vence o custo de leitura scatter-gather do sharding.
• Confundir uma partição quente com um Scan lento. Um Scan é lento porque lê tudo; uma partição quente sofre throttling porque uma chave está sobrecarregada. Problemas diferentes — veja Query vs Scan.

Próximos passos

Esboce as chaves com sharding, depois prove o caminho de leitura contra dados reais. Monte as condições por shard no DynamoDB Expression Builder, e baixe o DynoTable para rodá-las contra suas próprias tabelas e ver quais partições realmente recebem o calor.