Se il NoSQL diventa SQL

Le vere ragioni della tendenza alla crescente “SQLizzazione” dei database NoSQL

Senza dubbio i big data sono una delle tendenze di spicco nel settore IT. Come noto, i big data comportano la memorizzazione, la gestione e l’analisi di enormi quantità di dati. Oggi, le aziende possono scegliere come memorizzare i dati tra le soluzioni basate su SQL o quelle che si basano su NoSQL, come Hadoop, Cassandra o MongoDB. Soprattutto questo secondo gruppo ha riscosso molta attenzione negli ultimi anni. E recentemente sono stati resi disponibili molti prodotti che “avvolgono” un sistema NoSQL in uno strato di SQL: in altre parole, i sistemi NoSQL si stanno trasformando in sistemi SQL. Ma quali sono le ragioni di questa tendenza?

È difficile dare una definizione dei sistemi NoSQL, in quanto sono tutti diversi e hanno in comune solo due cose. In primo luogo, sono stati classificati in un gruppo chiamato NoSQL, e in secondo luogo hanno tutti un’architettura MPP (Massively Parallel Processor) altamente scalabile che permette di distribuire l’elaborazione e lo storage in centinaia di nodi. La loro architettura interna è ideale per scalare in modalità scale-out, cioè in senso orizzontale, mentre i database SQL classici hanno un’architettura progettata per lo scale-up, ovvero in senso verticale. Ma è qui che finisce ogni somiglianza.

Caratteristiche fondamentali

I prodotti NoSQL sono molto diversi dai sistemi SQL, in quanto non organizzano i propri dati in tabelle piatte costituite da colonne, non supportano l’integrità dei dati, non sono limitate a strutture relazionali piatte ma consentono le strutture gerarchiche nei dati, e non supportano un linguaggio di alto livello come SQL, ma solo API e linguaggi di basso livello. Questi diversi concetti di database e di interfacce sono stati implementati per ottime ragioni: infatti, possono essere utilizzati in ambiti big data nei quali le esigenze di storage e di elaborazione sono estremamente elevate.

Tuttavia, quasi tutti gli strumenti più diffusi per il reporting e le analisi esigono che i dati siano organizzati in tabelle SQL, e si aspettano un’interfaccia SQL. Ma soprattutto non funzionano con NoSQL. Inoltre, a causa delle API di basso livello supportate, la produttività è inferiore a quella di SQL e, infine, non tutti gli sviluppatori (in particolare all’interno di reparti BI) hanno esperienza con la programmazione in linguaggi come Java o Python.

Per questi motivi, per utilizzare i noti strumenti di reporting e di analisi unitamente a NoSQL bisogna prima copiare i dati da un sistema NoSQL a uno SQL. Come si può immaginare, questo processo di copia richiede tempo, e conservare per due volte (unicamente per ottenere un’interfaccia SQL) grandi quantità di dati è costoso. È meglio perciò se i dati rimangono all’interno del sistema NoSQL e vi si accede tramite un’interfaccia SQL.

La buona notizia

Sempre più soluzioni si sono rese disponibili per una “SQLizzazione” di NoSQL, con strumenti che consentono alle applicazioni di accedere ai dati memorizzati nei sistemi NoSQL utilizzando SQL. Le soluzioni di SQLizzazione possono essere classificate così:

