Le traduzioni sono generate tramite traduzione automatica. In caso di conflitto tra il contenuto di una traduzione e la versione originale in Inglese, quest'ultima prevarrà.

Elementi costitutivi della modellazione dei dati in DynamoDB

In questa sezione verranno descritti i modelli di progettazione (o elementi costitutivi) che puoi utilizzare per l'applicazione.

Blocco costitutivo di chiave di ordinamento composita

Quando le persone pensano al NoSQL, possono anche considerarlo non relazionale. In definitiva, non c'è un motivo per cui le relazioni non possono essere inserite in uno schema DynamoDB; hanno semplicemente un aspetto diverso rispetto ai database relazionali e alle relative chiavi esterne. Uno dei modelli più critici che possiamo utilizzare per sviluppare una gerarchia logica dei dati in DynamoDB è una chiave di ordinamento composita. Lo stile di progettazione più comune è quello in cui ogni livello della gerarchia (livello padre > livello figlio > livello nipote) è separato da un hashtag. Ad esempio PARENT#CHILD#GRANDCHILD#ETC.

Sebbene una chiave di partizione in DynamoDB richieda sempre il valore esatto per eseguire query sui dati, possiamo applicare alla chiave di ordinamento una condizione parziale da sinistra a destra, simile all'attraversamento di un albero binario.

Nell'esempio precedente, è disponibile un negozio di e-commerce con un carrello acquisti che deve essere mantenuto tra le sessioni utente. Ogni volta che l'utente esegue l'accesso, può scegliere di visualizzare l'intero carrello acquisti, inclusi gli elementi salvati per uso futuro. Tuttavia, al momento del pagamento, solo gli elementi nel carrello attivo devono essere caricati per l'acquisto. Poiché entrambi richiedono KeyConditions esplicitamente chiavi di CART ordinamento, i dati aggiuntivi della lista dei desideri vengono semplicemente ignorati da DynamoDB in fase di lettura. Sebbene gli elementi salvati e attivi facciano entrambi parte dello stesso carrello, devono essere gestiti in modo diverso nelle diverse parti dell'applicazione. Pertanto, l'applicazione di una KeyCondition al prefisso della chiave di ordinamento è il modo più ottimizzato per recuperare solo i dati necessari per ciascuna parte dell'applicazione.

Funzionalità principali di questo elemento costitutivo

Elemento costitutivo di multilocazione

Molti clienti utilizzano DynamoDB per ospitare dati per applicazioni multi-tenant. Per questi scenari, desideriamo progettare lo schema in modo da mantenere tutti i dati di un singolo tenant nella propria partizione logica della tabella. Questo sfrutta il concetto di raccolta di elementi, che è un termine per tutti gli elementi in una tabella DynamoDB con la stessa chiave di partizione. Per ulteriori informazioni su come DynamoDB approccia la multilocazione, consulta Multitenancy on DynamoDB.

In questo esempio, gestiamo un sito di hosting di foto con potenzialmente migliaia di utenti. Inizialmente ogni utente caricherà foto solo sul proprio profilo, ma per impostazione predefinita un utente non può visualizzare le foto di qualsiasi altro utente. L'ideale sarebbe aggiungere un ulteriore livello di isolamento all'autorizzazione della chiamata di ogni utente all'utente per API garantire che richieda dati solo dalla propria partizione, ma a livello di schema sono sufficienti chiavi di partizione univoche.

Funzionalità principali di questo elemento costitutivo

Elemento costitutivo di indice Sparse

A volte un modello di accesso richiede la ricerca di elementi che corrispondono a un elemento raro o a un elemento che riceve uno stato (che richiede una risposta riassegnata). Piuttosto che interrogare regolarmente l'intero set di dati per individuare questi elementi, possiamo sfruttare il fatto che gli indici secondari globali () sono scarsamente caricati di dati. GSI Ciò significa che solo gli elementi della tabella di base che dispongono degli attributi definiti nell'indice verranno replicati nell'indice.

In questo esempio, vediamo un caso IOT d'uso in cui ogni dispositivo sul campo riporta regolarmente uno stato. Per la maggior parte dei report, ci aspettiamo che il dispositivo segnali tutto, ma a volte può essere presente un guasto che deve essere riassegnato a un tecnico di riparazione. Per i report con un'escalation, l'attributo EscalatedTo viene aggiunto all'elemento, ma non è altrimenti presente. GSIIn questo esempio è partizionato per EscalatedTo e, poiché le chiavi di GSI riporto dalla tabella di base, possiamo ancora vedere quale DeviceID ha segnalato l'errore e a che ora.

Sebbene le letture siano più economiche delle scritture in DynamoDB, gli indici Sparse sono uno strumento molto potente per casi d'uso in cui le istanze di un tipo di elemento specifico sono rare, ma le letture per trovarle sono comuni.

Funzionalità principali di questo elemento costitutivo

Elemento costitutivo di Time to Live

