Nessun SQL design per DynamoDB

Nessun sistema di SQL database come Amazon DynamoDB utilizza 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 senza SQL database come DynamoDB, è importante comprendere le differenze principali e gli approcci di progettazione specifici.

Differenze tra progettazione di dati relazionali e No SQL

I sistemi di database relazionali (RDBMS) e i SQL database No presentano punti di forza e di debolezza diversi:

• InRDBMS, i dati possono essere interrogati in modo flessibile, ma le query sono relativamente costose e non si adattano bene in situazioni di traffico elevato (vedi). Fase iniziale per la modellazione dei dati relazionali in DynamoDB

• In un SQL database No come DynamoDB, i dati possono essere interrogati in modo efficiente in un numero limitato di modi, al di fuori dei quali le query possono essere costose e lente.

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

• InRDBMS, si progetta in modo flessibile senza preoccuparsi dei dettagli di 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 No design SQL

Nessun SQL design richiede una mentalità diversa dalla RDBMS progettazione. Per esempioRDBMS, puoi procedere e 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. Puoi organizzare ogni tipo di dati nella sua tabella.

In che modo nessun SQL design è diverso

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

Avvicinarsi a No design SQL

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 rimodellare i dati quando viene elaborata una query (come fa un RDBMS sistema), un SQL database No organizza i dati in modo che la loro forma nel database corrisponda a quella che verrà interrogata. 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 SQL sistemi No, 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. Si tratta di un'importante strategia di No Design. SQL

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

Nessun SQL workbench per DynamoDB

Nessun SQL workbench per DynamoDBè un'GUIapplicazione multipiattaforma lato client che è possibile utilizzare per lo sviluppo e le operazioni di database moderni. È disponibile per Windows, macOS e Linux. No SQL Workbench è uno strumento di sviluppo visivo che fornisce funzionalità di modellazione, visualizzazione dei dati, generazione di dati di esempio e sviluppo di query per aiutarti a progettare, creare, interrogare e gestire tabelle DynamoDB. Con No SQL Workbench for DynamoDB, puoi creare nuovi modelli di dati o progettare modelli basati su modelli di dati esistenti che soddisfino i modelli di accesso ai dati della tua applicazione. 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.