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à.

Best practice per la gestione di relazioni molti a molti nelle tabelle DynamoDB

Gli elenchi di adiacenza sono un pattern di progettazione utile per la modellazione di relazioni molti-a-molti in Amazon DynamoDB. Più in generale, forniscono un modo per rappresentare i dati grafici (nodi ed edge) in DynamoDB.

Modello di progettazione elenchi di adiacenza

Quando diverse entità di un'applicazione hanno una relazione molti-a-molti tra di loro, la relazione può essere modellata come un elenco di adiacenza. In questo modello, tutte le entità di primo livello (sinonimi di nodi nel modello grafico) vengono rappresentate utilizzando la chiave di partizione. Qualsiasi relazione con altre entità (edge in un grafico) viene rappresentata come voce in una partizione impostando il valore della chiave di ordinamento sull'ID dell'entità target (nodo target).

I vantaggi di questo modello comprendono una duplicazione minima dei dati e modelli di query semplificati per trovare tutte le entità (nodi) legate a un'entità target (avendo un edge in un nodo target).

Un esempio reale dove questo modello è stato utile è un sistema di fatturazione dove le fatture contengono ricevute multiple. Una ricevuta può appartenere a fatture multiple. La chiave di partizione in questo esempio è un InvoiceID o un BillID. Le partizioni BillID hanno tutti gli attributi specifici delle fatture. Le partizioni InvoiceID hanno una voce che contiene attributi specifici delle fatture e una voce per ogni BillID che si trova nella fattura.

Lo schema ha il seguente aspetto.

Utilizzando lo schema precedente, puoi vedere che per tutte le ricevute per una fattura può essere eseguita una query utilizzando la chiave primaria nella tabella. Per controllare tutte le fatture che contengono una parte di ricevuta, crea un indice secondario globale nella chiave di ordinamento della tabella.

Le previsioni per l'indice secondario globale hanno il seguente aspetto.

Modello grafico materializzato

Molte applicazioni devono comprendere le classifiche tra pari, le relazioni tra entità e lo stato delle entità vicine. Se la tua applicazione utilizza questi tipi di flussi di lavoro in stile grafico, considera il seguente schema di progettazione.

Come esempio reale, prendete in considerazione un'applicazione di social networking. In questa applicazione, le persone hanno relazioni con altre persone, possiedono competenze, vivono in luoghi e hanno date associate (come le date di nascita). Ogni persona è un nodo nel grafico. Le connessioni tra le persone, come le amicizie, sono dei limiti. Anche le associazioni tra le persone e i loro attributi (competenze, luoghi, date) sono dei limiti.

Con il pattern grafico materializzato, puoi memorizzare sia i nodi che i bordi in un'unica tabella DynamoDB e attraversare le relazioni in modo efficiente. I seguenti diagrammi mostrano come modellare questo grafico di social network. Il primo diagramma mostra la struttura principale della tabella. I diagrammi successivi mostrano le proiezioni dell'indice secondario globale.

La tabella utilizza la seguente struttura chiave:

Le voci edge contengono un attributo Target e Type. Questi costituiscono la chiave composita "TypeTarget" che identifica gli elementi nella tabella primaria e nel secondo indice secondario globale. Ad esempio, "Person-1 è amico di Person-2" produce Type=FriendTarget=Person-2, eTypeTarget=Friend-Person-2.

Il primo indice secondario globale è costruito sull'attributo Data. Questo attributo utilizza l'overload globale dell'indice secondario per indicizzare diversi tipi di attributi all'interno dello stesso indice:

È possibile utilizzare questo unico indice secondario globale per eseguire ricerche su tutte le persone nate in una data specifica, tutte le persone in una località o tutte le persone con una competenza specifica.

Il secondo indice secondario globale viene utilizzato TypeTarget come chiave di partizione per le ricerche inverse. Ad esempio, puoi trovare tutte le persone che sono elencate Person-2 come amici eseguendo una query per. TypeTarget=Friend-Person-2

Quando inserite degli elementi nella tabella, potete utilizzare una strategia di sharding intelligente per distribuire i set di elementi con grandi aggregazioni (data di nascita, abilità) su tutte le partizioni logiche sugli indici secondari globali necessarie per evitare problemi indesiderati. read/write

Con questa combinazione di modelli di progettazione, si ottiene un solido archivio dati per flussi di lavoro grafici in tempo reale altamente efficienti. Puoi utilizzarlo per creare query di aggregazione dei margini e dello stato delle entità adiacenti ad alte prestazioni per motori di raccomandazione, applicazioni di social networking, classifiche dei nodi, aggregazioni di sottoalberi e altri casi d'uso comuni dei grafici.

Se il tuo caso d'uso non è sensibile alla coerenza dei dati in tempo reale, è possibile utilizzare un processo Amazon EMR programmato per popolare gli edge con aggregazioni di riepilogo grafico rilevanti per i flussi di lavoro. Se la tua applicazione non deve sapere immediatamente quando un edge è aggiunto al grafico, puoi utilizzare un processo programmato per aggregare i risultati.

Per mantenere un certo divello di coerenza, la progettazione può includere Amazon DynamoDB Streams e AWS Lambda per elaborare gli aggiornamenti edge. Può anche utilizzare un processo Amazon EMR per convalidare i risultati a un intervallo regolare. Questo approccio viene illustrato nel seguente diagramma. Viene comunemente utilizzato nelle applicazioni di social network dove il costo di una query in tempo reale è alta e la necessità di ottenere aggiornamenti all'utente individuale è bassa.

Le applicazioni di gestione dei servizi IT (ITSM) e di sicurezza in genere devono rispondere in tempo reale alle modifiche all'entità stato composte da aggregazioni degli edge complesse. Tali applicazioni necessitano di un sistema che può supportare aggregazioni dei nodi multiple in tempo reale di relazioni di secondo e terzo livello o elementi trasversali di edge complessi. Se il tuo caso d'uso richiede questi tipi di flusso di lavoro grafici di query in tempo reale, consigliamo l'utilizzo di Amazon Neptune per gestire questi flussi di lavoro.