Un filo conduttore della tecnologia è l’evoluzione – come del resto anche per gli esseri umani. Non è insolito, vedere le cose evolversi e adattarsi mentre il mondo intorno a loro cambia. Un esempio che conosciamo benissimo sono gli aggiornamenti nei software applicativi del nostro pc o del nostro smartphone… Questo adattamento significa che a volte appaiono nuove “varianti” nei nostri strumenti, per servire meglio determinati scopi specifici.
Il mondo del database non fa eccezione. Sin dai tempi di EF Codd e della sua introduzione del modello di dati relazionali, abbiamo visto i database, e le loro esigenze, evolversi da modelli puramente transazionali ACID (Atomic, Consistent, Isolated, Durable), richiedendo maggiore flessibilità, capacità di scalare (in sistemi distribuiti) e velocità (in termini di latenza e velocità effettiva).
Queste evoluzioni potrebbero essere state, in molti casi, le motivazioni per cui si è preferito, in passato, l’adozione dei sistemi RDBMS. Chi lo sa?
In questo articolo, faremo riferimento ai tradizionali database SQL – sistemi di database relazionali – come RDBMS. La loro controparte è la categoria di database NoSQL – che include molti sottotipi.
Panoramica di SQL / RDBMS
Gli RDBMS sono stati la scelta di default per l’archiviazione delle informazioni nei sistemi finanziario, manifatturiero, logistico, del personale e di altro tipo sin dagli anni ’80. Quando Oracle (che prima era conosciuta come Relational Software Inc.), nel 1979 lanciò la sua prima offerta commerciale, il mondo vide un graduale ritiro dei loro predecessori, i cosidetti database gerarchici e di rete legacy, grazue alla facilità d’uso e amministrazione dei nuovi sistemi. Esempi di database RDBMS disponibili oggi includono Oracle, MySQL, Microsoft SQL Server e PostgreSQL.
Gli RDBMS migliorano rispetto ai loro predecessori grazie ad alcune caratteristiche che li rendono indispensabili: supporto per la transazione ACID e facilitazione dell’integrità referenziale. La tolleranza agli errori, l’accuratezza e l’affidabilità hanno reso i RDBMS i veri e propri db transazionali. Tuttavia, con l’avvento del web negli anni ’90 e i “Big Data” nei mid-laugh, sono comparsi nuovi requisiti.
Per gestire l’inondazione di dati a crescita esponenziale e semi-strutturata che, a quel punto, stava diventando comune, gli amministratori facevano domande. È possibile distribuire un RDBMS o limitarne la capacità all’hardware su cui risiedevano? In che modo la distribuzione ha influenzato il throughput? Gli RDBMS supportano la multi-tenancy e questo ha minacciato l’isolamento delle transazioni? I sistemi relazionali possono supportare colonne molto ampie, record a lunghezza variabile, dati semi-o anche non strutturati? Volete un’unica risposta? NoSql.
Panoramica di NoSQL
In realtà, alcune soluzioni “NoSQL” erano già esistenti da un po’ di tempo, ma non avevano guadagnato molta stima al di fuori di domini specifici. Già nel 1966, lo sfortunato linguaggio di programmazione MUMPS supportava un database di valori-chiavi (con transazioni ACID) per, ironia della sorte, l’industria sanitaria. Un altro database di valori-chiavi (per Unix) è stato il dbm di Ken Thompson (di cui un attuale successore è BerkeleyDB).
NoSQL è un termine generico per qualsiasi database che memorizzi i dati in un modo diverso dalle tabelle relazionali rigidamente tipizzate, immutabili nello schema di RDBMS. Oggi esistono diversi tipi comuni di database NoSQL, più adatti a scopi diversi. Tra loro:
- Key-Value stores: ricerca fulminee, tramite una coppia chiave-valore, con capacità di memorizzazione nella cache.
- Document-oriented databases: database che, come i database di Key-Value, utilizzano una chiave per accedere a un valore associato; in un database orientato ai documenti, tuttavia, i dati nel valore non sono opachi al sistema e possono essere utilizzati per ottimizzare la query. I database orientati ai documenti possono memorizzare i loro dati in una notazione come JSON o XML.
- Distributed/Tunably Consistent databases: database distribuiti che consentono all’utente di configurare il compromesso tra coerenza, disponibilità e tolleranza della partizione.
- Wide-Column stores: database che utilizzano tabelle, righe e colonne, come un RDBMS, ma dove nomi e formati di colonne possono variare in base alla riga all’interno della stessa tabella.
- Time-Series databases: database ottimizzati per l’archiviazione e la manipolazione dei dati delle serie temporali (dove i timestamp vengono trattati al meglio come quantità discrete anziché dimensioni matematiche continue).
- Text Search: questi database consentono di archiviare i dati in formato non strutturato o anche come testo normale.
Vale la pena ricordare che molti database NoSQL disponibili oggi forniscono funzionalità da più tipi NoSQL. Ad esempio, sia Apache Cassandra che ScyllaDB sono wide-column stores e distributed, tunably-consistent databases.
Ora che molti database NoSQL raggiungono i compromessi dei RMDBS, molti, se non la maggior parte, utilizzano un linguaggio simile a SQL, per far crescere la loro base di utenti con utenti che hanno già familiarità con SQL. CQL (Cassandra Query Language), Spark, Hive o Presto sono tutti esempi degni di nota. Elasticsearch ha la sua variante SQL. Così come MongoDB…
Differenze chiave tra NoSQL e RDBMS
Oltre ai linguaggi di query (simil SQL), i database NoSQL e RDBMS condividono un’altra cosa: la capacità di memorizzare i dati. La differenza sta nel come.
I database NoSQL offrono alcuni compromessi per ottenere un vantaggio su flessibilità, velocità di ingestione e throughput delle query. Come notato in precedenza, ad esempio, un database coerente consistente offre agli utenti un compromesso regolabile in termini di coerenza se si preferisce una maggiore disponibilità o tolleranza delle partizioni. Inoltre, i database NoSQL perdono o vengono compromessi alcune delle funzionalità di base inerenti a RDBMS, ad esempio chiavi primarie, chiavi esterne, schemi rigidi e tipi di dati (codificati).
Ecco alcune delle principali differenze tra le categorie RDBMS e NoSQL, generalmente:
| NoSQL | SQL / RDBMS |
|---|---|
| Non relazionale | Relazionale |
| Molti tipi non sono basati su tabelle, se lo sono, gli schemi non sono di solito fissi | Schema fisso, basato su tabelle |
| Orizzontalmente scalabile | Verticalmente scalabile |
| Se distribuito, segue il teorema CAP (l’utente può regolare il compromesso tra coerenza, disponibilità e tolleranza della partizione). | Generalmente non distribuito. Le transazioni aderiscono strettamente alle proprietà ACID (Atomic, Consistent, Isolated, Durable). |
Tipi di database NoSQL: confronto di caratteristiche ed esempi
Per comprendere ancora meglio la distinzione, è utile anche osservare le differenze all’interno della categoria dei database NoSQL:
| genere | Esempi | Caratteristiche |
|---|---|---|
| Key-value pair | Redis | Piattaforma di database veloce e in-memory che offre supporto nativo per una vasta gamma di strutture di dati. Spesso usato anche come parte di un sistema di cache o di broker di messaggi. |
| Text search | elasticsearch | Motore di ricerca e analisi di testo completo; funziona quasi in tempo reale, inclusa l’indicizzazione. |
| Document based | MongoDB | Archivio dati distribuito basato su documenti (simile a JSON). Attualmente MongoDB è il DB NoSQL più popolare. |
| Time-series | InfluxDB | DBMS semplice per l’archiviazione di serie temporali, eventi e metriche. |
| Distributed wide column store | Apache Cassandra, ScyllaDB | Magazzino distribuito, a colonne larghe, ideale per ambienti multi-cloud o multi-data center. |
Qual è il migliore e quando utilizzarlo?
Se si potesse rispondere alla domanda “Perché NoSQL?” con poche parole, probabilmente si ridurrebbe in concetti come scalabilità, flessibilità (incluso lo schema e i vincoli di tipo), latenza e performance (incluso il throughput). Considerazioni secondarie possono includere le dimensioni della comunità (e il supporto e la documentazione che si può trovare in rete) o il livello di adozione del settore (popolarità, equivale ad affidabilità e idoneità allo scopo) di una determinata soluzione.
Certo, c’è dell’altro oltre a questo. Mentre le offerte NoSQL sono basate su questi concetti, i database RDBMS rimangono la scelta preferita in settori e applicazioni che coinvolgono dati transazionali, in cui la durabilità basata su ACID è essenziale: autenticazione utente e gestione dei diritti di accesso, assistenza sanitaria, banca, allocazione delle risorse, gestione dell’inventario, carrelli della spesa, solo per citarne solo alcuni. I database RDBMS hanno caratteristiche consolidate di isolamento, sicurezza e integrità referenziale, e credo che, per il momento, non sono requisiti che possono svanire dall’oggi al domani.
Tuttavia, nelle applicazioni che coinvolgono dati analitici a volume elevato e in rapido movimento prodotti da sensori, applicazioni o sistemi complementari, una soluzione NoSQL con caratteristiche o attributi diversi dai RDBMS potrebbe essere più adatta.
NoSQL è un’evoluzione dai database RDBMS per soddisfare meglio esigenze specifiche. Il “migliore” in ogni caso è quello che si adatta alle tue esigenze; ricorda di valutare la tua infrastruttura e il tuo team per trovare le aree in cui le lacune possono diventare punti di forza.
