Partizioni fisiche DynamoDB

Una partizione fisica è l'unità su cui DynamoDB memorizza effettivamente i tuoi dati: una porzione di SSD, replicato nelle zone di disponibilità, conservando una porzione dello spazio della chiave. Il tuo tavolo è una cosa logica. Le partizioni sono dove si trovano i byte e il throughput limiti: vivi davvero.

Come funzionano le partizioni DynamoDB?

DynamoDB archivia la tua tabella su partizioni fisiche: porzioni SSD replicate su zone di disponibilità. Ciascuno ha un limite massimo di ~10 GB, 3.000 unità di lettura /sec e 1.000 unità di scrittura /sec. L'hash del tuo partition key decide su quale partizione si trova un elemento e DynamoDB divide automaticamente le partizioni man mano che crescono o si surriscaldano.

• Ogni partizione ha un limite massimo di ~10 GB di spazio di archiviazione, 3.000 unità di lettura/sec e 1.000 scrivere unità/sec. Questi massimali sono per partizione, non per tabella.
• L'hash del tuo partition key seleziona la partizione. Item con la stessa chiave atterrare insieme; un singolo hot item attivo, o una chiave di ordinamento monotona, è ciò che blocca una partizione.
• DynamoDB divide le partizioni per te — in base alle dimensioni e al calore sostenuto — incluso dividendo la raccolta di elementi di una chiave in corrispondenza del limite della chiave di ordinamento, a meno che un LSI o una chiave di ordinamento in costante aumento non lo blocchi.
• L'effetto throttling con capacità di riserva è determinante. A ProvisionedThroughputExceeded errore mentre la tabella si trova al 5% di utilizzo significa che una singola partizione è al massimo.

Come un elemento trova la sua partizione

DynamoDB alimenta il valore della chiave di partizione tramite una funzione hash interna. L'hashish l'output seleziona la partizione fisica. Stessa chiave in entrata, stessa partizione in uscita, ogni volta.

Provenendo da SQL, non c'è analogico. Non c'è nessun indice B-tree da ottimizzare, nessuna chiave di shard assegni a mano. Il posizionamento è un hash che non controlli e che non vedi mai.

Gli Item che condividono una chiave di partizione formano un item collection, archiviati insieme e ordinati per chiave di ordinamento. Questo è ciò che rende economico un Query su una chiave: ne legge uno esecuzione contigua su una partizione. (Vedere Query vs Scan.)

Prendi un negozio di eventi di partite per un gioco. Le chiavi della tabella sono arenaId (partizione) e eventKey (ordina):

# Item
arenaId    = "ARENA#7f3a"
eventKey   = "EVT#1719100800#a91c"
playerTag  = "Nightjar"
dmgDealt   = 412

Ogni evento per arena 7f3a ha l'hashing nella stessa partizione e viene impilato in una chiave di ordinamento ordine. Ottimo per "leggere la cronologia di questa partita". Una responsabilità se quell'arena diventa tutto il traffico.

I tre soffitti imposti da ogni partizione

Una singola partizione è progettata per fornire al massimo:

Fonte: guida AWS Best practice per la progettazione delle chiavi di partizione.

Le dimensioni dell'Item scalano i conti. Un elemento da 20 KB costa 5 unità di lettura per coerenza elevata read, quindi una partizione serve circa 600 letture /sec prima di rallentare, non 3.000. Costo di scrittura arrotondato fino a 1 KB, costo di lettura fino a 4 KB.

Questi limiti sono per partizione, non per tabella. È possibile effettuare il provisioning del tuo tavolo 40.000 WCU e ancora rallentamento, perché tutte le scritture stanno martellando una partizione che supera i 1.000.

Come si dividono le partizioni

DynamoDB aggiunge automaticamente le partizioni in due casi. Non esegui mai un comando.

Divisione in base alla dimensione. Quando una partizione si riempie fino a circa 10 GB, DynamoDB divide la sua chiave l'intervallo in due e sposta metà degli elementi in una nuova partizione. Lo spazio di archiviazione cresce in modo trasparente; le tue letture e scritture continuano a funzionare ovunque.

