Per la maggior parte di noi pensare a un
database come a una collezione di tabelle fatte di righe e colonne è quasi confortante. Si tratta di una struttura dati semplice da capire e visualizzare, anche se sappiamo bene che in quelle righe e colonne possiamo conservare ormai di tutto e non solo lettere e numeri. Ma dobbiamo
abituarci al cambiamento, perché questa visione sta diventando sempre più parziale.
Il modello classico del
database relazionale è stato messo in crisi tempo fa dal boom del mondo
NoSQL, che come minimo ha provato come si possano usare
approcci diversi per problemi differenti. Ma molte
altre evoluzioni stanno modificando il modo di gestire i dati, aprendo nuove possibilità di sviluppo e cambiando le abitudini di chi gestisce i dati.
Un esempio calzante è la ricerca di soluzioni mirate per la
gestione di dati particolari che difficilmente si possono incasellare in una struttura di righe e colonne. Anni fa sarebbe stato ad esempio naturale fare i salti mortali per adattare a un database relazionale formati di dati come quelli
geospaziali. Oggi elaborare al meglio e soprattutto velocemente queste informazioni è essenziale, per cui sono nate
piattaforme con funzioni native per la gestione e l'elaborazione di coordinate spazio-temporali.
Lo stesso vale per l'
analisi dei grafi, oggi che tutto è una rete e i collegamenti fra i nodi di una rete contano quanto le informazioni sui nodi stessi. Una tabella relazionale non è certo fatta per uno scenario del genere, meglio abbandonarla in favore di soluzioni che nativamente permettano di eseguire
query sulle relazioni tra elementi e non solo sugli elementi stessi. Quello che fanno i
graph database con i loro linguaggi di query specifici.
Tutto questo non vuol dire che il mondo
SQL sia destinato alla pensione. Tutt'altro, perché la piccola crisi legata al successo dei modelli NoSQL è stata in molti sensi metabolizzata come spinta positiva a evolvere. Il fascino di molte soluzioni alternative è stato soprattutto nella possibilità di
fare scale-out distribuendo i dati su cluster di nodi distribuiti, una funzione che nel mondo SQL era patrimonio solo di piattaforme di fascia alta. Ma al prezzo di problemi di
coerenza dei dati e proprio su questo puntano ora alcuni database SQL in cloud come
CockroachDB: unire l'approccio distribuito di NoSQL con l'affidabilità del mondo tradizionale.
E poi c'è l'hardware
Oggi il
GPU computing è la normalità per le applicazioni di calcolo più esigenti e per il machine learning. Da qui ad applicarlo ai database il passo è, se non breve, logico. Servono però
piattaforme specifiche in grado di
adattare il workload dei database alle GPU, che possono anche avere migliaia di core che operano in parallelo rispetto alle poche decine delle CPU ma si tratta anche di core nati per eseguire compiti semplici e ripetitivi.
Infine, molti si aspettano una nuova ridefinizione dei database man mano che le loro informazioni saranno conservate in RAM non volatile come i
sistemi 3DXPoint. L'adozione della
NVRAM cambia alcuni concetti di base nell'ottimizzazione dei database e del codice collegato, in primis il fatto che la memoria RAM e lo storage (una volta i dischi, ora la NVRAM) hanno prestazioni drasticamente diverse. Non è facile dire oggi se abbia ragione chi prevede una
riprogettazione completa dei database sulla spinta delle NVRAM. La discussione è stata avviata ma durerà ancora molto tempo.