Cos'è NoSQL? Modelli di dati, differenze con SQL e quando usarlo

I database NoSQL sono una famiglia di database che utilizzano modelli come documenti, coppie chiave-valore, colonne larghe e grafi invece di basarsi sul modello relazionale a tabelle. Scegline uno in base alla forma dei tuoi dati e alle operazioni necessarie alla tua applicazione; l'etichetta NoSQL da sola non garantisce query più rapide o progettazioni più semplici.

SQL (Structured Query Language) è un linguaggio per interrogare e manipolare dati, mentre NoSQL è una categoria che copre diversi modelli. “Not Only SQL” è un modo per spiegare il nome; non significa che ogni prodotto vieti SQL. La Panoramica di AWS NoSQL descrive i diversi modelli e scopi.

I quattro principali modelli di dati NoSQL

Queste categorie descrivono come i dati sono rappresentati. Un prodotto può supportare più modelli e i prodotti nella stessa categoria possono differire nelle capacità di interrogazione e operazione.

Database chiave-valore

Un modello chiave-valore cerca un valore usando una chiave come session:abc123. Consideralo quando l'accesso è prevedibile, come nel recupero di una sessione tramite il suo ID. Cercare condizioni arbitrarie all'interno dei valori richiede di verificare le caratteristiche di indicizzazione e di query del prodotto specifico.

I valori non devono essere semplici stringhe. Redis supporta hash, liste, set e set ordinati oltre alle stringhe, come documentato nel suo riferimento ai tipi di dati. Per una cache, bisogna anche decidere dove risiedono i dati autorevoli, quando scadono le voci e cosa succede quando una voce della cache manca.

Database documentali

Un documento raggruppa i campi, gli array e gli oggetti annidati di un elemento. JSON (JavaScript Object Notation) è un formato testuale per esprimere tali strutture; MongoDB memorizza i documenti usando BSON (Binary JSON). Considera i documenti per elementi con attributi diversi o per dati comunemente letti insieme su un unico schermo.

Scegli tra incorporare informazioni correlate in un documento o fare riferimento all'identificatore di un altro documento in base alla frequenza di accesso, alla dimensione e agli aggiornamenti. Copiare un indirizzo in ogni ordine può semplificare le letture, ma è necessario decidere cosa significa la copia e come viene mantenuta. La guida alla modellazione di MongoDB raccomanda di progettare in base ai modelli di accesso.

Database a colonne larghe

I modelli a colonne larghe organizzano i dati attorno a chiavi di riga o di partizione e colonne. Bigtable utilizza una mappa ordinata per chiave di riga e raggruppa le colonne correlate in famiglie di colonne. La sua documentazione sul modello di archiviazione spiega righe, colonne e famiglie.

Un archivio a colonne larghe non dovrebbe essere trattato come la stessa cosa di un archivio analitico a colonne che raggruppa i valori di una colonna. Cassandra richiede una progettazione di tabelle e partizioni orientata alle query e non supporta join relazionali. La sua introduzione alla modellazione dei dati spiega perché dovresti prima identificare domande come “leggi i record di questo dispositivo per questo periodo.” Verifica che il candidato supporti le query e le aggregazioni a intervallo richieste.

Basi di dati a grafo

Un grafo rappresenta entità, come persone, prodotti o server, come nodi e le loro connessioni come archi. Consideralo per domande che seguono relazioni, come identificare i servizi influenzati da un guasto del server.

Anche i grafi possono memorizzare attributi. Il modello a grafi di proprietà di Neo4j consente di avere proprietà sia sui nodi sia sulle relazioni, come spiegato nella sua guida sui concetti dei grafi. Un modello a grafi non rende ogni query veloce; definisci la profondità del percorso, i tipi di relazione e le condizioni del percorso.

In cosa differisce NoSQL da un database relazionale?

Un sistema di gestione di database relazionale (RDBMS) organizza i dati usando tabelle, chiavi e vincoli. Fornisce una base utile per unire record correlati e applicare regole condivise. Un prodotto NoSQL offre operazioni appropriate al suo modello, quindi confronta come ciascun candidato risponde alle domande della tua applicazione piuttosto che copiare uno schema esistente senza modifiche.

Memorizzare JSON non richiede automaticamente NoSQL. PostgreSQL, ad esempio, offre tipi JSON e indicizzazione per jsonb; vedi la sua documentazione sui tipi JSON. Mantenere le regole relazionali e le transazioni mentre si utilizzano attributi flessibili per una parte dei dati è anche una possibile soluzione progettuale.

Uno schema flessibile necessita ancora di progettazione

Uno schema definisce struttura e regole, come nomi dei campi, tipi e valori richiesti. Anche se i documenti possono avere campi diversi, un'applicazione ha bisogno di dati prevedibili. Questo catalogo JSON fittizio illustra due prodotti con attributi diversi:

[
  {
    "product_id": "book-101",
    "name": "Database Basics",
    "price_krw": 24000,
    "attributes": {
      "author": "Mina Kim",
      "pages": 320
    }
  },
  {
    "product_id": "headphones-201",
    "name": "Wireless Headphones",
    "price_krw": 79000,
    "attributes": {
      "wireless": true,
      "battery_hours": 30
    }
  }
]

Entrambi i prodotti condividono product_id, name e price_krw, ma i loro attributes annidati differiscono. Una struttura di documento esprime quella variazione in modo naturale. Tuttavia, mescolare numeri e stringhe nello stesso campo prezzo può complicare ordinamenti e calcoli, quindi definire i tipi consentiti e la gestione dei valori mancanti.

