Come funzionano le chiavi di partizione DynamoDB
Il tuo è un indirizzo. DynamoDB esegue l'hashing di quella chiave e l'hash decide quale macchina fisica memorizza l'oggetto. Scegli bene la chiave e spread di carico; sceglilo male e un server prende il caldo.
Come funzionano le chiavi di partizione DynamoDB?
DynamoDB esegue il tuo tramite una funzione hash interna e tale hash decide quale partizione fisica memorizza l'elemento. L'hash decide il posizionamento; la chiave non è ordinata o indicizzata come una colonna SQL. Scegli una chiave ad alta cardinalità e carica gli spread su molte partizioni; scegline uno a bassa cardinalità e una singola partizione si prenderà tutto il calore.
- La chiave è sottoposta ad hashing, non ordinata. DynamoDB esegue la chiave di partizione tramite un file hash interno per scegliere una partizione. Due valori adiacenti non si trovano neanche lontanamente vicini l'uno all'altro altro su disco.
- Una partizione è una vera e propria unità di archiviazione. Ognuna ha una capacità massima di circa 10 GB, 3.000 unità di lettura /sec e 1.000 unità di scrittura /sec. Il tuo traffico è diviso per quanti partizioni su cui sono distribuite le chiavi.
- I tasti di scelta rapida sono la pistola. Incanala la maggior parte delle richieste su un valore di chiave di partizione e limiti la partizione mentre il resto del tavolo rimane inattivo.
- I tasti ad alta cardinalità vincono. Il tasto più distinto e premuto in modo uniforme ti valorizza più partizioni assorbono il carico.
Inizia con ciò che fa effettivamente la chiave
Proveniente da SQL, una chiave primaria è una colonna ordinata e indicizzata su JOIN e ORDER DA acceso. In DynamoDB lo fa la chiave di partizione (a volte chiamata chiave hash).
qualcosa di diverso: decide il posizionamento.
DynamoDB inserisce la chiave di partizione in una funzione hash interna. Le mappe di output in uno spazio delle chiavi e lo spazio delle chiavi viene suddiviso in intervalli: ogni intervallo è di proprietà di a partizione fisica. Quella partizione è una vera memoria su un nodo reale.
Quindi la chiave di partizione risponde a una domanda: quale macchina contiene questo elemento? Il file , se ne hai uno, ordina solo gli articoli all'interno di quella macchina. Suona nessuna parte nel posizionamento.
Segui una scrittura attraverso l'hash
Supponiamo che tu gestisca un SaaS che acquisisce le letture del dispositivo. Il tuo tavolo SensorReadings utilizza
una chiave di partizione deviceId e una chiave di ordinamento readingTs. Scrivi una lettura per
deviceId = "vac-7741".
Percorso seguito dalla scrittura: dalla chiave al disco su cui si ferma:
La scrittura per vac-7741 viene sottoposta ad hashing fino a un punto nello spazio delle chiavi, in quel punto rientra
La gamma di P2 e l'articolo arriva su P2 — ordinato lì da readingTs.
La cosa da interiorizzare: "vac-7741" e "vac-7742" sono un carattere a parte,
ma i loro hash non sono correlati. Quasi certamente vivono in luoghi diversi
partizioni. Non c'è "nelle vicinanze" nello spazio delle chiavi della partizione.
Questa è l'idea di hashing coerente che DynamoDB ha ereditato dal design originale: il documento Amazon Dynamo del 2007 ("Dynamo: valore-chiave altamente disponibile di Amazon Store") distribuisce le chiavi tra i nodi eseguendo l'hashing esattamente in modo che nessun singolo nodo diventi un collo di bottiglia.
Incolla un elenco di valori delle chiavi di partizione di seguito per vedere come un hash li distribuisce secchi. Un set ad alta cardinalità si diffonde uniformemente; riutilizzare un valore e tutto si accumula in un unico bucket: l' di cui parla la sezione successiva.
Questo è un hash didattico per l'intuizione, non il vero hash interno di DynamoDB: il la funzione effettiva, lo spazio delle chiavi e i limiti della partizione sono interni di AWS. Usalo per creare una sensazione di diffusione rispetto a inclinazione, non di prevedere quale partizione fisica è una chiave atterra su.
Rispetta i limiti rigidi della partizione
Una partizione fisica è finita. Secondo la Guida per sviluppatori AWS DynamoDB, ciascuno regge circa:
| Limite | Per partizione |
|---|---|
| Stoccaggio | ~10GB |
| Velocità effettiva di lettura | 3.000 unità di lettura/s |
| Velocità effettiva di scrittura | 1.000 unità di scrittura/s |
Quando una partizione supera i 10 GB o il throughput assegnato richiede più spazio, DynamoDB lo divide: l'intervallo dello spazio delle chiavi viene diviso e gli elementi vengono ridistribuiti su più partizioni. Questo è automatico; non lo attivi tu.
Una divisione può dividere la raccolta di elementi di una chiave di partizione in corrispondenza di una chiave di ordinamento confine, quindi il carico di una chiave occupata può essere distribuito su più partizioni. Che scissione non è possibile salvare un singolo item attivo, una chiave di ordinamento in costante aumento o una tabella con un LSI: bloccano la raccolta su una partizione.
Assegna un nome alla trappola: partizione hot
Una partizione attiva è la classica arma da fuoco. Succede quando una chiave di partizione valore (o un piccolo insieme di essi) assorbe una quota sproporzionata di traffico.
Fallimento concreto: si passa da SensorReadings a una chiave di partizione region con
valori come "us-east", "eu-west". Tre regioni significano tre valori chiave:
al massimo: tre partizioni che svolgono un lavoro reale. Slam "us-east" con letture e questo
rallenta a 3.000 RCU mentre la capacità totale fornita del tavolo rimane inutilizzata.
La capacità adattiva di DynamoDB attenua questo problema: può spostare il throughput inutilizzato verso una partizione occupata e isola un singolo tasto molto importante da solo partizione. AWS lo ha spiegato dettagliatamente nel re:Invent "Advanced Design Patterns for DynamoDB" sessioni di immersione profonda. Ma la capacità adattiva fa guadagnare tempo, non immunità: a singolo hot item, una chiave di ordinamento sempre crescente o un LSI limita ancora una chiave alla volta partizione unica. Design per la diffusione; non appoggiarti alla rete di sicurezza.
Scegli una chiave ad alta cardinalità
La soluzione è la cardinalità: il numero di valori chiave distinti e il grado di uniformità il traffico li investe.
- Bassa cardinalità (
region,status,true/false): poche partizioni, il traffico si concentra, rallenti presto. - Alta cardinalità (
deviceId,userId, un ID ordine): hashing di molti valori attraverso molte partizioni, il carico si distribuisce e l'headroom aumenta.
Provenendo da SQL indicizzeresti felicemente una colonna status e filtreresti su di essa. Come a
La chiave di partizione DynamoDB è una trappola: non può diffondersi. Mantenere una cardinalità bassa
attributi come filtri o come chiave di ordinamento dell'indice secondario,
mai come la cosa che decide il posizionamento.
Quando una chiave naturalmente buona è ancora distorta: una manciata di inquilini balena supera la
rest — aggiungi un suffisso per distribuire un valore logico su N partizioni, ad es.
tenantId#3 per un percorso di scrittura partizionato. Riaggregi in lettura.
Per indirizzare gli elementi all'interno di una partizione una volta diffusa la chiave, scriverai a
KeyConditionExpression sulla chiave di ordinamento. Puoi assemblarne uno contro il tuo
schema nel creatore di espressioni DynamoDB
prima di collegarlo al codice:
deviceId = "vac-7741" AND readingTs BETWEEN "2026-06-01" AND "2026-06-30"Questo legge la finestra di giugno di un dispositivo da una singola partizione: un Query, non un
Scan. La chiave di partizione blocca la macchina; la chiave di ordinamento
condizione restringe le righe.
Insidie e passaggi successivi
- Non scegliere una chiave in base a ciò che si legge bene in SQL. Sceglila in base a ciò che si diffonde. Prima la cardinalità, poi la comodità delle query.
- Non dare per scontato che la capacità totale della tabella sia tua per chiave. Il throughput lo è per partizione; un valore caldo può rallentare mentre la tabella sembra inattiva.
- Non combattere una scissione. È automatico e guidato dall'hashish: il tuo compito è darlo chiavi abbastanza distinte da diffondere.
Una volta che la chiave si è diffusa in modo pulito, le decisioni successive riguardano come disporre gli oggetti all'interno una partizione - vedere progettazione a tabella singola - e quando a indice secondario è lo strumento giusto per un secondo accesso modello.
Scarica DynoTable ed esegui un GROUP BY sulla chiave di partizione in
SQL Workbench per vedere quali chiavi accumulano elementi prima che uno si trasformi in una partizione attiva.