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à.
Fase iniziale per la modellazione dei dati relazionali in DynamoDB
Nota
La progettazione di un NoSQL richiede un approccio diverso rispetto alla progettazione di un RDBMS. Per un sistema RDBMS puoi creare un modello di dati normalizzati senza pensare ai modelli di accesso. Puoi estenderlo in seguito quando si presentano nuovi quesiti e requisiti di query. Per contro, in Amazon DynamoDB, non si inizia a progettare lo schema finché non si sa a quali domande si deve rispondere. È assolutamente essenziale capire da subito i problemi di business e i casi d'uso dell'applicazione.
Per iniziare a progettare una tabella DynamoDB in grado di dimensionare in maniera efficace, è necessario prima seguire alcune procedure per identificare i modelli di accesso richiesti dai sistemi di operations e business support (OSS/BSS) che deve supportare.
Per le nuove applicazioni, revisiona le storie degli utenti sulle attività e obiettivi. Documenta i vari casi d'uso che identifichi e analizza i modelli d'accesso che necessitano.
Per le applicazioni esistenti, analizza i log di query per scoprire come il sistema viene utilizzato al momento e quali sono i modelli della chiave di accesso.
Dopo aver completato il processo, dovresti avere un elenco che può sembrare a quanto segue.
| Modello # | Descrizione del modello di accesso |
|---|---|
| 1 | Ricerca dei dettagli dei dipendenti tramite ID dipendente |
| 2 | Esecuzione di query sui dettagli dei dipendenti tramite Nome dipendente |
| 3 | Trova i numeri di telefono di un dipendente |
| 4 | Trova i numeri di telefono di un cliente |
| 5 | Ricevi ordini per i clienti entro un intervallo di date |
| 6 | Mostra tutti gli ordini aperti entro un intervallo di date |
| 7 | Vedi tutti i dipendenti assunti di recente |
| 8 | Trova tutti i dipendenti in Warehouse |
| 9 | Ottieni tutti gli articoli ordinati per prodotto |
| 10 | Ottieni gli inventari dei prodotti in tutti i magazzini |
| 11 | Ottieni clienti tramite Account Rep |
| 12 | Ottieni ordini tramite Account Rep. |
| 13 | Acquisisci dipendenti con Job Title |
| 14 | Ottieni l'inventario per prodotto e magazzino |
| 15 | Ottieni l'inventario totale dei prodotti |
In un'applicazione reale, l'elenco può essere molto più lungo. Ma questo elenco rappresenta il livello di complessità del modello di query che puoi trovare in un ambiente di produzione.
Un approccio moderno alla progettazione dello schema DynamoDB utilizza principi orientati agli aggregati, raggruppando i dati in base a modelli di accesso anziché a rigidi confini di entità. Questo approccio considera diversi modelli di progettazione:
Progettazione a tabella singola: utilizzo di chiavi di ordinamento composite, indici secondari globali sovraccarichi e modelli di elenchi di adiacenza per archiviare più tipi di entità in un'unica tabella
Progettazione a più tabelle: utilizzo di tabelle separate per entità con caratteristiche operative indipendenti e bassa correlazione di accesso, con opzioni strategiche per interrogazioni tra entità GSIs
Progettazione aggregata: incorporamento dei dati correlati quando vi si accede sempre insieme (Order + OrderItems) o utilizzo di raccolte di articoli per identificare le relazioni (Prodotto+Inventario)
La scelta tra questi approcci dipende dai modelli di accesso specifici, dalle caratteristiche dei dati e dai requisiti operativi. Puoi utilizzare questi elementi per strutturare i dati in modo che un'applicazione possa recuperare ciò di cui hai bisogno per un determinato modello di accesso utilizzando una query singola in una tabella o indice.
Nota
La scelta tra un design a tabella singola e a più tabelle dipende dai requisiti specifici. La progettazione a tabella singola funziona bene quando le entità hanno un'elevata correlazione di accesso e caratteristiche operative simili. La progettazione a più tabelle è preferibile quando le entità hanno requisiti operativi indipendenti, modelli di accesso diversi o quando sono necessari confini operativi chiari. L'esempio di questa guida dimostra un approccio multitabella con aggregazione e denormalizzazione strategiche.
Per utilizzare NoSQL Workbench per DynamoDB per aiutarti a visualizzare la progettazione delle chiavi di partizione, consulta Creazione di modelli di dati con NoSQL Workbench.