MongoDB supporta regole di validazione per tipi e intervalli di valori; la sua documentazione sulla validazione degli schemi spiega come applicare le regole dove necessario. Al contrario, CQL (Cassandra Query Language) di Cassandra definisce le colonne e i tipi quando una tabella viene creata, come mostrato nel suo riferimento alla definizione della tabella. Pertanto, dire “Ogni database NoSQL è senza schema” è inaccurato.

JSON descrive una struttura; non è intrinsecamente un dato non strutturato. Decidere separatamente se immagini e video appartengono all'interno di un database o nello storage di oggetti, con le loro posizioni e metadati in un database. La dimensione dei file, i requisiti di consegna e le esigenze di gestione influiscono su questa scelta.

Verificare le garanzie di transazione e coerenza per ciascun prodotto

Supporto e ambito delle transazioni

Una transazione tratta le modifiche come un'unità di lavoro. ACID significa Atomicità, Coerenza, Isolamento e Durabilità. Per le modifiche che devono avere successo o fallire insieme, come la creazione di un ordine e la riduzione dell'inventario, stabilire prima le garanzie necessarie.

NoSQL non implica l'assenza di transazioni. MongoDB supporta transazioni multi-documento sui replica set e sui cluster partizionati (sharded clusters), con garanzie influenzate dalle impostazioni di deployment e lettura/scrittura; vedere la sua documentazione sulle transazioni. DynamoDB fornisce anche API transazionali (Interfacce di Programmazione delle Applicazioni), ma ha restrizioni che includono i target supportati e l'ambito della Regione. La sua documentazione sulle transazioni spiega questi limiti.

Cosa può restituire una lettura subito dopo una scrittura?

Anche il comportamento della replica è importante. Con letture a consistenza eventuale, una scrittura appena completata potrebbe non apparire ancora nel risultato di una lettura. Definisci i requisiti in base all'azione dell'utente: un ordine può essere temporaneamente assente subito dopo che l'utente lo ha salvato?

Le tabelle di DynamoDB e gli indici secondari locali possono utilizzare letture fortemente coerenti, mentre le letture dagli indici secondari globali e dai flussi offrono consistenza eventuale. Consulta la sua documentazione sulla coerenza delle letture per le differenze a seconda dell'obiettivo della query. La coerenza ACID all'interno di una transazione e la coerenza delle letture tra le repliche sono preoccupazioni diverse.

La scala orizzontale non garantisce prestazioni

La scalabilità orizzontale aggiunge server invece di sostituire un server con una macchina più grande. Lo sharding distribuisce i dati tra i server; la replicazione mantiene copie. Solo più server non garantiscono dati bilanciati o query più rapide. La panoramica sullo sharding di MongoDB descrive le configurazioni distribuite separatamente.

Una chiave mal distribuita può concentrare le richieste su una partizione calda. Ad esempio, raggruppare ogni evento sotto una chiave fissa può andare contro la distribuzione del carico. Considera insieme i modelli di accesso e la distribuzione delle chiavi, come spiegato nella guida sulle chiavi di partizione di DynamoDB.

Le prestazioni dipendono dalle dimensioni dei dati, dagli indici, dall'intervallo di query, dalla proporzione lettura/scrittura, dalle impostazioni di coerenza e dal carico di lavoro. Confronta la latenza delle richieste lente, i guasti e il comportamento di recupero insieme al tempo medio di risposta. Includi repliche, backup, rete e lavoro operativo nella valutazione dei costi; la categoria NoSQL da sola non determina un costo inferiore.

Quando dovresti considerare NoSQL?

• Cache a chiave nota o accesso alla sessione: considera un key-value store definendo scadenza, persistenza e sincronizzazione con i dati autorevoli.
• Articoli di catalogo con attributi variabili: considera i documenti progettando la convalida dei campi condivisi e gli indici di ricerca.
• Eventi interrogati tramite una chiave e un periodo noti: considerare l'archiviazione a colonne larghe mentre si controllano le dimensioni della partizione e le query di intervallo.
• Traversamento di relazioni multi-step: considerare un grafo mentre si definiscono i tipi di connessione e la profondità del traversamento.

Quando report variati uniscono più tabelle o vincoli tra record richiedono un'applicazione centralizzata, un database relazionale merita un confronto precoce. Non decidere solo in base a un'etichetta di settore o al volume dei dati: esaminare come funzionerebbero le letture e gli aggiornamenti più importanti in ciascun candidato.

Puoi assegnare ruoli diversi a diversi archivi, come usare un database relazionale come fonte autorevole e un archivio chiave-valore come cache. Archivi aggiuntivi rendono anche più complesse le operazioni di aggiornamento delle copie, la propagazione delle eliminazioni e il recupero, quindi aggiungili solo se c'è una necessità dimostrata.

Una sequenza di valutazione pratica

1. Annota le query importanti. Specifica filtri e ordinamenti per attività come la ricerca di prodotti per ID, gli ordini recenti degli utenti o i record giornalieri di un dispositivo.
2. Definisci i requisiti di correttezza. Registra le modifiche che devono riuscire insieme, la gestione delle richieste duplicate, le letture immediate e i valori obsoleti accettabili.
3. Progetta modelli candidati effettivi. Esamina la dimensione del documento, gli embedding o i riferimenti, gli indici, le chiavi di partizione e i percorsi di query man mano che i dati crescono.
4. Confronta piccole implementazioni. Usa gli stessi dati e operazioni per riprodurre carico normale, carico concentrato e guasti; registra le versioni del prodotto e le impostazioni.
5. Pianifica operazioni e migrazione. Controlla permessi, backup e ripristino, monitoraggio, migrazione, costi previsti e una via di ritorno all’archivio esistente se necessario.

Inizia dalle query e dai requisiti di correttezza, poi scegli un modello e un prodotto che li soddisfino. Se il database che già utilizzi soddisfa tali requisiti, stabilisci la ragione per aggiungere un altro tipo di archivio prima di introdurlo.