Leggere tutti gli Item da DynamoDB in Python

Leggere un'intera tabella in boto3 significa paginare uno scan fino in fondo. Ogni risposta si ferma a 1 MB, e il paginator integrato del client di basso livello segue LastEvaluatedKey su ogni pagina al posto tuo (come funzionano i cursori di DynamoDB).

Quale API boto3 scegli conta qui più della paginazione stessa, e il paginator è solo metà del motivo.

Codice

import boto3

client = boto3.client("dynamodb")

paginator = client.get_paginator("scan")

items = []
for page in paginator.paginate(TableName="Music"):
    items.extend(page["Items"])

print(f"Table holds {len(items)} items")

Spiegazione

I paginator appartengono al client, non alla resource — boto3.resource("dynamodb").Table(…).scan non ha alcun paginator, quindi lì il loop su LastEvaluatedKey lo scrivi tu. Già solo questo è un buon motivo per usare il client di basso livello per una lettura completa.
L'API resource converte i numeri in Decimal — un {"N": "1994"} memorizzato torna come Decimal('1994'), che json.dumps si rifiuta di serializzare senza un encoder personalizzato. Il client qui sopra ti passa il {"N": "1994"} grezzo e lascia a te la conversione (la codifica).
Regola il paginator invece di sostituirlo — paginator.paginate(TableName="Music", PaginationConfig={"PageSize": 500, "MaxItems": 10000}). Boto3 definisce PageSize come "the number of items returned per page of each result" e MaxItems come un tetto sul totale, che emette un NextToken da cui riprendi con StartingToken.
Gli scan paralleli richiedono un client per thread, costruito con attenzione — Segment e TotalSegments dividono il lavoro, e la guida di boto3 dice che i client sono thread-safe mentre sessioni e resource non lo sono. Avverte anche che "Invoking boto3.client() inside of a concurrent context may result in response ordering issues". Costruisci il client prima di distribuire il lavoro, oppure dai a ogni worker la sua boto3.session.Session() (quando il parallelo conviene).
items cresce fino alla dimensione della tabella — gestisci ogni page dentro il loop invece di allungare una lista che tieni in memoria, a meno che tu non sappia già che la tabella è piccola.
Uno scan fattura ogni byte che legge, a ogni esecuzione — ProjectionExpression riduce la risposta e non il conto (perché); una FilterExpression scarta gli Item dopo che sono stati letti e fatturati (Scan con un filtro). Su un percorso critico vuoi una query.

Fallo visivamente

Il conto di uno scan completo è la dimensione degli Item per il loro numero, arrotondata in unità da 4 KB. Il calcolatore delle dimensioni degli Item ti dà la metà per-Item di quel calcolo a partire da un Item incollato.

DynoTable invece scorre una tabella live in una griglia a scroll infinito, e il suo editor SQL nomina l'operazione in cui la tua query viene compilata prima che tu la esegua. La stima delle RCU compare solo quando i metadati della tabella lo consentono. Scarica DynoTable.

Esempi correlati

Ottenere tutti gli Item in Node.js — la stessa lettura completa con un loop esplicito.
Ottenere tutti gli Item con la AWS CLI — la CLI pagina al posto tuo.
DynamoDB Scan in Python — lo scan con una FilterExpression.
Scan paralleli — Segment/TotalSegments, numero di worker e quando vale la pena.
Perché il mio Scan DynamoDB è lento e costoso? — il modello di costo e come evitarlo.
DynamoDB ProvisionedThroughputExceededException — leggere l'intera tabella è il modo classico per incapparci.
"The provided starting key is invalid" — una chiave di ripresa storpiata nel loop di paginazione.

Riferimenti

Ultima verifica 2026-07-28 rispetto alla documentazione ufficiale AWS collegata sopra.