Progettazione NoSQL per DynamoDB

I sistemi di database NoSQL come Amazon DynamoDB utilizzano modelli alternativi per la gestione dei dati, come coppie chiave-valore o archiviazione di documenti. Quando si passa da un sistema di gestione di database relazionali a un sistema di database NoSQL come DynamoDB, è importante comprendere le differenze chiave e gli approcci di progettazione specifici.

Differenze tra la progettazione di dati relazionali e NoSQL.

I sistemi di gestione dei database relazionali (RDBMS) e i database NoSQL, hanno diversi vantaggi e svantaggi:

• Nei sistemi RDBMS, si possono eseguire query sui dati in modo flessibile ma le query sono relativamente costose e non si ridimensionano bene in situazioni di traffico elevato (consulta Fase iniziale per la modellazione dei dati relazionali in DynamoDB).

• In un database NoSQL come DynamoDB, le query possono essere eseguite in modo efficiente in un numero limitato di modi, al di fuori dei quali possono essere costose e lente.

Queste differenze rendono la progettazione del database diversa tra i due sistemi:

• Nei sistemi RDBMS, si progetta tenendo a mente la flessibilità senza doversi preoccupare dei dettagli dell'implementazione o delle prestazioni. L'ottimizzazione delle query in genere non ha ripercussioni sulla progettazione dello schema, ma la normalizzazione è importante.

• In DynamoDB, si progetta lo schema in modo specifico per rendere le query più comuni e importanti il più veloci ed economiche possibile. Le tue strutture di dati sono programmate per i requisiti specifici dei casi d'uso del tuo business.

Due concetti chiave per la progettazione di NoSQL.

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. Puoi organizzare ogni tipo di dati nella sua tabella.

In che modo la progettazione NoSQL è diversa

• Per contro, non è necessario iniziare a progettare lo schema per DynamoDB finché non si sa a quali domande si deve rispondere. È essenziale capire da subito i problemi di business e i casi d'uso dell'applicazione.

• In un'applicazione DynamoDB è necessario mantenere il minor numero possibile di tabelle. Un numero inferiore di tabelle rende le cose più scalabili, richiede una minore gestione delle autorizzazioni e riduce il sovraccarico dell'applicazione DynamoDB. Può anche aiutare a mantenere i costi di backup complessivi più bassi.

Approccio alla progettazione NoSQL.

La prima fase nella progettazione di un'applicazione DynamoDB consiste nell'identificare i modelli di query specifici che il sistema deve soddisfare.

In particolare, è importante capire le tre proprietà fondamentali dei modelli di accesso all'applicazione prima di iniziare:

• Dimensioni dei dati: sapere quanti dati verranno archiviati e richiesti in uno specifico momento aiuterà a determinare la maniera più efficace per distribuire i dati.

• Forma dei dati: invece di modificare i dati quando viene elaborata una query (come nei sistemi RDBMS)., un database NoSQL organizza i dati in modo che la loro forma nel database corrisponda al soggetto della query. Questo è un fattore chiave nell'aumentare la velocità e la scalabilità.

• Velocità dei dati: DynamoDB si dimensiona aumentando il numero di partizioni fisiche disponibili per eseguire le query e distribuendo efficacemente i dati nelle partizioni. Sapere in anticipo quali saranno i carichi di picco delle query potrebbe aiutare a determinare come partizionare i dati per utilizzare al meglio la capacità di I/O.

Dopo aver identificato i requisiti specifici della query, puoi organizzare i dati in casi ai principi generali che definiscono le prestazioni:

• Raggruppamento dei dati correlati.   La ricerca ha dimostrato che il principio della «località di riferimento», che consiste nel tenere insieme i dati correlati in un unico posto, è un fattore chiave per migliorare le prestazioni e i tempi di risposta nei sistemi NoSQL, proprio come si è rivelato importante per l'ottimizzazione delle tabelle di routing molti anni fa.

  Come regola 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.

• Utilizzo dell'ordine di selezione.   Gli elementi correlati possono essere raggruppati e le query possono essere eseguite facilmente se la progettazione della chiave prevede che siano raggruppati. Questa è una strategia di progettazione NoSQL importante.

• Distribuzione delle query.   È inoltre importante che un volume elevato di query non si concentri su una sola parte del database, dove può superare la capacità di I/O. È invece consigliabile progettare chiavi di dati in modo da distribuire il traffico in modo uniforme tra le partizioni il più possibile, evitando gli hot spot.

• Utilizzo di indici secondari globali.   Creando indici secondati globali specifici, puoi abilitare query diverse rispetto a quelle supportate dalla tua tabella principale, che sono comunque veloci e non tanto costose.

Questi principi generali si traducono in alcuni modelli di progettazione comuni che puoi utilizzare per modellare i dati in maniera efficiente in DynamoDB.

NoSQL Workbench per DynamoDB

Nessun SQL workbench per DynamoDB è un'applicazione GUI lato client multipiattaforma per operazioni e sviluppo di database moderni. È disponibile per Windows, macOS e Linux. NoSQL Workbench è uno strumento visuale di sviluppo che offre funzionalità di modellazione, visualizzazione dei dati, generazione di dati di esempio e funzionalità di sviluppo di query che consentono di progettare, creare, eseguire query e gestire le tabelle DynamoDB. Grazie a NoSQL Workbench per DynamoDB, è possibile creare nuovi modelli di dati o progettare modelli in base ai modelli di dati esistenti che soddisfino i pattern di accesso ai dati delle applicazioni. Puoi anche importare ed esportare il modello di dati progettato alla fine del processo. Per ulteriori informazioni, consulta Creazione di modelli di dati con No SQL Workbench.