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.