Por que um DynamoDB Scan é lento e caro

Um Scan lê todos os itens da tabela e somente filtra depois. É a operação que você realiza na memória muscular SQL e aquela que silenciosamente aumenta sua conta e torna sua latência pior do que a caixa RDS que você deixou.

Por que meu DynamoDB Scan é lento e caro?

Um Scan lê todos os itens da tabela antes de FilterExpression ser executado, então você paga para ler a tabela inteira, não importa quantas linhas retornem, e ela fica mais lentamente à medida que a mesa cresce. A correção é quase sempre uma chave Query - modele o padrão de acesso em torno de uma chave, então DynamoDB toca uma partição em vez de tudo.

• Um Scan lê a tabela inteira, sempre. Tamanho, não sua contagem de resultados, decide quanto você paga e quanto tempo leva.
• O FilterExpression é uma mentira sobre custo. Ele é executado depois da leitura medido, portanto, devolver 12 itens pode custar 12 milhões de leitura.
• Um Scan fica mais lento conforme você cresce. Um Query digitado permanece plano - ele toca uma partição, não importa o tamanho da tabela.
• A correção quase sempre é modelagem, não ajuste. Se você Scan para responder a uma pergunta de rotina, está faltando uma chave.

O que um Scan realmente faz

Vindo de SQL, SELECT * FROM events WHERE type = 'checkout' parece livre - o mecanismo tem um índice ou não, mas de qualquer forma você recupera as linhas. Em DynamoDB não existe um planejador de consultas que decida isso para você.

Um Scan percorre toda a tabela sequencialmente, 1 MB por vez, e entrega cada página para o seu FilterExpression. Tudo o que o filtro rejeita ainda é lido, ainda medido e ainda em sua conta. ([AWS: Scanning tabelas][varredura])

Essa é a armadilha. O filtro se parece com uma cláusula WHERE, mas altera o conjunto de resultados, nunca o custo. Um Scan consome a mesma capacidade de leitura, seja ou nenhum filtro está presente. ([AWS: Scanning tabelas][varredura])

Conte as unidades de leitura

DynamoDB leituras de medidores ler unidades de capacidade(RCUs). Um RCU compra um único

fortemente consistenteleitura de um item de até 4 KB;eventualmente consistentelê custa metade disso. Itens maiores são arredondados para os próximos 4 KB. (AWS: Ler/escrever modo de capacidade)

Pegue uma tabela analítica, ProductEvents. Cada linha é um evento rastreado:

PK  = "TENANT#acme"
SK  = "TS#2026-06-23T14:08:55Z#evt_9f3a"
attrs: eventType, sessionId, userId, payloadBytes

Digamos que ele contenha 2.000.000 eventos, cada um com aproximadamente 1 KB, todos em um locatário ocupado. Você quero os checkouts de hoje. O movimento reflexivo:

Scan ProductEvents
FilterExpression: eventType = "checkout"

Esse filtro pode retornar 40 linhas. Mas o Scan leu todos os 2.000.000 de itens primeiro. Com aproximadamente 1 KB cada (1 RCU por 4 KB, eventualmente consistente ≈ 0,5 RCU por 4 KB), você mediu aproximadamente 250.000 RCUs — e paginou aproximadamente 2 GB de dados — para devolva 40 itens.

Agora modele o padrão de acesso como uma chave e Query em vez disso:

Query ProductEvents
PK = "TENANT#acme"
AND SK begins_with "TS#2026-06-23"

Isto lê apenas a fatia correspondente de uma partição. Se essas 40 linhas de checkout além dos outros eventos do dia chegarem a aproximadamente 2 MB, você paga por aproximadamente 2 MB de leituras, não 2 GB. A mesma resposta, uma pequena fração do custo — e a latência permanece estável conforme a mesa cresce.

Scan vs Query, medido

Em um Scan, sua contagem de resultados e sua fatura são não relacionado. Em um Query, eles rastreiam um ao outro.

Decida antes de você Scan

A maioria dos Scan acidentais vêm de uma pergunta: posso nomear a partição que precisa? Se sim, é um Query. Se não, a correção é uma chave, não um filtro maior.

Aqui está a decisão em forma de fluxo.

O caminho quase sempre termina em Query; você só passa para Scan quando não chave — presente ou adicionável — se ajusta ao padrão de acesso.

Se o padrão for real e recorrente, mas a tabela base não puder digitá-lo, isso é o sinal para adicionar um Índice Secundário Global então a questão torna-se um Query. Modelar suas chaves em torno de seus padrões de acesso antecipadamente é o jogo inteiro — consulte design de mesa única.

Escreva a consulta chaveada, não um filtro

Quando você precisar de uma condição além da chave, construa-a deliberadamente, em vez de despejando tudo em um FilterExpression. O DynamoDB Expression Builder gera o KeyConditionExpression e atribua espaços reservados para você, então a partição e a tecla de classificação fazem o estreitamento - antes de DynamoDB medir a leitura, não depois.

KeyConditionExpression: PK = :tenant AND begins_with(SK, :day)

Quando um Scan está realmente bom

Um Scan é o padrão errado para consultas de rotina. É a ferramenta certa quando você realmente quer dizer "leia tudo":

• Exportações únicas ou preenchimentos feitos manualmente.
• Pequenas tabelas de configuração/pesquisa onde a tabela inteira tem alguns KB.
• Trabalhos em segundo plano que paginam a tabela completa propositalmente. Divida-os trabalhadores com Segment / TotalSegments — a varredura paralela - em vez de um longo rastreamento sequencial. ([AWS: Scanning tabelas][varredura])

E observe que PartiQL não salva você: SELECT * FROM ProductEvents WHERE eventType = 'checkout' sem predicado de chave compila diretamente para um Scan. É a mesma arma nas roupas SQL. (Veja Query vs Scan para a análise completa.)

Quando você realmente precisa de análises entre itens — um GROUP BY, um JOIN, um agregado DynamoDB não pode expressar - DynoTable do SQL Workbench os executa no lado do cliente em um conjunto de resultados limitado, em vez de martelar a tabela com um Scan completo.

Próximos passos

Estime quanto custa qualquer um dos padrões com o calculadora de preços, leia Query vs Scan para o contraste de nível API, e download DynoTable para executá-los em suas próprias tabelas e assistir quantos itens cada abordagem realmente lê.