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
Importante
Nessun SQL design richiede una mentalità diversa dalla progettazione. RDBMS In primo luogoRDBMS, è possibile creare un modello di dati normalizzato 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 scalare in modo efficiente, è necessario innanzitutto eseguire diversi passaggi per identificare i modelli di accesso richiesti dai sistemi operativi e di supporto aziendale 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.
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 comune alla progettazione dello schema di DynamoDB è identificare le entità a livello di applicazione e utilizzare la denormalizzazione e l'aggregazione delle chiavi composite per ridurre la complessità delle query.
In DynamoDB, ciò significa utilizzare chiavi di ordinamento composite, indici secondari globali sottoposti a overload, tabelle/indici partizionati e altri modelli di progettazione. 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. Il modello primario che puoi utilizzare per modellare lo schema normalizzato visualizzato in Modellazione relazionale è il modello dell'elenco di adiacenza. Altri modelli utilizzati in questa progettazione possono includere il partizionamento di scrittura dell'indice secondario globale, l'overload dell'indice secondario globale, le chiavi composite e le aggregazioni materializzate.
Importante
In generale, è necessario mantenere il minor numero possibile di tabelle in un'applicazione DynamoDB. Le eccezioni sono i casi in cui sono coinvolti dati di serie temporali a volumi elevati o i set di dati che hanno modelli di accesso molto diversi. Una tabella singola con indici invertiti possono solitamente abilitare query semplici per creare ed estrarre strutture di dati gerarchici complesse richieste dalla tua applicazione.
Per utilizzare No SQL Workbench for DynamoDB per aiutarti a visualizzare il design della chiave di partizione, consulta. Creazione di modelli di dati con NoSQL Workbench
