Partições quentes DynamoDB: como encontrá-las e corrigi-las

O DynamoDB espalha seus dados por muitas partições físicas, cada uma com sua própria fatia de rendimento. Uma partição quente é quando uma chave atrai muito mais leituras ou escreve do que sua fatia pode servir - então as solicitações para essa chave aceleram enquanto o resto da mesa fica ociosa.

O que é uma partição quente DynamoDB?

Uma partição quente DynamoDB ocorre quando um partition key absorve muito mais leituras ou escritas do que sua fatia de taxa de transferência pode atender, portanto, as solicitações para essa chave são aceleradas enquanto o restante da tabela fica ocioso. A causa é o design da chave – um item de celebridade, uma chave de baixa cardinalidade, a data de hoje – e não o tamanho da mesa. A cura está se espalhando, escreve.

• A causa é o design principal, não o tamanho da mesa. Um partition key concentrado o tráfego – um usuário famoso, uma bandeira status="OPEN", a data de hoje – é a armadilha. A capacidade adaptativa ajuda, mas não é uma solução. DynamoDB reequilibra o calor automaticamente, mas um único item ou uma única chave ainda pode exceder o que partição pode servir.
• A cura é espalhar escritas. Adicione entropia à chave (fragmentação de gravação) ou mova o caminho de leitura quente para um padrão de acesso melhor distribuído.
• Vindo do SQL, não tem equivalente. Uma tabela relacional não tem noção de "o valor do índice de uma linha é muito popular" - modelo de taxa de transferência por chave plana do DynamoDB faz.

Por que existem partições

DynamoDB é o herdeiro da produção do jornal Amazon Dynamo de 2007, que comercializou o modelo SQL de nó único para um particionado e com escala horizontal. Os dados são fragmentados por um hash da chave de partição em nós de armazenamento físico.

Cada partição contém uma quantidade limitada de dados e serve uma quantidade limitada de rendimento. O AWS documenta um teto rígido de 3.000 RCU e 1.000 WCU por partição, por segundo — o mesmo limite flexível para provisionamento e on-demand em us-east-1 (AWS — comportamento da partição). O modo de cobrança não aumenta o limite físico; isso apenas muda a forma como os gastos no nível da tabela é medido. Use a calculadora de preços para custo em nível de tabela e Contributor Insights para ver se as restrições são limitado por partição vs limitado por tabela.

Esse teto é toda a história. A taxa de transferência provisioned da sua tabela é a soma em todas as partições. A coleção de itens de uma chave começa em uma partição e split-for-heat pode dividi-lo em vários limites de chave de classificação - a menos que a tabela tem um LSI ou a chave de classificação está cada vez maior, o que a fixa em um.

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

A taxa de transferência é compartilhada uniformemente somente se o seu acesso for distribuído uniformemente pelas chaves. No momento em que uma chave recebe tráfego desproporcional, ela é limitada sozinha enquanto o a capacidade geral da tabela não é utilizada.

Formas clássicas de teclas de atalho:

• Um item de celebridade — um usuário, produto ou inquilino que todos leem.
• Uma chave de partição de baixa cardinalidade — status, country, type. Poucos distintos valores significam poucas partições fazendo todo o trabalho.
• Uma chave com intervalo de tempo — PK = "2026-06-23". Cada escrita hoje martela uma partição; o de ontem está frio para sempre.

Vindo do SQL, nada disso importaria. Um índice de árvore B em um valor popular é tudo bem. No DynamoDB o valor popular é a unidade de posicionamento físico, então a popularidade se torna um precipício no rendimento.

Um exemplo prático: a tabela de classificação de celebridades

Digamos que você administre uma tabela de classificação global de jogos. As pontuações ficam em uma tabela codificada assim:

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

As leituras alcançam os N primeiros por pontuação; escreve bump no currentScore de um jogador após cada combinar. Cada linha no quadro global compartilha uma chave de partição — BOARD#global

• para que cada leitura e gravação chegue a uma única partição.

Adicione um streamer com dois milhões de espectadores ao vivo enviando spam para o botão de atualização em seus própria classificação, e essa partição ultrapassa 3.000 unidades de leitura. Você consegue ProvisionedThroughputExceededException na placa global enquanto todos os outros tabuleiro na mesa está ocioso.

A arma é o colapso do BOARD#global: você modelou uma única placa lógica como um única chave física.

Espalhe as escritas: fragmentando a chave

A solução é fabricar cardinalidade. Anexe um sufixo de fragmento à partição chave para que uma placa lógica se espalhe por N partições físicas:

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

