Nella scelta di un database (db) una delle prime decisioni da prendere è se affidarsi a un modello relazionale (SQL) o non (NoSQL): soluzioni entrambe valide a seconda dell’uso. Andiamo allora ad analizzare i punti più importanti che ci porteranno a decidere quale database farà al caso nostro.

Il linguaggio 

SQL nasce nel 1974 come strumento per lavorare con database che seguono il modello relazionale. Il che gli ha dato la possibilità, nel corso degli anni, di essere ampiamente riconosciuto e utilizzato rispetto a NoSQL, apparso per la prima volta nel 1998. 

Pur risultando versatile e particolarmente adatto per query complesse, SQL limita l’utente a lavorare all’interno di uno schema tabellare predefinito e richiede tempo per organizzare e studiare i dati prima di poter essere utilizzato. Gli schemi dinamici dei database NoSQL permettono invece la rappresentazione di strutture alternative, spesso una accanto all’altra, incoraggiando una maggiore flessibilità. A caratterizzarlo è dunque l’enfasi sulla pianificazione e la libertà nell’aggiunta di nuovi attributi o campi, oltre alla possibilità di una sintassi varia tra i database. Va d’altro canto rilevato che i linguaggi NoSQL, mancando dell’interfaccia standard che fornisce SQL, rendendo le query più complesse e difficili da eseguire.

La scalabilità

Per scalabilità di un sistema si intende la possibilità di raggiungere un incremento di prestazioni direttamente proporzionale, grosso modo, all’aumento delle risorse.

La maggior parte dei database SQL ha una scalabilità di tipo verticale, incrementando le capacità di elaborazione dell’hardware, oppure di tipo orizzontale, aggiungendo repliche per i carichi di lavoro di sola lettura. I database NoSQL sono in genere di tipo orizzontale: il sistema riesce cioè a parallelizzare il carico di lavoro. Si caratterizzano inoltre per una maggior fault-tolerance, vale a dire che l’errore in un nodo non pregiudica totalmente il funzionamento dell’applicazione.

La struttura

Gli schemi di un database SQL rappresentano sempre dati relazionali, tabulari, con regole di coerenza e integrità. Contengono tabelle con colonne (attributi) e righe (record), e le chiavi hanno relazioni logiche vincolate. I database NoSQL generalmente rientrano in una delle quattro grandi categorie.

• Orientati alle colonne. I dati sono memorizzati in celle raggruppate in colonne anziché in righe. Le colonne sono logicamente raggruppate in famiglie di colonne. Le famiglie di colonne possono contenere un numero virtualmente illimitato di colonne che possono essere create a runtime o durante la definizione dello schema.
• Chiave-valore. Sono altamente partizionabili e consentono un dimensionamento orizzontale a livelli che altri tipi di database non possono raggiungere. Accedono a diversi oggetti con una chiave unica.
• Documento. Nel codice di applicazione, i dati sono spesso rappresentati come oggetto o un documento di tipo JSON: un modello dati efficiente ed intuitivo per gli sviluppatori. I database di documenti semplificano agli sviluppatori la ricerca e la memorizzazione di dati in un database, usando lo stesso formato di modello di documento che usano nel codice dell’applicazione.
• Grafo. Lo scopo di un database a grafo è facilitare la creazione e l’esecuzione delle applicazioni che operano con set di dati ad elevata connessione. I casi d’uso tipici di un database a grafo includono i social network, i motori di raccomandazione e il rilevamento di frodi.

Le proprietà

Affinché le transazioni operino in modo corretto sui dati è necessario che i meccanismi basati sulla tecnologia SQL presentino quattro proprietà, cosiddette ACID.

• Atomicità. Tutte le transazioni devono avere successo o fallire completamente. Non possono essere parzialmente completate, anche in caso di fallimento del sistema.
• Coerenza: Il database rispetta i vincoli di integrità, sia a inizio che a fine transazione. Non devono verificarsi contraddizioni (incoerenza dei dati) tra i dati archiviati nel DB.
• L’isolamento. Impedisce alle transazioni concorrenti di influenzarsi a vicenda. Le transazioni devono portare allo stesso stato finale come se fossero eseguite in sequenza, anche se sono eseguite in parallelo.
• La durabilità. Una volta che una transazione ha richiesto un commit work, i cambiamenti apportati non dovranno essere più persi. Per evitare che nel lasso di tempo fra il momento in cui la base di dati si impegna a scrivere le modifiche e quello in cui le scrive effettivamente si verifichino perdite di dati dovuti a malfunzionamenti, vengono tenuti dei registri di log dove tutte le operazioni sono annotate sul DB.

I modelli NoSQL aderiscono invece al teorema CAP, in base al quale è impossibile per un sistema informatico distribuito fornire simultaneamente tutte e tre le seguenti garanzie. 

• Coerenza. Tutti i client vedono gli stessi dati contemporaneamente, indipendentemente dal nodo a cui si connettono. Perché questo accada, ogni qualvolta i dati vengono scritti su un nodo devono essere istantaneamente inoltrati o replicati su tutti gli altri nodi nel sistema prima che la scrittura sia considerata riuscita.
• Disponibilità. Qualsiasi client che effettua una richiesta di dati ottiene una risposta, anche se uno o più nodi sono inattivi. In altre parole, tutti i nodi di lavoro nel sistema distribuito restituiscono una risposta valida per qualsiasi richiesta, senza eccezioni.
• Tolleranza di partizione. Una partizione è un’interruzione nelle comunicazioni all’interno di un sistema distribuito, una connessione interrotta o temporaneamente ritardata tra due nodi. La tolleranza alle partizioni significa che il cluster deve continuare a funzionare indipendentemente dal numero di interruzioni nelle comunicazioni tra i nodi nel sistema.

La community

I database SQL rappresentano la stragrande maggioranza delle domande sulle varie community. Essendo più facili da utilizzare, sono infatti preferiti da chi è alla prime armi con la programmazione. Le tecnologie NoSQL presentano invece forum più piccoli e più frammentati. Il che è dovuto anche alla presenza di diverse implementazioni, a seconda del software utilizzato. Richiedono inoltre un tempo maggiore per essere studiati con attenzione.

Database SQL e NoSQL: quando usare l’uno o l’altro

In linea di massima, NoSQL è consigliabile per:

• dati grafici o gerarchici  
• insiemi di dati grandi che mutano significativamente
• aziende che crescono molto velocemente ma che mancano di schemi di dati e che hanno quindi bisogno di un approccio più dinamico
• quando il supporto ACID non è necessario

Questi i casi in cui SQL risulta più appropriato:

• piccoli volumi di dati
• per archiviare e ottenere rapidamente i dati dal database
• in sistemi dove la coerenza è critica
• quando si vogliono eseguire query complesse
  

Fare le giuste scelte tecnologiche è essenziale fin dalle prime fasi del progetto. Noi di Baasbox saremo felici di guidarti in questo percorso, contattaci.

Contattaci

Cosmin Zaharia, Developer di Baasbox e aspirante data scientist, ama passeggiare e prendersi cura del proprio habitat, circondandosi di piante. Alterna il tempo libero tra un buon libro e una partita a scacchi.