Principali differenze e principi di progettazione della progettazione NoSQL

I sistemi di database NoSQL come Amazon Keyspaces 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 Amazon Keyspaces, è importante comprendere le differenze principali 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 Migliori pratiche di modellazione dei dati: consigli per la progettazione di modelli di dati).

• In un database NoSQL come Amazon Keyspaces, 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:

• 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 Amazon Keyspaces, progetti lo schema in modo specifico per rendere le query più comuni e importanti il più velocemente 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

• Al contrario, non dovresti iniziare a progettare il tuo schema per Amazon Keyspaces finché non conosci le domande a cui deve rispondere. È essenziale capire da subito i problemi di business e i casi d'uso dell'applicazione.

• È necessario mantenere il minor numero possibile di tabelle in un'applicazione Amazon Keyspaces. Avere meno tabelle mantiene le cose più scalabili, richiede una minore gestione delle autorizzazioni e riduce il sovraccarico per l'applicazione Amazon Keyspaces. Può anche aiutare a mantenere i costi di backup complessivi più bassi.

Approccio alla progettazione NoSQL.

Il primo passaggio nella progettazione di un'applicazione Amazon Keyspaces 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:

• Dimensione dei dati: sapere quanti dati verranno archiviati e richiesti contemporaneamente aiuta a determinare il modo più efficace per partizionare 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: Amazon Keyspaces si ridimensiona aumentando il numero di partizioni fisiche disponibili per elaborare le query e distribuendo in modo efficiente i dati tra tali 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.   Studi di ricerca sull'ottimizzazione della tabella di routing effettuati 20 anni fa hanno dimostrato che "l'ubicazione di riferimento" era il fattore più importante nel velocizzare il tempo di risposta, ovvero mantenere i dati correlati in un'unica posizione. Al giorno d'oggi, ciò vale anche nei sistemi NoSQL, dove tenere i dati correlati a distanza ravvicinata ha un impatto importante sui costi e sulle prestazioni. Invece di distribuire gli elementi con dati correlati su tabelle multiple, devi tenere gli elementi correlati il più vicino possibile nel tuo sistema NoSQL.

  Come regola generale, è necessario mantenere il minor numero possibile di tabelle in un'applicazione Amazon Keyspaces.

  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 non vi sia una concentrazione di un volume alto di query in una parte di database, dove possono eccedere la capacità di I/O. Invece, devi progettare chiavi di dati per distribuire il traffico il più possibile in maniera uniforme tra le partizioni, evitando "hot spot".

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