Dividi per calore. Quando una partizione richiede traffico sostenuto vicino al suo throughput soffitto, DynamoDB divide l'intervallo dei tasti di scelta rapida in modo che ciascuna metà si trovi nella propria partizione. AWS lo chiama meccanismo split-for-heat. Brevi raffiche di strozzamento che si fermano da soli spesso significano che si è verificata una divisione per calore, anche se brevi picchi possono anche essere solo semplici la capacità di scoppio si sta esaurendo.

La divisione acquista spazio su più chiavi e la divisione per calore può persino incidere una chiave raccolta di articoli con taglio a chiave di ordinamento. Ciò che non può diffondere è un singolo oggetto caldo, un chiave di ordinamento sempre crescente o una raccolta bloccata da un LSI.

Perché un tasto di scelta rapida batte lo splitter

La suddivisione ridistribuisce intervalli di chiavi di partizione. Se il tuo traffico si concentra su un valore chiave, ogni richiesta ha la stessa partizione e non c'è intervallo rimasto da dividere.

Se l'arena 7f3a è una finale del torneo, vengono effettuate 4.000 scritture /sec mentre tutte le altre l'arena è inattiva, rallenterai a 1.000 - e split-for-heat non può salvarlo qui, perché eventKey con prefisso timestamp è monotono, quindi ogni nuova scrittura arriva a il bordo iniziale di uno stretto intervallo di chiavi di ordinamento senza nulla da ritagliare. Il più recente Il motivo del throttling KeyRangeThroughputExceeded nomina esattamente questo: la chiave di una partizione l'intervallo, non la tabella, ha superato il limite.

La correzione sta nel modello di dati, non nel dispositivo di scorrimento della capacità. Scrivi frammento il tasto di scelta rapida: aggiungi un piccolo suffisso in modo che un'arena logica si estenda su N partizioni fisiche.

arenaId = "ARENA#7f3a#3"   # shard 0..9, chosen per write

Le letture si distribuiscono quindi tra i frammenti e si uniscono sul lato client. Puoi prototipare il file forme chiave e Query per ciascun frammento con DynamoDB Expression Builder prima di toccare una riga di codice dell'applicazione.

Una sfumatura: l'eccezione LSI

Esiste un caso in cui lo spazio di archiviazione è limitato per chiave di partizione. Senza un Local Secondary Indice, una raccolta di elementi si divide in tante partizioni quante sono deve servire sia i byte memorizzati che il throughput: miliardi di valori di chiavi di ordinamento vanno bene.

Aggiungi un LSI e l'intera raccolta per una chiave di partizione dovrà rientrare in una singola Partizione da 10 GB, perché LSI la condivide. Questo è il dirupo per PK coperto GSI vs LSI: un altro motivo per cui la maggior parte dei team sceglie le GSI.

Progettare in modo che le partizioni rimangano fresche

La leva che controlli effettivamente è la chiave di partizione. Scegline uno con molti distinti valori relativi al conteggio delle righe, in modo che il traffico si distribuisca uniformemente. (Altri modelli in design a tabella singola.)

• Chiave ad alta cardinalità. Una chiave per utente o per tenant batte una chiave per giorno o chiave per stato che tutti martellano contemporaneamente.
• Attenzione ai tasti di scelta rapida conosciuti. Un valore "torneo corrente" o "oggi" è a rischio di concentrazione prima della spedizione, non dopo.
• Shard l'inevitabile tasto di scelta rapida. Quando un tasto deve sopportare un traffico eccessivo, a il suffisso è la botola di fuga standard.

La limitazione della capacità di riserva è il segnale che una partizione è calda. Ispezionare la raccolta di elementi distorti e provare un layout di tasti frammentati DynoTable: puntalo sulla tua tabella, GRUPPO PER la chiave di partizione l'SQL Workbench per vedere quali tasti dominano e modellare la correzione prima che ti chiami.