Vedo molta confusione sul posto e lo scopo delle molte nuove soluzioni di database (“database NoSQL”) rispetto alle soluzioni di database relazionali che sono in giro da molti anni. Quindi cercherò di spiegare le differenze e i migliori casi d’uso per ciascuno.
Prima di tutto chiariamo queste soluzioni di database in due gruppi:
1) Database relazionali, che possono anche essere chiamati sistemi di gestione di database relazionali (RDBMS) o database SQL. I più popolari sono Microsoft SQL Server, Oracle Database, MySQL e IBM DB2. Questi RDBMS sono per lo più utilizzati in grandi scenari aziendali, con l’eccezione di MySQL, che è principalmente utilizzato per memorizzare i dati per le applicazioni web, tipicamente come parte del popolare stack LAMP (Linux, Apache, MySQL, PHP/ Python/ Perl).
2) I database non relazionali, chiamati anche database NoSQL, i più popolari sono MongoDB, DocumentDB, Cassandra, Coachbase, HBase, Redis e Neo4j. Questi database sono solitamente raggruppati in quattro categorie: Tutti i database relazionali possono essere usati per gestire applicazioni orientate alle transazioni (OLTP), e la maggior parte dei database non relazionali che appartengono alle categorie Archivi di documenti e Archivi di colonne possono anche essere usati per OLTP, aggiungendo ulteriore confusione. I database OLTP possono essere pensati come database “Operativi”, caratterizzati da transazioni frequenti e brevi che includono aggiornamenti e che toccano una piccola quantità di dati e dove la concorrenza di migliaia di transazioni è molto importante (esempi includono applicazioni bancarie e prenotazioni online). L’integrità dei dati è molto importante, quindi supportano transazioni ACID (Atomicità, Consistenza, Isolamento, Durabilità). Questo è opposto ai data warehouse, che sono considerati database “Analitici” caratterizzati da lunghe e complesse query che toccano una grande quantità di dati e richiedono molte risorse. Gli aggiornamenti sono poco frequenti. Un esempio è l’analisi delle vendite nell’ultimo anno.
I database relazionali di solito lavorano con dati strutturati, mentre i database non relazionali di solito lavorano con dati semi-strutturati (cioè XML, JSON).
Guardiamo ogni gruppo più in dettaglio:
Base di dati relazionali
Un database relazionale è organizzato sulla base del modello relazionale dei dati, come proposto da E.F. Codd nel 1970. Questo modello organizza i dati in una o più tabelle (o “relazioni”) di righe e colonne, con una chiave unica per ogni riga. Generalmente, ogni tipo di entità descritta in un database ha la propria tabella con le righe che rappresentano le istanze di quel tipo di entità e le colonne che rappresentano i valori attribuiti a quell’istanza. Poiché ogni riga di una tabella ha la sua chiave unica, le righe di una tabella possono essere collegate a righe di altre tabelle memorizzando la chiave unica della riga a cui dovrebbe essere collegata (dove tale chiave unica è nota come “foreign key”). Codd dimostrò che relazioni di dati di complessità arbitraria possono essere rappresentate usando questo semplice insieme di concetti.
Pirtualmente tutti i sistemi di database relazionali usano SQL (Structured Query Language) come linguaggio per interrogare e mantenere il database.
Le ragioni del dominio dei database relazionali sono: semplicità, robustezza, flessibilità, prestazioni, scalabilità e compatibilità nella gestione di dati generici.
Ma per offrire tutto questo, i database relazionali devono essere incredibilmente complessi internamente. Per esempio, un’istruzione SELECT relativamente semplice potrebbe avere dozzine di potenziali percorsi di esecuzione della query, che un ottimizzatore di query valuterebbe in fase di esecuzione. Tutto questo è nascosto agli utenti, ma sotto il cofano, l’RDBMS determina il miglior “piano di esecuzione” per rispondere alle richieste utilizzando cose come algoritmi basati sui costi.
Per i grandi database, specialmente quelli usati per le applicazioni web, la preoccupazione principale è la scalabilità. Poiché sempre più applicazioni vengono create in ambienti che hanno carichi di lavoro massicci (ad esempio Amazon), i loro requisiti di scalabilità possono cambiare molto rapidamente e crescere molto. I database relazionali scalano bene, ma di solito solo quando questo scaling avviene su un singolo server (“scale-up”). Quando la capacità di quel singolo server viene raggiunta, è necessario “scalare” e distribuire quel carico su più server, passando al cosiddetto calcolo distribuito. Questo è il momento in cui la complessità dei database relazionali inizia a causare problemi con il loro potenziale di scalabilità. Se si cerca di scalare a centinaia o migliaia di server, le complessità diventano schiaccianti. Le caratteristiche che rendono i database relazionali così attraenti sono le stesse che riducono anche drasticamente la loro fattibilità come piattaforme per grandi sistemi distribuiti.
Basi di dati non relazionali
Un database NoSQL fornisce un meccanismo per la memorizzazione e il recupero dei dati che è modellato con mezzi diversi dalle relazioni tabulari usate nei database relazionali.
Le motivazioni per questo approccio includono:
- Semplicità di progettazione. Non avere a che fare con il “mismatch di impedenza” tra l’approccio orientato agli oggetti per scrivere applicazioni e le tabelle basate sullo schema e le righe di un database relazionale. Per esempio, immagazzinare tutte le informazioni sugli ordini dei clienti in un documento invece di dover unire molte tabelle insieme, risultando in meno codice da scrivere, debug e mantenere
- Migliore scalabilità “orizzontale” per cluster di macchine, che risolve il problema quando il numero di utenti concorrenti sale alle stelle per le applicazioni che sono accessibili via web e dispositivi mobili. L’uso di documenti rende molto più facile lo scale-out in quanto tutte le informazioni per l’ordine del cliente sono contenute in un unico posto, invece di essere sparse su più tabelle. I database NoSQL distribuiscono automaticamente i dati sui server senza richiedere modifiche all’applicazione (auto-sharding), il che significa che distribuiscono nativamente e automaticamente i dati su un numero arbitrario di server, senza che l’applicazione debba essere consapevole della composizione del pool di server. I dati e il carico delle query sono automaticamente bilanciati tra i server, e quando un server va giù, può essere rapidamente e trasparentemente sostituito senza interruzione dell’applicazione
- Controllo più fine sulla disponibilità. I server possono essere aggiunti o rimossi senza interruzioni dell’applicazione. La maggior parte dei database NoSQL supporta la replicazione dei dati, memorizzando più copie di dati attraverso il cluster o anche attraverso i data center, per garantire l’alta disponibilità e il disaster recovery
- Per catturare facilmente tutti i tipi di dati “Big Data” che includono dati non strutturati e semi-strutturati. Consentire un database flessibile che può facilmente e rapidamente accogliere qualsiasi nuovo tipo di dati e non è interrotto dai cambiamenti della struttura del contenuto. Questo perché i database di documenti sono privi di schemi, permettendovi di aggiungere liberamente campi ai documenti JSON senza dover prima definire i cambiamenti (schema-on-read invece di schema-on-write). Si possono avere documenti con un numero di campi diverso da quello di altri documenti. Per esempio, un record di un paziente che può contenere o meno campi che elencano allergie
- Velocità. Le strutture dati usate dai database NoSQL (cioè i documenti JSON) differiscono da quelle usate di default nei database relazionali, rendendo molte operazioni più veloci in NoSQL rispetto ai database relazionali grazie al fatto di non dover unire le tabelle (al costo di un aumento dello spazio di archiviazione dovuto alla duplicazione dei dati – ma lo spazio di archiviazione è così economico al giorno d’oggi che di solito non è un problema). Infatti, la maggior parte dei database NoSQL non supportano nemmeno i join
- Costo. I database NoSQL di solito usano cluster di server economici, mentre gli RDBMS tendono ad affidarsi a costosi server proprietari e sistemi di archiviazione. Inoltre, le licenze per i sistemi RDBMS possono essere piuttosto costose, mentre molti database NoSQL sono open source e quindi gratuiti
La particolare idoneità di un dato database NoSQL dipende dal problema che deve risolvere.
I database NoSQL sono sempre più utilizzati nei big data e nelle applicazioni web in tempo reale. Sono diventati popolari con l’introduzione del web, quando i database sono passati da un massimo di poche centinaia di utenti su un’applicazione aziendale interna a migliaia o milioni di utenti su un’applicazione web. I sistemi NoSQL sono anche chiamati “Non solo SQL” per sottolineare che possono anche supportare linguaggi di interrogazione simili a SQL.
Molti negozi NoSQL compromettono la coerenza (nel senso del teorema CAP) in favore della disponibilità e della tolleranza alle partizioni. Alcune ragioni che bloccano l’adozione degli store NoSQL includono l’uso di linguaggi di query di basso livello, la mancanza di interfacce standardizzate e gli enormi investimenti in SQL esistenti. Inoltre, la maggior parte degli store NoSQL manca di vere transazioni ACID o supporta le transazioni solo in certe circostanze e a certi livelli (ad esempio, a livello di documento). Infine, gli RDBMS sono di solito molto più semplici da usare in quanto hanno GUI, mentre molte soluzioni NoSQL usano un’interfaccia a riga di comando.
Confronto tra i due
Una delle limitazioni più gravi dei database relazionali è che ogni elemento può contenere solo un attributo. Se usiamo l’esempio di una banca, ogni aspetto della relazione di un cliente con una banca è memorizzato come elementi di riga separati in tabelle separate. Così i dettagli anagrafici del cliente sono in una tabella, i dettagli del conto sono in un’altra tabella, i dettagli del prestito in un’altra ancora, gli investimenti in un’altra tabella, e così via. Tutte queste tabelle sono collegate l’una all’altra attraverso l’uso di relazioni come le chiavi primarie e le chiavi esterne.
I database non relazionali, in particolare gli archivi chiave-valore di un database o coppie chiave-valore, sono radicalmente diversi da questo modello. Le coppie chiave-valore permettono di memorizzare diversi elementi correlati in una “riga” di dati nella stessa tabella. Mettiamo la parola “riga” tra virgolette perché una riga qui non è proprio la stessa cosa della riga di una tabella relazionale. Per esempio, in una tabella non relazionale per la stessa banca, ogni riga conterrebbe i dettagli del cliente così come i dettagli del suo conto, prestito e investimento. Tutti i dati relativi a un cliente sarebbero convenientemente memorizzati insieme come un unico record.
Questo sembra ovviamente un metodo superiore di memorizzazione dei dati, ma ha un grande svantaggio: gli archivi a valore chiave, a differenza dei database relazionali, non possono imporre relazioni tra i dati. Per esempio, nel nostro database key-value, i dettagli del cliente (nome, previdenza sociale, indirizzo, numero di conto, numero di elaborazione del prestito, ecc.) sarebbero tutti memorizzati come un unico record di dati (invece di essere memorizzati in diverse tabelle, come nel modello relazionale). Le transazioni del cliente (prelievi dal conto, depositi sul conto, rimborsi del prestito, spese bancarie, ecc.) sarebbero anch’esse memorizzate come un altro singolo record di dati.
Nel modello relazionale, c’è un metodo incorporato e infallibile per assicurare e far rispettare la logica di business e le regole a livello di database, per esempio che un prelievo sia addebitato sul corretto conto bancario, attraverso chiavi primarie e chiavi esterne. Negli archivi key-value, questa responsabilità ricade interamente sulla logica dell’applicazione e molte persone sono molto a disagio nel lasciare questa responsabilità cruciale solo all’applicazione. Questo è uno dei motivi per cui i database relazionali continueranno ad essere usati.
Tuttavia, quando si tratta di applicazioni basate sul web che usano i database, l’aspetto di far rispettare rigorosamente la logica di business spesso non è una priorità assoluta. La priorità più alta è la capacità di servire un gran numero di richieste degli utenti, che sono tipicamente query di sola lettura. Per esempio, su un sito come eBay, la maggior parte degli utenti semplicemente naviga e guarda tra gli articoli pubblicati (operazioni di sola lettura). Solo una frazione di questi utenti fa effettivamente offerte o riserva gli oggetti (operazioni di lettura-scrittura). E ricordate, stiamo parlando di milioni, a volte miliardi, di pagine viste al giorno. Gli amministratori del sito eBay sono più interessati a tempi di risposta rapidi per garantire un caricamento più rapido delle pagine per gli utenti del sito, piuttosto che alle priorità tradizionali di far rispettare le regole di business o garantire un equilibrio tra letture e scritture.
I database a modello relazionale possono essere modificati e impostati per eseguire operazioni di sola lettura su larga scala attraverso il data warehousing, e quindi potenzialmente servire una grande quantità di utenti che stanno interrogando una grande quantità di dati, specialmente quando si usano architetture MPP relazionali come Analytics Platform System, Teradata, Oracle Exadata, o IBM Netezza, che supportano tutti lo scaling. Come menzionato prima, i data warehouse si distinguono dai tipici database in quanto sono usati per un’analisi più complessa dei dati. Questo differisce dal database transazionale (OLTP), il cui uso principale è quello di supportare i sistemi operativi e offrire rapporti quotidiani su piccola scala.
Tuttavia, la vera sfida è la mancanza di scalabilità del modello relazionale quando si tratta di applicazioni OLTP, o qualsiasi soluzione con molte scritture individuali, che è il dominio delle architetture SMP relazionali. È qui che i modelli non relazionali possono davvero brillare. Possono facilmente distribuire i loro carichi di dati su decine, centinaia e in casi estremi (si pensi alla ricerca su Google) anche migliaia di server. Con ogni server che gestisce solo una piccola percentuale delle richieste totali degli utenti, il tempo di risposta è molto buono per ogni singolo utente. Anche se questo modello di calcolo distribuito può essere costruito per i database relazionali, è un vero dolore da implementare, specialmente quando ci sono molte scritture (cioè OLTP), richiedendo tecniche come lo sharding che di solito richiede una codifica significativa al di fuori della logica di business dell’applicazione. Questo perché il modello relazionale insiste sull’integrità dei dati a tutti i livelli, che deve essere mantenuta, anche quando i dati sono accessibili e modificati da diversi server. Questa è la ragione per cui il modello non relazionale è l’architettura di scelta per le applicazioni web come il cloud-computing e il social networking.
Quindi, in sintesi, gli RDBMS soffrono della mancanza di scalabilità orizzontale per alti carichi di transazioni (milioni di letture-scritture), mentre i database NoSQL risolvono alti carichi di transazioni ma a costo dell’integrità dei dati e delle giunzioni.
Tenete a mente che molte soluzioni useranno una combinazione di database relazionali e non relazionali (vedi Cos’è la persistenza poliglotta?).
Tenete anche a mente che potreste non aver bisogno delle prestazioni di un database non relazionale e invece basterà archiviare i file in HDFS e usare Apache Hive (Apache Hive è un’infrastruttura di data warehouse costruita sopra Hadoop per fornire la sintesi dei dati, le query e l’analisi che fornisce tramite un linguaggio simile a SQL chiamato HiveQL).
E per finire con una nota che si aggiunge alla confusione, abbiamo un’altra categoria che si forma chiamata NewSQL: NewSQL è una classe di RDBMS moderni che cercano di fornire le stesse prestazioni scalabili dei sistemi NoSQL per carichi di lavoro OLTP in lettura-scrittura, pur mantenendo le garanzie ACID di un sistema di database relazionale tradizionale. Gli svantaggi sono che non sono per le query in stile OLAP, e sono inappropriati per i database oltre qualche terabyte. Gli esempi includono VoltDB, NuoDB, MemSQL, SAP HANA, Splice Machine, Clustrix e Altibase.
Un’immagine che mostra le categorie in cui rientrano molti dei prodotti:
Un eccellente grafico che mostra come tutte le tecnologie si adattano alla nuvola Azure è tratto da Understanding NoSQL on Microsoft Azure:
La linea di fondo per l’utilizzo di una soluzione NoSQL è se si dispone di un’applicazione OLTP che ha migliaia di utenti e ha un database molto grande che richiede una soluzione scale-out e/o sta utilizzando dati JSON, in particolare se questi dati JSON hanno varie strutture. Si ottiene anche il beneficio dell’alta disponibilità, poiché le soluzioni NoSQL memorizzano più copie dei dati. Basta tenere a mente che per le prestazioni si può sacrificare la consistenza dei dati, così come la capacità di unire i dati, usare SQL e fare rapidi aggiornamenti di massa.
Più informazioni:
MySQL vs MongoDB
MySQL vs. MongoDB: Guardando ai database relazionali e non relazionali
10 cose che dovresti sapere sui database NoSQL
Introduzione ai database
Differenza tra SQL e NoSQL: confronto
SQL vs NoSQL Differenze di database spiegate con pochi esempi di DB
NoSQL, NewSQL, o RDBMS: Come scegliere
NewSQL – RDBMS su steroidi
NoSQL vs NewSQL Databases Scegli lo strumento giusto per il lavoro giusto
SQL vs NoSQL: vuoi avere uno storage relazionale di default
Oracle difende i DB relazionali contro i concorrenti NoSQL
Comprendere il NoSQL su Microsoft Azure
Incontrare l’avanguardia dei nuovi database relazionali
A SQL o NoSQL? Questa è la domanda del database
Teorema CAP: Rivisitato
Cosa c’è di veramente nuovo con NewSQL?
MongoDB vs MySQL: Uno studio comparativo sui database
Caratteristiche e differenze dei database SQL e NoSQL