Partições físicas DynamoDB

Uma partição física é a unidade onde o DynamoDB realmente armazena seus dados: uma fatia de SSD, replicado em zonas de disponibilidade, mantendo uma fatia do seu espaço de chave. Sua mesa é uma coisa lógica. As partições são onde os bytes — e a taxa de transferência limites - realmente viva.

Como funcionam as partições DynamoDB?

O DynamoDB armazena sua tabela em partições físicas — fatias de SSD replicadas em zonas de disponibilidade. Cada um tem um limite de ~ 10 GB, 3.000 unidades de leitura/sec e 1.000 unidades de gravação/sec. O hash do seu partition key decide em qual partição um item vai parar, e o DynamoDB divide as partições automaticamente à medida que elas crescem ou esquentam.

• Cada partição tem limite de aproximadamente 10 GB de armazenamento, 3.000 unidades de leitura/sec e 1.000 escreva unidades/sec. Esses limites são por partição, não por tabela.
• O hash do seu partition key escolhe a partição. Itens com a mesma chave pousar juntos; um único hot item ativo – ou uma chave de classificação monotônica – é o que fixa uma partição.
• DynamoDB divide partições para você - em tamanho e em calor sustentado - incluindo dividir a coleção de itens de uma chave em um limite de chave de classificação, a menos que um LSI ou uma chave de classificação cada vez maior a bloqueie.
• Aceleração com capacidade de sobra é o que diz. Um ProvisionedThroughputExceeded erro enquanto sua mesa está com 5% de uso significa que uma única partição está no limite.

Como um item encontra sua partição

DynamoDB alimenta o valor da chave de partição por meio de uma função hash interna. O haxixe a saída escolhe a partição física. Mesma entrada, mesma partição – sempre.

Vindo do SQL, não há analógico. Não há árvore B de índice que você ajusta, nenhuma chave de fragmento você atribui manualmente. O posicionamento é um hash que você não controla e nunca vê.

Itens que compartilham uma chave de partição formam um item collection, armazenados juntos e classificado por chave de classificação. Isso é o que torna um Query barato em uma tecla – ele lê uma execução contígua em uma partição. (Consulte Consulta vs Verificação.)

Pegue uma loja de eventos de jogo para um jogo. As chaves da tabela são arenaId (partição) e eventKey (classificar):

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

Cada evento para arena 7f3a faz hash na mesma partição e empilha na chave de classificação ordem. Ótimo para "ler a linha do tempo desta partida". Uma responsabilidade se aquela arena ficar todo o tráfego.

Os três limites máximos que cada partição impõe

Uma única partição foi projetada para fornecer no máximo:

Fonte: guia AWS Melhores práticas para projetar chaves de partição.

O tamanho do item dimensiona a matemática. Um item de 20 KB custa 5 unidades de leitura por unidade fortemente consistente. leia, então uma partição atende aproximadamente 600 leituras /sec antes de ser acelerada - não 3.000. Aumente o custo de gravação por 1 KB e o custo de leitura por 4 KB.

Esses limites são por partição, não por tabela. Sua tabela pode ser provisionada para 40.000 WCU e ainda aceleração, porque todas as escritas estão afetando uma partição isso chega a 1.000.

Como as partições são divididas

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

Dividido por tamanho. Quando uma partição atinge aproximadamente 10 GB, o DynamoDB divide sua chave intervalo em dois 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.

Dividir para aquecimento. Quando uma partição recebe tráfego sustentado próximo à sua taxa de transferência teto, o DynamoDB divide o intervalo das teclas de atalho para que cada metade caia em sua própria partição. AWS chama isso de mecanismo split-for-heat. Rajadas curtas de estrangulamento que param por si só muitas vezes significam o início da divisão para aquecimento - embora breves picos também possam apenas capacidade de ruptura funcionando a seco.

A divisão compra espaço em muitas chaves, e a divisão para aquecimento pode até mesmo esculpir uma chave coleção de itens em um corte de chave de classificação. O que ele não pode espalhar é um único item quente, um chave de classificação cada vez maior ou uma coleção fixada por um LSI.

Por que uma tecla de atalho supera o divisor

A divisão redistribui intervalos de chaves de partição. Se o seu tráfego se concentra em um valor de chave, cada solicitação faz hash para a mesma partição e não há intervalo restante para dividir.

Se a arena 7f3a for uma final de torneio com 4.000 writes/sec enquanto todos os outros a arena está ociosa, você acelerará em 1.000 - e o split-for-heat não pode resgatá-lo aqui, porque o eventKey com prefixo de carimbo de data e hora é monotônico, então cada nova gravação chega a a borda principal de um intervalo estreito de chaves de classificação, sem nada para extrair. O mais novo O motivo do acelerador KeyRangeThroughputExceeded nomeia exatamente isto: a chave de uma partição o intervalo, e não a tabela, está acima do seu limite.

A correção está no modelo de dados, não no controle deslizante de capacidade. Write-shard a tecla de atalho: 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, chosen per write

As leituras se espalham pelos fragmentos e mesclam o lado do cliente. Você pode prototipar o formas de chave e o Query para cada fragmento com o DynamoDB Expression Builder antes de tocar uma linha de código do aplicativo.

Uma ressalva: a exceção LSI

Há um caso em que o armazenamento é limitado por chave de partição. Sem um Local Secondary Index, uma coleção de itens se divide em tantas partições quanto precisa servir tanto seus bytes armazenados quanto sua taxa de transferência – bilhões de valores de chave de classificação estão bem.

Adicione um LSI e toda a coleção de uma chave de partição deverá caber em uma única Partição de 10 GB, porque o LSI a compartilha. Esse é o penhasco per-PK coberto de GSI vs LSI – outro motivo pelo qual a maioria das equipes recorre aos GSIs.

Projetando para que as partições permaneçam legais

A alavanca que você realmente controla é a chave de partição. Escolha um com muitos distintos valores relativos à contagem de linhas, para que o tráfego seja distribuído uniformemente. (Mais padrões em design de mesa única.)

• Chave de alta cardinalidade. Uma chave por usuário ou por locatário é melhor que uma chave por dia ou chave por status que todos martelam ao mesmo tempo.
• Observe as teclas de atalho conhecidas. Um valor de "torneio atual" ou "hoje" é um risco de concentração antes do envio, não depois.
• Fragmentar a tecla de atalho inevitável. Quando uma chave precisa receber tráfego descomunal, um sufixo é a escotilha de fuga padrão.

A limitação com capacidade de sobra é o sinal de que uma partição está quente. Inspecionar a coleção de itens distorcidos e ensaie um layout de chave fragmentada em DynoTable — aponte para sua própria tabela, GROUP BY a chave de partição em o SQL Workbench para ver quais teclas dominam e modelar a correção antes que ela o chame.