• Driver dedicato: molte soluzioni offrono un’interfaccia SQL su uno o più sistemi NoSQL. Alcuni consentono inoltre di accedere a fonti dati SQL e possono federare i dati archiviati in più fonti dati. Questi driver trasformano le richieste SQL in arrivo nei linguaggi supportati dal sistema NoSQL, nascondendo la complessità dei linguaggi di basso livello. Tra gli esempi vi sono Apache Hive, Cassandra CQL, Cloudera Impala, DataDirect Cloud, Facebook Presto, Hortonworks Stinger, IBM BigSQL, MapR Drill, Quest Toad for Cloud Databases e Salesforce Phoenix.
• Server di virtualizzazione dati: i server di virtualizzazione dati offrono caratteristiche paragonabili alla traduzione da SQL a NoSQL vista poco fa, ma con tre principali differenze. I server di virtualizzazione dati supportano funzioni più potenti di ottimizzazione delle query quando si accede alle fonti dati, hanno tecnologie di federazione più mature e offrono funzionalità di sicurezza dei dati e ambienti di progettazione. Tra gli esempi, vi sono Cisco/Composite Information Server, Denodo Platform, Informatica IDS, RedHat JBoss Data Virtualization e Stone Bond Enterprise Enabler Virtuoso.
• Database server SQL: alcuni dei database server SQL danno una scelta agli sviluppatori, permettendo di memorizzare le tabelle SQL nel database nativo o in un sistema NoSQL come Hadoop, e il luogo effettivo in cui i dati vengono memorizzati è nascosto alle applicazioni. Gli esempi sono Actian Paraccell, EMC Greenplum UAP, Hadapt, Microsoft Polybase e il database Teradata Aster.

Bisogna però notare che la “SQLizzazione” dei database NoSQL non è così semplice come potrebbe a prima vista sembrare, soprattutto perché le performance rimangono un aspetto molto rilevante. È per questo che tali soluzioni devono affrontare alcune questioni, tra le quali vi sono queste:

• Alcuni dei dati nei sistemi NoSQL sono privi di schema: come può l’interfaccia SQL trasformare questi dati senza schema in dati relazionali con uno schema?
• La maggior parte dei sistemi NoSQL permettono che i record appartenenti alla stessa tabella abbiano diverse serie di colonne, mentre questo concetto non è supportato da SQL.
• Molti sistemi NoSQL supportano costrutti non relazionali come le strutture gerarchiche. Nella terminologia relazionale, questi sarebbero chiamati tabelle nidificate o tabelle NF2 (Non-first normal form). In qualche modo le soluzioni “SQLizzate” devono appiattire queste strutture gerarchiche in strutture relazionali piatte.
• Il join dei dati in SQL è una cosa molto comune da fare. Pertanto, i database server SQL sono sovraccarichi di funzioni per eseguire rapidamente il join. Ma molti sistemi NoSQL non sono rapidi nella funzione join, e preferiscono che i dati siano memorizzati in una qualche maniera de-normalizzata per ridurre al minimo la necessità di effettuare il join. Sarà quindi una vera sfida per le soluzioni di SQLizzazione eseguire rapidamente i join SQL.

Conclusione

La “SQLizzazione” di NoSQL è iniziata e continuerà a evolversi. Quest’anno ci si aspetta che vengano rilasciati nuovi prodotti e vengano rese disponibili versioni rinnovate di quelli esistenti. Si tratta di un fatto positivo in quanto le aziende sono interessate a NoSQL non perché non amano SQL, ma perché hanno bisogno della scalabilità e delle prestazioni di NoSQL. Però vogliono anche la produttività e la facilità di manutenzione di SQL, e la SQLizzazione offrirà il meglio dei due mondi: le prestazioni del NoSQL e la produttività di SQL.

Rick F. van der Lans

Analista indipendente, consulente, autore e docente specializzato in data warehousing, business intelligence e database. Amministratore delegato di R20/Consultancy, van der Lans è un conferenziere di fama internazionale ed è autore di numerosi white paper. Le sue opere più note, tra cui “Introduction to SQL” e “The SQL Guide to Oracle”, sono stati tradotti in numerose lingue e hanno venduto oltre 100mils copie. La sua pubblicazione più recente è “Data Virtualization for Business Intelligence Systems”.

Rick F. van der Lans presenterà a Roma per Technology Transfer i seminari: “La nuova tecnologia database” il 3 giugno 2014 e “Lean Data e Application Integration usando la Data Virtualization” il 4 giugno 2014.