Scan DynamoDB con la AWS CLI

aws dynamodb scan pagina automaticamente, il che è comodo e significa che l'unico numero che useresti per giudicare il danno è sbagliato per impostazione predefinita. Vedi Query vs. Scan per quando evitare del tutto l'operazione.

Codice

aws dynamodb scan \
  --table-name 'Music' \
  --filter-expression '#filter0 >= :filterValue0' \
  --expression-attribute-names '{"#filter0":"Year"}' \
  --expression-attribute-values '{":filterValue0":{"N":"2010"}}'

--return-consumed-capacity riporta una pagina, non lo scan

La fixture è di 600 canzoni da circa 3,9 KB ciascuna, di cui 8 corrispondono. Aggiungi --return-consumed-capacity TOTAL a quel comando e la CLI stampa:

{ "Count": 8, "ScannedCount": 600, "CU": 128.5 }

Lo scan è davvero costato 284,5 unità di lettura su tre pagine. Count e ScannedCount sono stati sommati su tutte e tre; ConsumedCapacity è stato preso dalla prima e il resto buttato via. Non è tanto un bug quanto una regola dichiarata — la configurazione del paginatore DynamoDB di botocore elenca Count e ScannedCount come result key e ConsumedCapacity come chiave non aggregata.

La spia è che la cifra si muove mentre il lavoro no. Stessa tabella, stessi 600 Item letti, un flag in più:

--page-size 50  ->  { "Count": 8, "ScannedCount": 600, "CU": 24.0 }

Se stai dimensionando una tabella a partire da uno scan da CLI, somma tu le pagine con --page-size più --starting-token, oppure leggi la capacità da CloudWatch.

--max-items non ferma lo scan

--max-items 3 sembra un campione a buon mercato. Non lo è:

--max-items 3  ->  { "Count": 8, "ScannedCount": 600 }

La CLI ha continuato a richiedere pagine finché non ha avuto abbastanza corrispondenze, il che con un filtro selettivo ha significato l'intera tabella, poi ha troncato l'elenco stampato. Il suo stesso token di ripresa lo dice ad alta voce:

{"ExclusiveStartKey": {"Artist": {"S": "Arturo Sandoval"},
 "SongTitle": {"S": "Cubano Chant 0541"}}, "boto_truncate_amount": 3}

boto_truncate_amount è un contatore lato client. Per limitare ciò che DynamoDB legge, usa --page-size, che imposta il Limit dell'API su ogni richiesta sottostante, e riprendi con --starting-token:

aws dynamodb scan \
  --table-name 'Music' \
  --page-size 500 \
  --max-items 100 \
  --starting-token "$NEXT_TOKEN"

Misurato il 2026-07-28 contro DynamoDB Local (amazon/dynamodb-local) con aws-cli/2.36.9. Il JSON qui sopra è output della CLI stessa, rimodellato con --query per questioni di larghezza.

Spiegazione

• --filter-expression gira dopo la lettura, quindi riduce l'output e non il conto. #filter0 fa da alias a Year tramite --expression-attribute-names perché Year è una parola riservata.
• --expression-attribute-values vuole il numero tra virgolette due volte: le virgolette della shell attorno al JSON, e il valore come stringa JSON. Togliere le virgolette interne non arriva mai a DynamoDB — la CLI lo rifiuta in locale con Invalid type for parameter ExpressionAttributeValues.:v.N, value: 2010, type: <class 'int'>, valid types: <class 'str'>.
• --page-size è il flag che cambia la chiamata API. Diventa Limit su ogni richiesta sottostante, limitando gli Item valutati per pagina. Il resto della famiglia della paginazione (--max-items, --starting-token) è la CLI che gestisce il proprio output.
• Lo scan parallelo richiede --segment N --total-segments M per worker, e ogni worker mantiene il proprio --starting-token. Compra tempo di orologio, non capacità.

Fallo visivamente

Il Generatore di espressioni DynamoDB emette il filtro ed entrambe le mappe JSON già con l'escape per la shell, il che elimina lo strato di quoting che fa fallire le espressioni CLI prima ancora che DynamoDB le veda.

Per esplorare le tabelle in una GUI, con griglie filtrate e paginate, scarica DynoTable invece di scansionare alla cieca dal terminale.

Guide correlate

• Query vs. Scan — quando (raramente) uno scan è giustificato.
• Perché il mio Scan DynamoDB è lento e costoso? — il modello di costo e come evitarlo.
• DynamoDB ProvisionedThroughputExceededException — cosa fa uno scan completo alla capacità di una tabella con provisioning.
• DynamoDB ThrottlingException — l'altro throttle, e come lo gestisce il backoff esponenziale.

Riferimenti

• Scan — Amazon DynamoDB API Reference
• scan — AWS CLI Command Reference
• Using the pagination options in the AWS CLI — AWS CLI User Guide
• Scanning tables — Amazon DynamoDB Developer Guide