DATABASE SQL vs NoSQL
Database
Un concetto chiave che ogni Data Engineer dovrebbe conoscere
Una delle cose da valutare attentamente quando bisogna lavorare su un progetto è la scelta del Database. Dove verranno salvate le informazioni? Come sono strutturate? Ci saranno delle transazioni importanti? Quanto sarà grande?
Tutte queste, e molte altre, sono domande da porci. La scelta di un Database “errato” può costare il buon esito di un progetto, ecco perché in ESSE I abbiamo specialisti che si occupano di ogni singolo aspetto di progetto, in particolare, per i Database, chiediamo ai nostri Data Engineer che ci danno un’idea sommaria delle scelte che fanno ogni giorno.
DATABASE SQL
L’acronimo SQL sta per Standard Query Language, ed è uno standard che aiuta nell'esecuzione di query sui database relazionali.
Pertanto, questi database sono spesso indicati anche come database SQL.
Il vantaggio principale dei database rispetto ai normali sistemi di archiviazione di file è che riduce in larga misura la ridondanza dei dati, facilita la loro condivisione tra vari utenti e garantisce la sicurezza dei dati i quali possono essere di immensa importanza per un'organizzazione.
Ogni database contiene più tabelle, contenenti dati sotto forma di righe e colonne. Ogni tabella è correlata a una serie di altre tabelle all'interno del database.
COS’È IL DATABASE NoSQL
Il tipo di Database NoSQL (che sta per non solo SQL) è entrato in scena alla fine degli anni 2000. Si tratta di database flessibili, scalabili, economici e senza schema.
Sono nati dalla necessità di gestire le enormi quantità di dati che si generano nel mondo odierno, dati che vengono generati a un ritmo elevato e sono di varietà diverse.
In confronto ai database SQL i database NoSQL sono di più tipi, ognuno con i suoi pro e i suoi contro.
- basati su documenti
- basati su valori-chiave
- basati su colonne larghe
- basati su grafici.
Esaminiamo in profondità alcune delle principali differenze tra i database SQL e NoSQL.
DIFFERENZA TRA DATABASE SQL E NoSQL
- Schema di progettazione
I database SQL sono database relazionali che archiviano i dati in più tabelle correlate. Queste tabelle sono relazioni.
Ogni relazione è organizzata in righe e colonne. Ogni riga è una tupla (cioè un generico elemento di una relazione con attributi in un database relazionale) e contiene un “record” (chiamiamola registrazione) e ogni colonna è un attributo per il quale ogni record di solito contiene un valore. Le tabelle nel database sono correlate utilizzando le chiavi SQL.
Le colonne nella tabella contengono un certo tipo di dati. Se un record contiene dati con un tipo di dati diverso allora il database genererà un errore.
Inoltre, un record deve contenere lo stesso numero di valori del numero di colonne nella tabella o deve fornire esplicitamente un valore NULL. Gli esempi più popolari di database SQL sono MySQL, PostgreSql, Oracle, SQL Server.
Come abbiamo anticipato esistono invece 4 tipi di database NoSQL. Esaminiamoli:
- Database Basati su documenti
- Database Basati su valori-chiave
- database Basati su colonne larghe
- Database Basati su grafici
- Database basati su documenti
Questi database NoSQL archiviano i dati in documenti simil JSON. Ogni documento ha un formato KEY-VALUE, il che significa che i dati sono semi-strutturati. Anche se c'è un valore mancante all'interno di un documento per una chiave, il database non genererà un errore. Un esempio popolare è MongoDB.
- Key-Value Database
Questi database NoSQL archiviano i dati in formato KEY-VALUE. Sia le KEY che le VALUE possono essere qualsiasi cosa, dalle stringhe alle value complesse. Le KEYS vengono archiviate in strutture di indice efficienti (efficent index structures) e possono individuare le values in modo rapido e univoco. I database NoSQL di questo tipo sono ideali per le applicazioni che richiedono un rapido recupero dei dati. Amazon DynamoDB è un esempio di tali database.
- Database ampi basati su colonne
Questo database archivia i dati in record simili a qualsiasi database relazionale, ma ha la capacità di memorizzare un numero molto elevato di colonne dinamiche.
Ciò significa che il numero di valori di colonna per le righe può variare in tali database. Esso raggruppa le colonne, in modo logico, in famiglie di colonne. Cassandra è un esempio popolare di database NoSQL di questo tipo.
- Database basati su grafi
Questo tipo di database usa i nodi per memorizzare entità di dati come luoghi, prodotti, ecc. E bordi per memorizzare la relazione tra loro. Non c'è limite al numero e al tipo di relazioni che un nodo può avere.
Neo4j è un esempio di tali database NoSQL.
- Struttura dei dati
Determinare la struttura o lo schema del database prima di aggiungere dati è un prerequisito per i database SQL.
Ciò significa che questo tipo di database può memorizzare solo dati strutturati.
Questo rende molto rigida la gestione dei dati provenienti dal mondo reale e generati a un ritmo elevato. L'aggiornamento dello schema richiede molto tempo e impegno e richiede l'aggiornamento di molte relazioni.
I database NoSQL invece non hanno una struttura fissa e possono gestire qualsiasi tipo di dati: dati strutturati, semi-strutturati o non strutturati. Ciò significa che anche se i dati in entrata hanno un numero diverso di attributi, il database sarà in grado di gestirli senza errori. Questo rende i database NoSQL molto popolari perché si può facilmente modificare lo schema senza troppe interruzioni.
- Velocità
Non c'è una vera differenza tra i due quando si tratta di velocità. Entrambi funzionano ugualmente bene nella maggior parte degli scenari. Tuttavia, si possono notare alcune differenze quando si tratta di gestire query complesse e set di dati di grandi dimensioni.
I database SQL richiedono che l'archiviazione dei dati sia nella forma normalizzata per evitare la ridondanza. Sebbene ciò riduca la quantità di memoria richiesta dal database e garantisca un facile aggiornamento dei record, può avere qualche effetto durante il processo di querying del database.
Ad esempio, l'esecuzione di query complesse come le join su un database contenente più tabelle può rivelarsi piuttosto faticosa, soprattutto quando la dimensione dei dati diventa piuttosto significativa. I database NoSQL superano questo svantaggio.
I database NoSQL infatti non si preoccupano se c'è una duplicazione dei dati perché l'archiviazione non è un problema. I dati nei database NoSQL vengono generalmente archiviati in un modo ottimizzato per le query. Ciò significa che è possibile memorizzare i dati nello stesso modo in cui li richiederesti dopo aver eseguito una query. Questo solleva l'intero problema dei join per un lancio e rende il compito di querying molto più veloce.
Ad esempio, i database SQL richiedono di mantenere due tabelle separate per le informazioni sui dipendenti e le informazioni sul reparto, collegandole con una chiave esterna, forse l'ID del reparto.
Tuttavia, nel caso di database NoSQL, come MongoDB, è possibile memorizzare le informazioni complete sul dipendente, comprese le informazioni sul reparto, all'interno dello stesso documento, sebbene sia possibile eseguire alcuni annidamenti di valori se lo si desidera.
- Ridimensionamento / Scalabilità
I database SQL vengono eseguiti su macchine tradizionali. Ciò significa che vengono eseguiti su un singolo server. Ora, se supera la capacità attuale del server, bisognerebbe usare una CPU più potente, aggiungere più RAM, impilare lo spazio di archiviazione, ecc. Questo è quello che chiamiamo scalabilità verticale e può rivelarsi piuttosto costoso, soprattutto se si ha a che fare con i Big Data (nell'ordine di TB, GB, PB, ecc.)
I database NoSQL d'altra parte offrono quella che chiamiamo scalabilità orizzontale. Ciò significa che se si esaurisce la capacità, è possibile semplicemente aggiungere una macchina al cluster (un gruppo di macchine che lavorano insieme). Queste macchine sono generalmente molto più economiche e sono giustamente indicate come hardware di base. Questa capacità dei database NoSQL ha un altro vantaggio importante: la distribuzione dei dati.
I database NoSQL di solito vengono eseguiti su un numero di macchine interconnesse noto come cluster. I dati vengono distribuiti tra le macchine all'interno del cluster. Ogni macchina memorizzerà una parte dei dati.
Perché è utile?
Ebbene, la distribuzione dei dati ci offre la capacità di replicare i dati e offrire tolleranza ai guasti. Ciò significa che una parte dei dati potrebbe essere replicata e archiviata su più macchine.
Se una macchina si guasta, i dati su di essa saranno presenti su un'altra macchina nel cluster e potranno essere utilizzati senza che l’utente si accorga del guasto, offrendo così la tolleranza agli errori. Questo ovviamente non è possibile con i database SQL perché la memorizzazione di tutti i dati è sulla stessa macchina.
- Principi guida
Uno dei principali vantaggi dei database SQL è la loro capacità di gestire l'elaborazione transazionale. Questi processi modificano il contenuto di un database. Le proprietà ACID dei database SQL governano:
Atomicity: - le transazioni vengono eseguite una alla volta o non avvengono affatto.
Consistency: - questo garantisce che il database non venga lasciato in uno stato completo a metà. Se si verifica un errore, garantisce che vengano eseguite le modifiche di rollback.
Isolation: - le transazioni avvengono in modo indipendente. Nessuna transazione ha accesso a qualsiasi altra transazione.
Durability: - le modifiche apportate al database tramite le transazioni al completamento vengono salvate nel database e gli aggiornamenti non vengono persi.
I database NoSQL d'altra parte non forniscono interamente le proprietà ACID e sono invece governati da quello che chiamiamo il teorema CAP:
Consistency - Ciò significa che l'utente dovrebbe essere in grado di vedere gli stessi dati indipendentemente dal nodo / macchina a cui si connette sul sistema / cluster. Quindi, se un dato è stato scritto su un nodo, dovrebbe essere replicato su tutte le sue repliche.
Availability: significa che ogni richiesta dell'utente dovrebbe suscitare una risposta dal sistema. Se l'utente desidera leggere o scrivere, dovrebbe ricevere una risposta anche se l'operazione non ha avuto successo.
Partition Tolerance: La partizione si verifica quando un nodo non può ricevere messaggi da un altro nodo nel sistema. Potrebbe accadere a causa di un errore di rete, un arresto anomalo del server o qualsiasi altro motivo. Pertanto la tolleranza della partizione garantirà che il sistema sia ancora in grado di funzionare anche se nel sistema è presente una partizione.
Tuttavia, i database NoSQL devono fare un compromesso tra Consistency e Availability quando si verifica una partizione. Questo perché, in un “sistema del mondo reale”, la partizione è destinata a verificarsi a causa di un errore di rete o per qualche altro motivo. Pertanto, quando si verifica una partizione, un database NoSQL deve rinunciare alla Consistency o all’availability. Quindi, un database distribuito NoSQL è caratterizzato come CP (Consistency / Partition Tolerance) o AP (Availability / Partition Tollerance).
Nota: “ Bisogna però notare che i database NoSQL non sono così rigidi quando si tratta di C.A.P. La maggior parte di essi fornisce ad oggi opzioni per bilanciare tra la Consistency e l’Availability.
Pertanto, la scelta non è sempre così bianca e nera”.
Veniamo ora all’ultimo punto della nostra trattazione, l’utilizzo, un punto di grande importanza per chi deve orientarsi nella scelta tra un Database SQL e Database NoSQL
- Utilizzo
La proprietà ACID rende i database SQL di enorme valenza nei campi in cui le transazioni sono estremamente importanti. Ad esempio nel settore bancario, in cui le transazioni di denaro devono essere gestite correttamente, soprattutto in caso di trasferimento non riuscito, il cui fallimento può costare una fortuna.
Inoltre, se i dati saranno strutturati e immutabili, non c'è motivo di utilizzare database NoSQL. Puoi sempre sfruttare le capacità dei tuoi database SQL e, naturalmente, la tua conoscenza stellare dell’SQL!
Tuttavia, se bisogna lavorare con un grande volume di dati senza una struttura impostata i database NoSQL sono la scelta migliore! Ma anche i database NoSQL possono avere casi d'uso ad ampio raggio a seconda della struttura intrinseca e della loro preferenza per le proprietà del teorema CAP.
Mentre da un lato “ElasticSearch” memorizza i dati di registro, Cassandra dall'altra è utilizzata da molti siti di social network. Tuttavia, tutto ciò alla fine della giornata aiuta a gestire il volume, la velocità e la varietà dei Big Data!
FONTE:
https://www.analyticsvidhya.com/blog/2020/10/sql-vs-nosql-databases-a-key-concept-every-data-engineer-should-know