Quando scegliere NoSQL

Per apprezzare ancor più il valore dei DBMS NoSQL, vale la pena considerare le loro differenze rispetto al mondo relazionale in generale.

Database relazionali: caratteristiche principali

Parlare di DBMS relazionali significa pensare ad un agglomerato strutturato, in cui i dati sono:

• ripartiti in tabelle, ognuna con una struttura fissa in cui ogni campo è distinto da un tipo di dato preimpostato e rappresentato come una colonna della tabella;
• stratificati in righe (dette record), ognuna delle quali è contraddistinta da una chiave primaria individuata nel valore di un campo specifico o nella congiunzione del valore di più campi. Ogni tabella è costituita da più righe;
• collegati, trasversalmente alle tabelle, grazie alle cosiddette relazioni, che consistono nel posizionare in un record il valore della chiave primaria presente in un record di un'altra tabella;
• esaminati tramite query scritte in SQL in cui il meccanismo principe è il JOIN, che aggrega orizzontalmente più tabelle trattandole all'unisono come se fossero una sola;
• creati, cancellati o modificati tramite ulteriori comandi SQL.

Limiti dei database relazionali

I quarant'anni di dominio del paradigma relazionale non sono stati solo costellati di successi, ma hanno talvolta messo in luce alcuni limiti nel loro utilizzo. Per esempio, è emerso che non sempre i DBMS tradizionali si dimostrano in grado di gestire quantità di dati molto grandi, se non al prezzo di performance molto più limitate e costi piuttosto elevati. Riepiloghiamo i principali punti di debolezza ravvisati nell'uso dei DBMS relazionali:

• i JOIN: nonostante la loro efficacia, queste operazioni coinvolgono spesso più righe del necessario - soprattutto se le query non sono ottimizzate - limitando le performance delle interrogazioni eseguite;
• struttura rigida delle tabelle, utile finchè si ha necessità di introdurre informazioni caratterizzate sempre dalle medesime proprietà, ma molto meno efficiente per informazioni di natura eterogenea;
• conflitto di impedenza, che consiste nella differenza strutturale tra i record delle tabelle e gli oggetti comunemente utilizzati per gestire i dati nei software che interagiscono con le basi di dati. Questo problema ha prodotto - tra l'altro - la nascita di strumenti come gli O/RM, librerie in grado di convertire oggetti in record (e viceversa);
• proprietà ACID: ogni transazione deve essere atomica, consistente, isolata e duratura. Implementare queste proprietà, però, comporta una serie di controlli e precauzioni che penalizzano le prestazioni del sistema. I database non relazionali sono meno stringenti, offrendo una maggiore elasticità.

Quando il NoSQL conviene

A questo punto è lecito chiedersi quando è conveniente utilizzare un approccio NoSQL piuttosto che relazionale. In generale, conviene scegliere l'approccio NoSQL quando:

• la struttura dei dati non è definibile a priori. Pensiamo ad esempio alla variegata gestione dei contenuti che impongono oggi i social network o gli applicativi web per la gestione dei contenuti;
• i dati disposti nei vari oggetti sono molto collegati tra loro e - situazione aggravata da una loro gran quantità - il JOIN rischia di non essere lo strumento ottimale: sarebbe da prediligere la navigazione tra oggetti sfruttando i riferimenti tra i vari nodi di informazione;
• è necessario interagire molto frequentemente con il database, volendo evitare conversioni onerose tra record e oggetti, nè tanto meno ricorrere all'utilizzo di O/RM o altre librerie specifiche;
• necessitiamo di prestazioni più elevate, potendo considerare troppo stringenti le proprietà ACID per il nostro campo di applicatione.

I suddetti motivi non sono gli unici che porterebbero ad optare per NoSQL, ma sono sufficienti per gli scopi di questa guida.

Quando non rinunciare al modello relazionale

In moltissimi casi, il modello relazionale rimane l'opzione migliore. Innanzitutto, esistono DBMS relazioni ormai consolidati da decenni, supportati da una gran varietà di strumenti: pensiamo a Oracle, MySQL o SQL Server di Microsoft. Inoltre, la struttura rigida che richiede non è necessariamente un problema, e talvolta può costituire un vantaggio (soprattutto se si devono modellare dati molto strutturati). In tali contesti, la duttilità del NoSQL non appare un requisito fondamentale. Inoltre non è da dimenticare che le nuove tipologie di approccio ai dati offerte dal NoSQL si stanno facendo largo in prodotti relazionali blasonati, offrendo comode vie di fuga e scenari di integrazione nuovi, senza rinunciare alla persistenza in senso tradizionale: si pensi, ad
esempio, ai nuovi tipi di dato introdotti in PostgreSQL, di cui si è già discusso su questo sito.