La maggior parte dei dati ha una certa durata per cui può essere considerato utile mantenerli in un datastore primario. Per facilitare l'invecchiamento dei dati da DynamoDB, è disponibile una funzionalità chiamata time to live (). TTL La TTLfunzionalità consente di definire un attributo specifico a livello di tabella che deve essere monitorato per gli elementi con un timestamp epocale (appartenente al passato). Ciò consente di eliminare gratuitamente i record scaduti dalla tabella.

In questo esempio, è disponibile un'applicazione progettata per consentire a un utente di creare messaggi di breve durata. Quando un messaggio viene creato in DynamoDB, TTL l'attributo viene impostato su una data futura di sette giorni dal codice dell'applicazione. In circa sette giorni, DynamoDB rileverà che il timestamp di epoca di questi elementi appartiene al passato e li eliminerà.

Poiché le eliminazioni effettuate da TTL sono gratuite, si consiglia vivamente di utilizzare questa funzionalità per rimuovere i dati storici dalla tabella. Ciò ridurrà le spese mensili di archiviazione complessive e i costi delle letture utente poiché le query devono recuperare una quantità minore di dati. Sebbene TTL sia abilitato a livello di tabella, sta all'utente decidere per quali elementi o entità creare un TTL attributo e per quanto tempo nel futuro impostare il timestamp dell'epoca.

Funzionalità principali di questo elemento costitutivo

Time to Live per elemento costitutivo di archiviazione

Sebbene TTL sia uno strumento efficace per eliminare i dati più vecchi da DynamoDB, molti casi d'uso richiedono che un archivio dei dati venga conservato per un periodo di tempo più lungo rispetto al datastore principale. In questo caso, possiamo sfruttare TTL l'eliminazione temporizzata dei record per inserire i record scaduti in un datastore a lungo termine.

Quando un'TTLeliminazione viene eseguita da DynamoDB, viene comunque inserita nel flusso DynamoDB come evento. Delete Tuttavia, quando TTL DynamoDB è colui che esegue l'eliminazione, c'è un attributo nel record dello stream di. principal:dynamodb Utilizzando un abbonato Lambda al flusso DynamoDB, possiamo applicare un filtro sugli eventi solo per l'attributo principale di DynamoDB e sapere che gli eventuali record che corrispondono a tale filtro devono essere inviati a un archivio come S3 Glacier.

Funzionalità principali di questo elemento costitutivo

Elemento costitutivo di partizionamento verticale

Gli utenti che hanno dimestichezza con un database di modelli documentali conosceranno l'idea di archiviare tutti i dati correlati all'interno di un unico documento. JSON Sebbene DynamoDB JSON supporti i tipi di dati, non supporta KeyConditions l'esecuzione su nested. JSON Poiché KeyConditions sono i fattori che determinano la quantità di dati letti dal disco e la quantità effettivamente utilizzata da RCUs una query, ciò può comportare inefficienze su larga scala. Per ottimizzare meglio le scritture e le letture di DynamoDB, si consiglia di suddividere le singole entità del documento in singoli elementi DynamoDB, operazione nota anche come partizionamento verticale.

Il partizionamento verticale, come mostrato in precedenza, è un esempio chiave di progettazione tabella singola, ma può anche essere implementato su più tabelle, se lo si desidera. Poiché DynamoDB addebita le scritture in incrementi di 1 KB, devi partizionare idealmente il documento in un modo che generi inferiori a 1 KB.

Funzionalità principali di questo elemento costitutivo

Elemento costitutivo di partizionamento di scrittura

Uno dei pochi limiti fissi implementati da DynamoDB è la limitazione della velocità di trasmissione effettiva che una singola partizione fisica può mantenere al secondo (non necessariamente una singola chiave di partizione). Questi limiti sono attualmente:

Nel caso in cui le richieste inviate alla tabella superino uno di questi limiti, viene inviato un errore al client SDK diThroughputExceededException, più comunemente noto come throttling. I casi d'uso che richiedono operazioni di lettura oltre tale limite saranno per lo più gestiti al meglio posizionando una cache di lettura davanti a DynamoDB, ma le operazioni di scrittura richiedono una progettazione a livello di schema nota come partizionamento di scrittura.

Per risolvere questo problema, un numero intero casuale verrà aggiunto alla fine della chiave di partizione per ogni partecipante nel codice UpdateItem dell'applicazione. L'intervallo del generatore di numeri interi casuali dovrà avere un limite superiore che corrisponde o supera la quantità prevista di scritture al secondo per un determinato partecipante diviso 1000. Per supportare 20.000 voti al secondo, l'aspetto è simile a rand (0,19). Ora che i dati sono archiviati in partizioni logiche separate, devono essere ricombinati in fase di lettura. Poiché i totali dei voti non devono essere in tempo reale, una funzione Lambda pianificata per leggere tutte le partizioni di voto ogni X minuti può eseguire un'aggregazione occasionale per ogni partecipante e riscriverla in un singolo record totale di voti per le letture dal vivo.

Funzionalità principali di questo elemento costitutivo