“It is perhaps fair to say that from the perspective of many engineers working on the Google infrastructure,
the SQL vs. NoSQL dichotomy may no longer be relevant.”
Source: “Spanner: Becoming a SQL System”
Stiamo assistendo a uno strano fenomeno: dopo un’abbuffata di nuove tecnologie per far fronte a un panorama del tutto nuovo relativo alla gestione dei Big Data, sempre più di frequente incontriamo soluzioni che adottano un approccio relazionale al dato o al più forniscono un’interfaccia SQL per la sua interrogazione.
Si è pertanto riaperto per i Big Data un capitolo tecnologico che pareva chiuso o che almeno in un primo momento non sembrava poi così interessante. Vediamo come.
L’origine del SQL
Gli albori dei database relazionali risalgono agli anni settanta, quando sono state implementate delle basi dati facili da utilizzare per le operazioni di scrittura, lettura e manutenzione, basate su una modellazione dei dati sotto forma di tabelle composte da righe e colonne in relazione tra loro. Il linguaggio per interrogare tali entità era originariamente denominato SEQUEL (Structured English QUEry Language), costituito da un accesso dichiarativo ad alto livello, tradotto dal database in un set di procedure da eseguire sui file fisici.
Il database relazionale si pone come alternativa a quanto utilizzato all’epoca, ossia soluzioni legate a file indicizzati (tipo ISAM/VSAM) per mainframe e trova grande riscontro nel mondo informatico, con un’offerta di prodotti commerciali per aziende, di cui Oracle fornisce un primo esempio.
SQL (Structured Query Language) diventa uno standard nel 1986 con la nascita di SQL ANSI, e ingenti investimenti sui DB relazionali vengono fatti da parte di vendor quali IBM, Microsoft e Oracle, aprendo anche le porte a database open source come MySQL e PostgreSQL e a diverse tecnologie, per esempio applicativi per la Business Intelligence o tools di ETL (Extract, Transform and Load).
I database relazionali nell’era dei Big Data
Con l’avvento dei Big Data i database relazionali perdono un po’ di popolarità poiché spesso inadatti a scenari in cui il dato da gestire non è più rappresentabile con uno schema rigido di righe e colonne, o il volume di dati è così significativo da richiedere una soluzione hardware scalabile col minor impatto economico. La critica più aspra riguarda proprio questo aspetto. In un’ottica tradizionale, le capacità elaborative e di storage del database si possono raggiungere solo aumentando le caratteristiche hardware del server (scale-up), il quale determina un incremento dei costi in funzione del volume dei dati da gestire.
Il movimento NoSQL (Not Only SQL) e sistemi Hadoop-based installati su cluster di macchine a basso costo fanno fronte a queste nuove esigenze e si preoccupano di risolvere il tema della scalabilità oltre che una serie di altre problematiche, di cui le più significative sono:
- gestire dati semi-strutturati/non strutturati o con uno schema flessibile
- supportare dataset molto grandi con elevate performance di risposta alle operazioni in lettura e scrittura
- mettere a disposizione APIs (Application Programming Interface) per l’interazione
- accrescere il numero dei server del cluster per gestire volumi maggiori (scale-out).
Si stava meglio prima?
Grande entusiasmo e fermento si protraggono per qualche anno, ma presto affiorano alcune perplessità. Come garantire la consistenza del dato? Come interfacciarsi ai tool consolidati in azienda e dal business come quelli dedicati alla BI e agli ETL? Come effettuare delle interrogazioni su questi database? Possibile che per un semplice raggruppamento si debba coinvolgere uno sviluppatore esperto dello strumento? E ancora: come garantire un accesso al dato abbastanza flessibile, tale da garantire una piena comprensione dell’ informazione, senza dover modificare il modello dei dati?
Tutte domande a cui alcuni NoSQL hanno cercato di fornire una risposta. Ad esempio Cassandra ha dotato il suo sistema di un linguaggio SQL-like, il quale però non mette al riparo dal funzionamento NO (inteso come negazione!) SQL del DB. Anche sul fronte Hadoop, per lavorare sui dati non strutturati o semi-strutturati, si avvicendano ormai da anni soluzioni denominate “query-engine” o “SQL on Hadoop” che ogni distribuzione o Hadoop vendor integra.
Sempre più spesso si cercano sistemi che non forniscano solo ottime prestazioni nelle interrogazioni finalizzate alla lettura dei dati a fini analitici come avviene nei data warehouse, ma che mettano a disposizione anche dei meccanismi per la gestione delle transazioni. Questi due approcci sono spesso mutuamente esclusivi in molte tecnologie di storage Big Data, che preferibilmente soddisfano le necessità analitiche OLAP (On Line Analytical Processing) e sacrificano la componente OLTP (On Line Transaction Processing). Le operazioni di scrittura come inserimenti, cancellazioni e modifiche, infatti, sono disponibili sui database NoSQL, che però spesso non sono interrogabili tramite SQL.
Stanno quindi nascendo database ibridi cosiddetti HTAP (Hybrid Transactional/Analytic Processing), che si prefiggono di gestire ambo i requisiti, seppur a scapito delle performance. È su questo fronte che SQL e NoSQL finalmente convergono, per gestire dati strutturati e scalare di qualche ordine di grandezza rispetto ad altri ben noti sistemi MPP (Massively Parallel Processing) proprietari. Uno degli ultimi esponenti è appunto Spanner di Google o Kudu di Cloudera.
SQL is back!
Una seconda giovinezza del SQL è senz’altro notizia gradita a tutti quegli avventori dei Big Data che negli anni si sono focalizzati su questo linguaggio e che in un primo momento si sono sentiti precludere la possibilità di interrogare i Big Data contenuti nel Data Lake. Ciò non basta: nuove occasioni nascono in questo periodo anche per interfacciarsi a dati real-time tramite SQL.
Una recente notizia riguarda l’uscita di una soluzione per effettuare “streaming SQL” sui dati presenti nel sistema di Messaging Apache Kafka, parte integrante di molte distribuzioni Hadoop e standard tecnologico. Questo consente di fare analisi real-time mediante continuous query (interrogazioni continue) in linguaggio SQL sui dati che transitano nella coda.
Analogamente si possono trovare tool dedicati alle elaborazioni di dati in streaming che consentono l’utilizzo di questa sintassi per le interrogazioni dei dati in tempo reale, caratterizzati dall’essere parte di un flusso continuo. Un esempio è Amazon Kinesis presente nella piattaforma cloud PaaS di AWS.
In conclusione, sempre più ambiti di applicazione si prospettano per il linguaggio SQL, anche laddove la sua adozione sembrerebbe meno scontata ma fornisce valido supporto all’utilizzo di strumenti Big Data.
Monica Franceschini
