Chiavi di ordinamento composito in DynamoDB

UN chiave primaria composita è una chiave di partizione più una chiave di ordinamento. Il trucco quello lo rende potente è ciò che inserisci nella chiave di ordinamento: codifica una gerarchia come se fosse una sola stringa delimitata e un singolo Query legge un intero sottoalbero in ordine di ordinamento - no join, nessuna ricorsione, nessun secondo viaggio di andata e ritorno.

Come funzionano le chiavi di ordinamento composite in DynamoDB?

Una chiave di ordinamento composito racchiude una gerarchia in una stringa delimitata — root/photos/2026/ — che DynamoDB memorizza in ordine byte UTF-8. Poiché il layout corrisponde già all'albero, un singolo Query con begins_with(SK, "root/photos/") legge un intero sottoalbero in ordine di percorso. Nessuna unione, nessuna ricorsione, nessun secondo viaggio di andata e ritorno: solo una scansione del prefisso su un contiguofetta .

• La chiave di ordinamento è una stringa ordinabile, non solo un ID. Inserisci un percorso al suo interno — root/photos/2026/ — e DynamoDB memorizza gli elementi della partizione in byte UTF-8 ordinare automaticamente.
• Un delimitatore trasforma le corrispondenze dei prefissi in letture di sottoalberi. begins_with(SK, "root/photos/") restituisce ogni discendente di quella cartella in una query.
• Le chiavi di ordinamento supportano condizioni di intervallo, non filtri arbitrari. Ottieni begins_with, between, >, < — progetta la chiave in modo che la lettura di cui hai bisogno sia prefisso o un intervallo, non Scan.
• Il delimitatore è portante. Scegline uno che non possa apparire in un segmento di percorso, oppure due rami non correlati si scontrano.

Perché la chiave di ordinamento è l'intero gioco

Provenendo da SQL, modelleresti un albero di cartelle con un self-join parent_id e cammineresti in modo ricorsivo: una query per livello. In DynamoDB è una pistola N+1 contro a archivio di valori-chiave che non dispone di join.

DynamoDB memorizza ogni elemento sotto una chiave di partizione ordinato in base alla sua chiave di ordinamento, in UTF-8 ordine dei byte per le stringhe (AWS: Query condizioni chiave). Quindi, se la chiave di ordinamento è il percorso, il layout fisico corrisponde già all'albero. Una lettura diventa una scansione del prefisso su una sezione contigua, non una passeggiata sul grafico.

Questo è il cambiamento: la chiave di ordinamento non è un identificatore a cui corrispondi esattamente. È un indirizzo ordinabile. Progettalo e la query verrà eseguita gratuitamente.

Modella un albero del file system

Supponiamo che tu stia memorizzando alberi di file per account. Una guida per account è la cosa naturale partizione; il percorso al suo interno è la chiave di ordinamento.

Due convenzioni originali che svolgono il lavoro qui:

• PK = DRIVE#<account> mantiene l'intero albero di un account in un unicoraccolta di oggetti, quindi qualsiasi sottoalbero letto è una partizione singola Query.
• SK è il percorso completo con / finale sulle cartelle. La barra finale è intenzionale: fa sì che una cartella venga ordinata prima dei propri figli e la mantenga root/photos/ distinto da un file fratello denominato root/photos.

Legge un sottoalbero in una query

Elenca tutto in "root/photos/" - cartella, sottocartelle e file, in modo ricorsivo:

Query
KeyConditionExpression = PK = :drive AND begins_with(SK, :prefix)
:drive   = "DRIVE#a91"
:prefix  = "root/photos/"

Ciò restituisce root/photos/, root/photos/2026/, beach.jpg e sunset.jpg — in ordine di percorso, in una lettura fatturata. Paghi solo per gli articoli in quella sezione, no l'intero viaggio.

In DynoTable, esegui esattamente questa query begins_with rispetto alla chiave di ordinamento del percorso e al la cartella e i suoi discendenti ritornano nell'ordine del percorso: nessuna sintassi segnaposto da scrivere a mano.

Hai bisogno del KeyConditionExpression grezzo (nomi, valori e begins_with) per il tuo codice? Costruiscilo e copialo nel file DynamoDB Expression Builder.

Elenca un livello, non l'intero sottoalbero

begins_with ti dà la lettura ricorsiva. Per una directory non ricorsiva listato: i figli immediati di root/photos/ e niente di più profondo: memorizza a profondità e aggiungi un intervallo di chiavi di ordinamento più un filtro oppure dividi il percorso in un "genitore" GSI. La versione più semplice: mantenere un attributo parent (root/photos/) e un GSI premuto su di esso.

Una chiave di ordinamento risponde in modo economico alle domande sul prefisso e sull'intervallo. "Diretto solo bambini" è una questione diversa: modellala esplicitamente piuttosto che sperare che a FilterExpression lo rende efficiente. Un filtro viene eseguito dopo la lettura e tu paghi per ogni oggetto che scarta.

Scegli attentamente il delimitatore

Il delimitatore fa parte del contratto dati. Due regole:

• Non deve mai apparire all'interno di un segmento di percorso. Se i nomi dei file possono contenere /, "/" è il delimitatore sbagliato: un file denominato "a/b" non è distinguibile da a cartella "a" contenente "b". Scegli un byte riservato (alcuni team utilizzano # o un controllo char) e vietarlo nei segmenti.
• Attenzione all'ordinamento ai limiti. / (0x2F) ordina prima delle cifre e lettere, che di solito è ciò che desideri per l'ordine degli alberi. Cambia il delimitatore e modifichi l'ordine: verificalo rispetto ai dati reali.

Chiave di ordinamento composita e attributo di ordinamento separato

Le chiavi composite vincono quando le letture sono a forma di sottoalbero e sono importanti per l'ordinamento; il il modello flat-ID vince quando l'albero muta costantemente. Gerarchie con un elevato numero di letture: alberi di file, alberi di categoria, organigrammi: composito snello.

Insidie e passaggi successivi

• Non riempire eccessivamente la chiave. Tutto ciò che codifichi è immutabile e indicizzato solo prefisso. Gli attributi interrogati in base all'uguaglianza appartengono ai rispettivi campi o a GSI, non incastrato nella chiave di ordinamento.
• Una chiave di ordinamento non può eseguire WHERE arbitrariamente. Solo begins_with, between e confronti. Se ti ritrovi a raggiungere un FilterExpression, hai probabilmente ha modellato la chiave in modo sbagliato: vedi Query vs. Scan.
• Approfondire il design chiave vive in design a tabella singola; per quando un sottoalbero legge necessita di un indice invece della tabella di base, vedere GSI vs. LSI.

Costruisci la condizione chiave begins_with con il file Expression Builder, quindi download DynoTable per eseguire queste query di prefisso rispetto alle tue tabelle e guardare un sottoalbero ritornare nell'ordine del percorso. (E l'io-"UNISCITI" a te lasciato indietro in SQL? DynoTable's SQL Workbench funziona ancora quando ne hai bisogno.)