DynoTable
Avançado7 min de leitura

DynamoDB Paralelo Scans

Uma varredura paralela divide um Scan em N solicitações Scan independentes, cada uma reivindicando um Segment da tabela, para que vários trabalhadores o leiam de uma vez. É o única maneira que o Scan API oferece para ler uma tabela inteira mais rápido do que uma partição a taxa de transferência permite.

O que é uma varredura paralela DynamoDB?

Uma varredura paralela DynamoDB divide um Scan em N solicitações independentes, cada uma reivindicando um Segment da tabela via Segment e TotalSegments, para que vários trabalhadores a leiam simultaneamente. É a única maneira que o Scan API oferece para ler uma tabela inteira mais rápido do que o rendimento de uma única partição permite - mas ainda é uma leitura completa, então você paga por cada item verificado.

  • Um Scan sequencial lê uma partição por vez — sua velocidade é limitada a um rendimento da partição única, não importa o tamanho da tabela.
  • Segment + TotalSegments fragmentam a leitura entre os trabalhadores TotalSegments; cada trabalhador verifica sua própria fatia em paralelo.
  • DynamoDB faz hash dopara atribuir segmentos, para que as fatias possam ser desequilibrado – mais trabalhadores nem sempre significa mais rápido.
  • Ainda é um Scan: você paga para ler cada item, e uma varredura paralela gorda pode drenar a taxa de transferência da tabela do tráfego ativo.

Por que um Scan sequencial é lento

Vindo de SQL, uma leitura de tabela completa parece uma operação de streaming. Em DynamoDB não é. Os dados da tabela residem em muitas partições físicas, mas um único Scan os percorre um de cada vez, 1 MB por página.

Isso significa que um Scan simples só pode extrair da taxa de transferência de uma partição orçamento de cada momento - mesmo que a tabela esteja espalhada por dezenas de partições com capacidade ociosa. Quanto maior a mesa, mais ela rasteja. (AWS: Verificação paralela)

Divida a leitura com Segment e TotalSegments

Uma varredura paralela corrige o gargalo. Você escolhe uma contagem de trabalhadores, define TotalSegments para esse número e dê a cada trabalhador um valor distinto baseado em zero Segmento. Cada trabalhador emite seu próprio Scan; DynamoDB os atende simultaneamente.

Worker 0 →  Scan  Segment=0  TotalSegments=4
Worker 1 →  Scan  Segment=1  TotalSegments=4
Worker 2 →  Scan  Segment=2  TotalSegments=4
Worker 3 →  Scan  Segment=3  TotalSegments=4

Cada trabalhador ainda pagina com LastEvaluatedKey de forma independente - ele possui seu segmento da primeira à última página. O aplicativo costura os quatro fluxos de volta juntos. Agora você está lendo a taxa de transferência de quatro partições de uma só vez de um.

Um exemplo prático: a exportação noturna

Digamos que você execute uma tabela de telemetria, leituras de sensores. Cada item é uma leitura de um dispositivo de campo:

PK = "DEVICE#a83f"          (partition key — the device id)
SK = "TS#2026-06-22T03:14"  (sort key — ISO timestamp)
batteryMv  = 3120
tempC      = 41.8
firmwareTag = "fw-7.2.1"

Todas as noites, um cron job despeja a tabela inteira no S3 para o warehouse analítico. Um Scan sequencial de 80 GB leva horas e quase não prejudica sua leitura provisionada capacidade. Então você distribui isso por oito trabalhadores:

Scan  sensor-readings  Segment=0  TotalSegments=8  ConsistentRead=false
…
Scan  sensor-readings  Segment=7  TotalSegments=8  ConsistentRead=false

Oito trabalhadores, oito segmentos, uma tabela lêem cerca de oito vezes mais rápido. Se você só precisa de leituras recentes, adicione um FilterExpression para descartar carimbos de data/hora antigos antes as linhas atingem o fio - construa e inspecione essa expressão no Expression Builder:

FilterExpression:  begins_with(SK, :today)

Como DynamoDB atribui itens a segmentos

DynamoDB atribui cada item a um segmento fazendo hash em sua chave de partição — não por contagem de linhas, não por contagem de bytes.

Portanto, cada item que compartilha um PK cai no mesmo segmento. Em leituras de sensores, todos as leituras de DEVICE#a83f vão para um trabalhador, independentemente de quantos carimbos de data/hora esse dispositivo tem ou quão grande éé. (AWS: Verificação paralela)

tabela de leituras de sensoreshash partition keySegmento 0DISPOSITIVO#a83fDISPOSITIVO#1c20Segmento 1DISPOSITIVO#9be4Segmento 2 (vazio)

Os segmentos acabam desiguais. Um trabalhador pode possuir três conversadores dispositivos com milhões de leituras; outro pode desenhar uma fatia vazia. Arranque TotalSegments mais alto não ajudará se suas chaves de partição se aglomerarem - você apenas adiciona inativo trabalhadores esperando o quente. Até mesmo a distribuição de chaves é o que faz o fan-out pagar.

Veja o custo de leitura antes de executá-lo

Uma varredura paralela é um evento de rendimento, não um almoço grátis. A pergunta honesta é "quanto de toda esta tabela estou prestes a ler?" — e antes de DynoTable executa um a leitura da tabela completa mostra uma caixa de diálogo de confirmação mostrando a tabela aproximada tamanho e contagem de itens, além de um aviso de capacidade de leitura e, em seguida, transmite ao vivo o progresso dos itens verificados à medida que a leitura é executada, para que o trabalho noturno não o surpreenda.

Armadilhas e quando não se preocupar

  • O penhasco de rendimento. Uma varredura de TotalSegments alta pode consumir a tabela toda a capacidade de leitura em segundos, eliminando o tráfego ao vivo. Em uma mesa servindo usuários, limitem cada trabalhador com o parâmetro Limit ou verifiquem fora do horário de pico. (AWS: Verificação paralela)
  • Ainda é a ferramenta errada para um padrão de acesso. Varreduras paralelas são para empregos deliberados de mesa cheia – exportações, preenchimentos, migrações. Se você está alcançando para responder a uma consulta recorrente, isso é um sinal de modelagem: adicione um GSI e transforme-o em Query.
  • SELECT * em PartiQL é o mesmo scan disfarçado. Ele compila para um Scan sequencial. Quando você realmente precisa de análises entre itens - um GROUP BY, um JOIN, um agregado - DynoTable's SQL Workbench executa aqueles do lado do cliente em um conjunto de resultados limitado, em vez de martelar a tabela.
  • Consistência forte dobra a conta. O padrão Scan élê. Para uma exportação, deixe ConsistentRead=false a menos que cada página deva refletir as gravações mais recentes - e observe que mesmo uma varredura fortemente consistente dura minutos, portanto não é um instantâneo de um momento específico (use PITR/Export para isso).

Próximos passos

Modele suas chaves para que as leituras do dia a dia nunca precisem de uma digitalização - comece com design de tabela única e Query vs Scan. Quando um trabalho de mesa cheia é genuinamente o chamada correta, tente DynoTable para executar leituras de tabela completa com um aviso antecipado de tamanho e custo e progresso da verificação ao vivo.

Atualizado