As escritas agora estão espalhadas por dez partições em vez de uma – dez vezes a gravação altura livre. O custo: uma leitura de todo o tabuleiro deve atingir todos os dez fragmentos e fundir, porque nenhum Query ultrapassa os limites dos fragmentos. Você troca simplicidade de leitura por distribuição de gravação.

Veja a diferença por si mesmo. Cole uma única chave repetida no visualizador abaixo e cada gravação vai para um balde - a partição quente. Adicione um sufixo de fragmento (BOARD#global#0… #9) e as mesmas escritas se espalham uniformemente:

Este é um hash de ensino para intuição, não o verdadeiro hash interno do DynamoDB - o a função real e os limites da partição são internos do AWS. Leia-o como "mesmo espalhado vs skew", não como uma previsão de qual partição física uma chave irá parar.

AWS chama isso de fragmentação de gravação e o recomenda precisamente para alta velocidade, chaves de baixa cardinalidade (AWS — usando fragmentação de gravação).

Este é o mesmo instinto key-overloading por trás design de mesa única — você molda a tonalidade para o padrão de acesso, não pela forma como os dados ficam "naturalmente".

Deixe a capacidade adaptativa fazer a parte mais fácil

DynamoDB vem com capacidade adaptativa, abordada na sessão re:Invent 2018 "Amazon DynamoDB sob o capô" (DAT401). Ele redistribui continuamente os dados de uma tabela taxa de transferência para as partições que recebem calor e isolará um sistema persistentemente tecla de atalho em sua própria partição (isolamento em nível de chave, AWS — capacidade de expansão e adaptação).

É instantâneo e gratuito – mas é limitado pela física (como funciona a capacidade adaptativa). A capacidade adaptativa pode mudar aquecimento entre teclas e divisão por aquecimento podem até dividir uma coleção de itens quentes em um limite da chave de classificação. O teto por partição permanece absoluto apenas para um único ponto quente item, uma chave de classificação cada vez maior ou uma tabela com um LSI — onde uma chave de celebridade ainda acelera. A fragmentação é a solução determinística; split-for-heat é lento e oportunista, então não espere.

Caminho de decisão quando você vê aceleradores em uma tecla ocupada:

A maioria das partições quentes resolvem "fragmentar a chave" ou "deixar a capacidade adaptativa absorva-o" — o diagrama mostra exatamente em qual ramo você está.

Diagnosticar antes de redesenhar

Você não pode consertar o que não pode ver. A limitação aparece como

ProvisionedThroughputExceededException (provisionado) ou como ThrottledRequests, ReadThrottleEvents/WriteThrottleEvents e ReadThrottleEventsForKeyRange/WriteThrottleEventsForKeyRange — o contagens específicas de limite de partição — no CloudWatch (AWS — métricas do CloudWatch).

Combine isso com o CloudWatch Contributor Insights for DynamoDB, que classifica seu chaves mais acessadas diretamente – a maneira mais rápida de confirmar uma chave de celebridade pelo nome (AWS – Insights do Colaborador). E se você ainda não tem certeza se uma tecla de atalho é a causa - o DynamoDB acelera para quatro razões distintas - comece por o guia de otimização e deixe as métricas nomearem o limite que você realmente atingiu.

Ao testar o caminho de leitura fragmentado, você estará construindo manualmente o KeyConditionExpression para cada fragmento. Gere aqueles sem erros de digitação com o DynamoDB Expression Builder — emite o formato PK = :pk AND begins_with(SK, :sk) exato por fragmento.

Armadilhas a evitar

• Chaves de classificação cada vez maiores. Uma chave de classificação monotônica (um carimbo de data/hora, uma sequência número) força cada nova gravação no mesmo final de uma coleção de itens, e split-for-heat não pode ajudar – a coleção permanece limitada a 1.000 unidades de gravação. Adicione entropia à chave de classificação ou fragmente a chave de partição.
• Fragmentando o caminho de leitura pesada desnecessariamente. Se as leituras dominarem e o item for pequeno, um cache ou um GSI com uma chave melhor distribuída geralmente supera o custo de leitura de coleta de dispersão do sharding.
• Confundir uma partição quente com um Scan lento. Um Scan é lento porque lê tudo; uma partição quente é acelerada porque uma chave está sobrecarregada. Problemas diferentes — consulte Consulta vs Varredura.

Próximos passos

Esboce as chaves fragmentadas e compare o caminho de leitura com dados reais. Construa o condições por fragmento no Construtor de expressão DynamoDB e download DynoTable para executá-los em suas próprias tabelas e ver quais as partições realmente suportam o calor.