DynamoDB Parallelo Scans

Una scansione parallela divide un Scan in N richieste Scan indipendenti, ciascuna rivendicando un "segmento" della tabella, in modo che più lavoratori lo leggano contemporaneamente. È il unico modo in cui Scan API offre di leggere un'intera tabella più velocemente di una partizione la produttività lo consente.

Cos'è una scansione parallela DynamoDB?

Una scansione parallela DynamoDB divide un Scan in N richieste indipendenti, ciascuna delle quali rivendica un Segmento della tabella tramite Segment e TotalSegments, quindi più lavoratori lo leggono contemporaneamente. È l'unico modo in cui Scan API offre di leggere un'intera tabella più velocemente di quanto consentito dal throughput di una singola partizione, ma è comunque una lettura completa, quindi paghi per ogni elemento scansionato.

• Un Scan sequenziale legge una partizione alla volta — la tua velocità è limitata a il throughput di una singola partizione, non importa quanto sia grande la tabella.
• Segment + TotalSegments suddivide la lettura tra i lavoratori TotalSegments; ogni lavoratore scansiona la propria fetta in parallelo.
• DynamoDB esegue l'hash delchiave di partizioneper assegnare segmenti, quindi le fette possono essere sbilanciato: più lavoratori non sempre significano più velocità.
• È pur sempre un Scan: si paga per leggere ogni elemento, e una grossa scansione parallela può drena il throughput della tabella dal tuo traffico live.

Perché un Scan sequenziale è lento

Venendo da SQL, la lettura dell'intera tabella sembra un'operazione di streaming. Dentro DynamoDB non lo è. I dati della tabella risiedono in molte partizioni fisiche, ma a il singolo Scan li guida uno alla volta, 1 MB per pagina.

Ciò significa che un semplice Scan può estrarre solo dal throughput di una partizione budget in un momento, anche se la tabella è distribuita su dozzine di partizioni con capacità inattiva. Più grande è la tabella, più a lungo striscia. (AWS: Scansione parallela)

Dividi la lettura con Segment e TotalSegments

Una scansione parallela risolve il collo di bottiglia. Scegli un conteggio dei lavoratori, imposta "TotalSegments" a quel numero e assegna a ciascun lavoratore un valore in base zero distinto "Segmento". Ogni lavoratore emette il proprio Scan; DynamoDB li serve contemporaneamente.

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

Ogni lavoratore continua a paginare con "LastEvaluatedKey" in modo indipendente: ne possiede il file segmento dalla prima all'ultima pagina. L'applicazione ricuce i quattro flussi insieme. Ora stai invece leggendo il throughput di quattro partizioni contemporaneamente di uno.

Un esempio pratico: l'esportazione notturna

Supponiamo che tu esegua una tabella di telemetria, "letture dei sensori". Ogni elemento è una lettura da a dispositivo da 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"

Ogni notte un lavoro cron scarica l'intera tabella su S3 per il magazzino di analisi. Un Scan sequenziale di 80 GB richiede ore e intacca a malapena la lettura fornita capacità. Quindi lo distribuisci su otto lavoratori:

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

Otto lavoratori, otto segmenti, una tabella leggono circa otto volte più velocemente. Se tu servono solo letture recenti, aggiungi un FilterExpression per eliminare prima i vecchi timestamp le righe colpiscono il filo: costruisci e ispeziona quell'espressione nel file Expression Builder:

FilterExpression:  begins_with(SK, :today)

Come DynamoDB assegna gli elementi ai segmenti

DynamoDB assegna ogni elemento a un segmento hashing la tua chiave di partizione — non tramite conteggio delle righe, non in base al conteggio dei byte.

Quindi ogni elemento che condivide un PK finisce nello stesso segmento. In "letture dei sensori", all le letture per "DEVICE#a83f" vanno a un lavoratore, indipendentemente dal numero di timestamp ha quel dispositivo o quanto è granderaccolta di oggettiÈ. (AWS: Scansione parallela)

I segmenti risultano irregolari. Un lavoratore potrebbe possederne tre chiacchieroni dispositivi con milioni di letture; un altro potrebbe disegnare una fetta vuota. Avviamento TotalSegments più alto non aiuterà se le chiavi della partizione si raggruppano: aggiungi semplicemente inattivo lavoratori in attesa di quello caldo. Anche la distribuzione delle chiavi è ciò che rende possibile il fan-out pagare.

Visualizza il costo di lettura prima di eseguirlo

Una scansione parallela è un evento di throughput, non un pasto gratuito. La domanda onesta è "quanto di tutta questa tabella sto per leggere?" — e prima che venga eseguito DynoTable a lettura della tabella completa ti porta con una finestra di dialogo di conferma che mostra la tabella approssimativa dimensioni e numero di elementi più un avviso di capacità di lettura, quindi trasmette in streaming dal vivo gli elementi scansionati avanzano durante la lettura, quindi il lavoro notturno non ti sorprende.

Insidie e quando non preoccuparsi

• Il limite del throughput. Una scansione con un numero elevato di TotalSegments può consumare i dati della tabella l'intera capacità di lettura in pochi secondi, affamando il traffico in tempo reale. Servire su una tabella utenti, limitare ciascun lavoratore con il parametro "Limite" o eseguire la scansione in orari non di punta. (AWS: Scansione parallela)
• È ancora lo strumento sbagliato per un modello di accesso. Le scansioni parallele servono lavori deliberati a tutto campo: esportazioni, riempimenti, migrazioni. Se stai raggiungendo per rispondere a una query ricorrente, questo è un segnale di modellazione: aggiungi a GSI e trasformalo invece in un Query.
• SELECT * in PartiQL è la stessa scansione sotto mentite spoglie. Si compila in sequenziale Scan. Quando hai effettivamente bisogno di analisi tra elementi: un "GROUP BY", un JOIN, un aggregato: SQL Workbench di DynoTable esegue quelli lato client su un set di risultati limitato, invece di martellare la tabella.
• Una forte coerenza raddoppia il conto. Il valore predefinito è Scaneventualmente coerentelegge. Per un'esportazione, lascia ConsistentRead=false a meno che ogni pagina non debba riflettere le scritture più recenti e nota che anche una scansione fortemente coerente dura minuti, quindi non è un'istantanea punto nel tempo (usa PITR/Export per quello).

Passaggi successivi

Modella le tue chiavi in modo che le letture quotidiane non abbiano mai bisogno di una scansione: inizia con design a tabella singola e Query vs Scan. Quando un lavoro a tavola completa è davvero il chiamata giusta, prova DynoTable per eseguire letture di tabelle complete con a avvisi anticipati su dimensioni e costi e avanzamento della scansione in tempo reale.