DynamoDB Raccolte di oggetti
Una raccolta di elementi è l'insieme di tutti gli elementi in una tabella (o indice) che condividono il file stessovalore: una proprietà emergente del tuo schema chiave.
Nel momento in cui due elementi portano la stessa chiave di partizione, formano una raccolta e basta
la raccolta diventa l'unità DynamoDB che consente di leggere insieme in un unico Query.
Se lo fai bene, le tue letture torneranno in un unico viaggio di andata e ritorno. Se sbagli, lo sei
bloccato con un Scan.
Cos'è una raccolta di oggetti DynamoDB?
Una raccolta di elementi DynamoDB è l'insieme di tutti gli elementi che condividono lo stessovalore, memorizzati insieme e ordinati per chiave di ordinamento. La raccolta emerge dal tuo schema chiave. La raccolta è l'unità che un singolo Query legge in modo efficiente, mentre un Scan percorre ogni partizione.
- Una raccolta è semplicemente "la stessa chiave di partizione". Due o più elementi con la stessa chiave i valori della chiave di partizione vengono archiviati insieme, ordinati per.
- È l'unità di un
Queryefficiente.Querylegge una raccolta;Scanpercorre ogni partizione. Questa è tutta la storia della performance. - Nessuna chiave di ordinamento, nessuna raccolta. Una tabella basata solo sulla chiave di partizione contiene un elemento per chiave — niente da raccogliere.
- Due limiti: il limite massimo di 10 GB per raccolta quando unesiste, ed è caldo partizioni da chiavi a bassa cardinalità.
Il problema: leggere insieme gli articoli correlati
Supponiamo che tu gestisca una flotta di veicoli, ciascuno con telemetria in streaming: velocità, liquido di raffreddamento
temperatura, livello del carburante - ogni pochi secondi. La lettura dominante è "dammi il
letture recenti per il veicolo V-7741".
Provenendo da SQL, indicizzeresti una colonna vehicle_id e lasceresti che il pianificatore faccia il lavoro.
Un semplice negozio con valore-chiave non può permettersi questo lusso.
Tratta ogni lettura come un record isolato, quindi quella domanda significa scansionare il file intera tabella e filtraggio. Lento, costoso e peggio con la crescita della flotta.
La risposta di DynamoDB è di raggruppare fisicamente "tutte le letture per un veicolo", cosa direttamente indirizzabile. Questo raggruppamento è la raccolta di elementi.
Cos'è realmente una collezione
DynamoDB memorizza gli elementi in partizioni e instrada ciascun elemento a una partizione tramite eseguire l'hashing della chiave di partizione. Viene archiviato ogni elemento con lo stesso valore della chiave di partizione insieme e ordinati per chiave di ordinamento. Iniziano su una partizione, ma senza LSI DynamoDB può dividere una raccolta ampia o attiva tra partizioni in corrispondenza del limite della chiave di ordinamento; solo un LSI fissa l'intera raccolta su una singola partizione (motivo per cui i 10 GB il limite inferiore è solo LSI).
La Guida per sviluppatori AWS lo nomina esattamente. Elementi che condividono un valore di chiave di partizione sono una raccolta di elementi, archiviati insieme e ordinati per chiave di ordinamento.
Questa è la stessa idea introdotta nel documento Amazon Dynamo del 2007: hashing coerente assegnare chiavi ai nodi: esteso con una dimensione di ordinamento in modo che gli elementi correlati siano adiacenti disco.
Poiché sono adiacenti e ordinati, DynamoDB ne restituisce una sequenza contigua
una ricerca. Ecco perché Query è economico e Scan non lo è: Query legge un singolo
raccolta; Scan percorre ogni partizione.
Per formare una collezione è necessario un — una chiave di partizione e a chiave di ordinamento. Una tabella basata solo sulla chiave di partizione ha esattamente un elemento per valore di chiave, quindi non c'è niente da raccogliere.
Il nostro esempio pratico: veicolo → letture telemetriche
Modellare il flusso di telemetria con una chiave composita. La chiave di partizione identifica il file veicolo; la chiave di ordinamento è il timestamp della lettura, che mantiene le letture nel timestamp ordine (ascendente per impostazione predefinita; passa ScanIndexForward=false per il più recente-prima).
| PK (vehicleId) | SK (recordedAt) | attributes |
|---|---|---|
| VEH#V-7741 | META | plate, model, depotCode |
| VEH#V-7741 | TS#2026-06-23T09:00:01Z | speedKph, coolantC, fuelPct |
| VEH#V-7741 | TS#2026-06-23T09:00:06Z | speedKph, coolantC, fuelPct |
| VEH#V-7741 | TS#2026-06-23T09:00:11Z | speedKph, coolantC, fuelPct |
| VEH#V-7742 | META | plate, model, depotCode |
| VEH#V-7742 | TS#2026-06-23T09:00:02Z | speedKph, coolantC, fuelPct |
Qui vivono due collezioni: una per veicolo. L'elemento "META" (metadati del veicolo) e tutte le letture di "V-7741" formano un'unica raccolta; Gli articoli di "V-7742" ne formano un altro.
Assegna ai metadati una chiave di ordinamento (META) che ordina prima di qualsiasi TS#...
valore e un singolo Query su PK = "VEH#V-7741" restituisce il profilo del veicolo
e le sue letture insieme.
Questo è il modello genitore-figli al centro di progettazione a tabella singola.
Ogni casella tratteggiata rappresenta una raccolta di elementi: stessa chiave di partizione, elementi ordinati per chiave di ordinamento.
Un Query legge esattamente una casella.
Query sto facendo una raccolta
Poiché la raccolta è ordinata per chiave di ordinamento, ottieni letture dell'intervallo gratuitamente. Tirare le letture registrate in una finestra di dieci minuti per un veicolo, si vincola la chiave di ordinamento:
# Query
KeyConditionExpression vehicleId = :v AND recordedAt BETWEEN :from AND :to
ScanIndexForward false # newest first
La condizione chiave ti limita a una raccolta (vehicleId = :v) e poi a a
porzione contigua di esso ("recordedAt BETWEEN ..."). DynamoDB legge solo gli elementi e
ti fattura solo per loro. Vuoi solo i metadati? recordedAt = "META" recupera il file
singolo elemento META.
Costruire manualmente queste condizioni chiave ed espressioni di proiezione è complicato. Il
DynamoDB Expression Builder genera il
KeyConditionExpression, ExpressionAttributeNames e
"ExpressionAttributeValues" per te, quindi i dettagli della parola riservata e del segnaposto
non mordere.
Collezioni su indici
Un indice secondario ha il tuo proprio schema di chiavi, quindi forma le sue proprie raccolte di elementi.
Aggiungi un indice secondario globale digitato su "depotCode" (partizione) e "recordedAt" (ordinamento),
e "tutte le letture dal deposito DEP-LON-3, prima il più recente" diventa un singolo Query
rispetto alla raccolta di quell'indice: una lettura che la tabella di base non può servire.
Ecco perché il tipo di indice è importante: determina quali raccolte puoi formare e come si comportano. Vedi GSI vs LSI per il compromesso.
Una netta distinzione: un indice secondario locale (LSI) condivide la tabella di base chiave di partizione, quindi la tua raccolta è fisicamente legata alla raccolta di elementi di base — e quel legame crea un limite rigido, di seguito.
I limiti che mordono
Le raccolte di elementi sono potenti, ma due vincoli determinano il modo in cui si modellano le chiavi:
- Il limite di 10 GB LSI. Quando una tabella ha uno o più indici secondari locali,
una singola raccolta di articoli: gli articoli base più le loro proiezioni LSI per uno
chiave di partizione: non può superare 10 GB. Superarlo e scrive che cresce il
inizio della raccolta non riuscito con "ItemCollectionSizeLimitExceededException". una tabella con no
LSI non ha tale massimale per collezione. Questo è esattamente il motivo per cui un illimitato,
il flusso in continua crescita (telemetria che non si ferma mai) non è adatto per un LSI: il
la collezione cresce solo. A GSI ha le proprie partizioni, quindi elude il limite.
-. Una raccolta risiede in una partizione e una singola partizione ha
rendimento finito. Se un veicolo (o un
depotCode) attira selvaggiamente una quota sproporzionata di traffico, puoi eseguire l'hotspot di quella partizione anche mentre il la tabella nel suo complesso è ben al di sotto della velocità effettiva assegnata. Capacità adattiva - coperta da AWS "Modelli di progettazione avanzati per DynamoDB" re:Invent approfondimenti: isola e potenzia tasti di scelta rapida automaticamente, ma non può salvare una chiave senza alcuna diffusione. Scegli chiavi di partizione con cardinalità elevata in modo che il traffico si diffonda su più raccolte.
Vedilo in DynoTable
Il modo più veloce per creare intuizione per le collezioni è guardarne una. Nel DynoTable, l'interrogazione di una chiave di partizione rende l'intera raccolta come contigua, elenco ordinato per chiave: l'elemento "META" si trova subito prima delle sue letture con timestamp, sullo schermo, non è richiesta alcuna ricostruzione mentale.

Insidie e passaggi successivi
- Nessuna chiave di ordinamento, nessuna raccolta. Una tabella basata solo sulla chiave di partizione non può raggruppare quelle correlate elementi. Se devi leggere gli elementi insieme, hai bisogno di una chiave composita.
- Non lasciare che una raccolta LSI cresca senza limiti. I flussi di sola aggiunta appartengono a GSI (o una chiave di partizione a intervalli di tempo), non LSI, a causa del limite di 10 GB.
- Distribuisci le chiavi di partizione. Una raccolta è scalabile tanto quanto la partizione vive dentro. Le chiavi di partizione a bassa cardinalità creano punti caldi.
- Raggiungi
Query, nonScan. Esistono raccolte in modo da poter leggere gli elementi correlati con un obiettivoQuery; ripiegare su unScanbutta via quel vantaggio — vedere Query vs Scan.
Disegna il tuo schema di chiavi, esegui un Query su una chiave di partizione reale e guarda il file
la raccolta torna ordinata. Scarica DynoTable ed esplora le tue tabelle'
raccolte direttamente.


