NoSQL con PostgreSQL

Il mondo attuale, affollato di web application e social network, produce quantità sconfinate di dati ad una velocità fino a poco tempo fa inimmaginabile. La priorità delle tecnologie odierne si è quindi spostata verso lo sviluppo di strumenti per immagazzinare ed analizzare queste informazioni più velocemente possibile. Una delle questioni da affrontare per risolvere questo problema è l'estrema eterogeneità dei dati, che fatica ad essere imprigionata nelle rigide strutture su cui si basano i database relazionali: testi, immagini, video, audio ed ogni altro contenuto che le moderne interfacce web e mobile riescono ad inviare ai server.

Il movimento NoSQL prende piede nel 2009 per proporre alternative in grado di superare i limiti dei DBMS, relazionali proponendo forme di archiviazione più flessibili e scalabili.

Il mondo del data storage appare da allora diviso in due grandi emisferi: da un lato l'archiviazione relazionale con prodotti open source e proprietari (MySQL, Oracle, SQL Server, eccetera…), dall'altro quello NoSQL con basi di dati non strutturate e totalmente rivolte ai contenuti (MongoDB, OrientDB, eccetera).

Nonostante ciò, esistono situazioni in cui entrambi gli approcci possono confluire ed integrarsi, come le soluzioni offerte da PostgreSQL, un gestore di database molto interessante.

Questo articolo spiega come questo DBMS riesca a gestire dati in stile NoSQL e relazionali, e sia in grado di farlo anche in contemporanea. Vedremo i tipi di dato più interessanti, ed alcuni esempi di utilizzo.

Evoluzione di PostgreSQL: dalle origini al NoSQL

PostgreSQL è un progetto open source con una lunga storia alle spalle. Fondato all'università di Berkley (California), con il nome di Ingres, alla fine degli anni ‘70, venne interrotto varie volte per poi resuscitare sempre in nuovi progetti. Ottenne dapprima il nome di Postgres (abbreviazione di “post-Ingres”) e, solo a metà anni ‘90, quello di PostgreSQL, quando venne dotato di un motore per l'esecuzione di comandi SQL.

È attualmente considerato un ORDBMS (Object Relational DBMS) in quanto racchiude ancora in sé sia la tradizione delle basi di dati relazionali, sia quella della programmazione orientata agli oggetti. È soprattutto quest'ultima, con il suo principio di ereditarietà, a conferire a PostgreSQL una grande flessibilità nella definizione dei dati.

Due tipi di dato in particolare, oggi in dotazione a PostgreSQL, permettono di gestire informazioni NoSQL: JSON e HSTORE.

Il primo dei due si avvicina molto alla filosofia dei DBMS NoSQL basati sui documenti, il cui esponente più famoso è MongoDB. Il secondo richiama i database di tipo chiave/valore, che archiviano dati etichettandoli con degli
identificativi univoci.

Preparazione dell'ambiente di lavoro

L'ambiente di lavoro che utilizzeremo nel seguito di questo articolo non richiede altro che un’installazione base di PostgreSQL. Si tratta di un prodottomultipiattaforma, disponibile pertanto per qualunque sistema operativo. Il download di sorgenti ed eseguibili può essere effettuato dal sito ufficiale.

Nel prosieguo dell'articolo, faremo riferimento ad un'installazione di PostgreSQL su sistema Ubuntu Server versione 14.04. Tale impianto si può ottenere
comodamente con i pacchetti precompilati mediante il seguente comando:

apt-get install postgresql postgresql-contrib

Conclusa l'installazione, su Ubuntu sarà configurato un utente, denominato postgres, che, senza entrare nel merito della gestione di permessi e ruoli del DBMS, utilizzeremo per la gestione di un database.

Per prima cosa, quindi, dopo avere avuto accesso al sistema Linux con le proprie credenziali, ci “immedesimeremo” nell'utente postgres:

sudo su - postgres

Potremo creare così un database per la sperimentazione usando il comando createdb, reso disponibile contestualmente all'installazione di PostgreSQL.

Creiamone quindi uno, che chiameremo example, utilizzando la seguente istruzione:

createdb example

Quindi accediamo al database appena creato con:

psql -d example

Il comando psql è il client da terminale che dà accesso ad una console testuale di PostgreSQL in cui si possono usare liberamente direttive SQL o alcuni comandi. I seguenti saranno particolarmente utili:

Comando	Descrizione
list	elenca i database disponibili per il profilo utente
dt	elenca tabelle all'interno del singolo database
z	elenca tutti gli elementi interni al database, tra cui tabelle e viste
h	mostra l'aiuto in linea
conninfo	fornisce informazioni sulla connessione in corso al database
q	chiude psql

Il formato JSON in PostgreSQL

Come già accennato, un primo tipo di dati NoSQL viene definito in PostgreSQL mediante JSON. Per chi non lo conoscesse, si tratta di un
formato testuale derivato dal linguaggio JavaScript, largamente utilizzato al giorno d'oggi soprattutto nell'interazione tra applicazioni attraverso la
rete. Ne fanno uso anche i database NoSQL a documenti, come MongoDB, per la descrizione dei dati.

Riassumendone le caratteristiche, un oggetto JSON è composto da un elenco di proprietà, ognuna specificata da un nome e dal valore assegnatole. Tali
proprietà sono separate da virgole e l'elenco nel suo complesso è racchiuso tra parentesi graffe.

Ad esempio, un oggetto caratterizzato dalle proprietà nome, cognome, eta, rispettivamente valorizzate dai dati “Carlo”, “Rossi”
e ”25”, potrebbe essere espresso in JSON così:

{ "nome": "Carlo", "cognome": "Rossi", "eta": "25" }

All'interno del database example, creiamo una tabella di nome multimedia destinata a contenere informazioni su documenti di vario genere (cd musicali,
ebook, immagini, eccetera...). Dato che ogni tipo di documento ha le sue peculiarità, la definizione di una struttura rigida, basata sul modello relazionale, potrebbe rivelarsi poco adatta. Utilizziamo pertanto il formato JSON che, per ogni documento, permetterà di utilizzare una stuttura specifica dei
dati. Ogni documento sarà descritto da un oggetto JSON.

Una volta fatto accesso al database, creiamo la tabella multimedia con un unico campo denominato data e tipizzato come JSON:

CREATE TABLE multimedia (data JSON);

A questo punto inseriamo tre righe, corrispondenti a tre documenti di tipologia diversa:

INSERT INTO multimedia (data) VALUES ('{"id":"1", "title":"Promessi sposi", "type":"ebook", "pages":"400"}');
INSERT INTO multimedia (data) VALUES ('{"id":"2", "title":"Canzoni di Natale", "type":"CD", "tracks":"12"}');
INSERT INTO multimedia (data) VALUES ('{"id":"3", "title":"panorama.jpg", "type":"photo", "pixels":"1665x894"}');

Gli oggetti JSON appena definiti hanno in comune tre proprietà – id, title e type - ma le altre sono specifiche del tipo di documento archiviato.

Sin qui, non sembra niente di eccessivamente innovativo. In fin dei conti, il campo JSON è stato utilizzato in maniera simile ad una stringa.

Il vero vantaggio consiste nella possibilità che offre PostgreSQL di analizzare i dati all'interno del JSON mediante una normale query.
Consideriamo, per esempio, la seguente interrogazione:

SELECT data->>'title' FROM multimedia;

Il risultato che produrrà sarà il seguente:

[code]
Promessi sposi
Canzoni di Natale
panorama.jpg
[/code]

L'operatore ->> è servito per richiedere a PostgreSQL di analizzare il formato JSON, ed estrapolare i dati del campo title. È un po' come se la vera
tabella fosse ora contenuta nei dati NoSQL, ma rimanesse analizzabile tramite normali dichiarazioni SQL.

HSTORE, il formato chiave-valore

Il formato HSTORE ricorda una tipologia di dato comunemente nota in informatica come dizionario. Ogni informazione viene indicata come una coppia
chiave-valore, ove la chiave è univoca e serve ad indicare il valore corrispondente.

Per usare HSTORE in PostgreSQL, dovremo prima abilitare l'opportuna estensione con la seguente query:

CREATE EXTENSION hstore;

A questo punto, proseguendo l'esempio del paragrafo precedente, creiamo un'ulteriore tabella, che servirà ad abbinare una descrizione ad ogni tipo di dato usato nell'esempio precedente:

CREATE TABLE data_type (type HSTORE);

Inseriamo al suo interno alcune coppie chiave/valore, come mostrato di seguito:

INSERT INTO data_type VALUES ('"ebook"=>"libro elettronico", "Photo"=>"Immagini in formato digitale", "CD"=>"Compact Disc musicale"');

Anche in questo caso, PostgreSQL permette di interrogare i dati all'interno del tipo NoSQL. Si consideri la query seguente:

SELECT type->'ebook' FROM data_type;

Il valore di output che sarà restituito è:

[code]> libro elettronico[/code]

Integrazione tra dati NoSQL ed ANSI SQL

I tipi JSON e HSTORE mostrano aspetti interessanti almeno per il fatto di poter essere espressi con strutture meno rigide, ed interrogati con le classiche
query SQL.

Un aspetto molto interessante è quello di poter utilizzare, in aggiunta a dati tipicamente NoSQL, le più comuni tabelle relazionali, e poter eseguire query "promiscue" all'interno del database.

Dal momento che la tabella multimedia, popolata con dati JSON, contiene riferimenti a risorse multimediali molto varie, immaginiamo che un'altra tabella
custodisca un'infomazione temporale (timestamp), che descrive l'ultimo accesso ad una risorsa.

Questa tabella necessita di due campi, ovvero l'id della risorsa in formato testuale, ed il timestamp vero e proprio. In questo caso, possiamo
fare a meno della flessibilità del NoSQL; pertanto la creiamo secondo i normali standard di SQL:

CREATE TABLE log (id TEXT, logtime TIMESTAMP DEFAULT CURRENT_TIMESTAMP);

Per default, il timestamp verrà impostato all'ora attuale. Il seguente comando inserirà una riga riferita alla risorsa con id pari a 1:

INSERT INTO log (id) VALUES ('1');

L'id definito coincide con quello riportato nella tabella multimedia, quindi possiamo incrociare i dati con un normale join SQL:

SELECT multimedia.data->>'title' AS title, logtime
FROM multimedia, log
WHERE multimedia.data->>'id'=log.id;

L'output prodotto mostrerà due campi, il nome della risorsa (presente nei dati NoSQL della tabella multimedia) e il timestamp (presente nella tabella log):

[code]
title | logtime

------------------------------------------------

Promessi sposi | 2014-11-25 17:48:18.535045
[/code]

Altre tipologie di integrazioni interessanti, questa volta tra dati NoSQL, sono offerte da funzioni già incluse in PostgreSQL che permettono conversioni e
trasformazioni di dati JSON e HSTORE. Un elenco completo con relativi esempi si può reperire facendo riferimento alla documentazione ufficiale.

Le prestazioni

Le capacità NoSQL viste sinora dischiudono prospettive nuove ed interessanti. Il dubbio che può legittimamente sorgere a questo punto riguarda le
prestazioni.

Un recente esperimento svolto da EnterpriseDB Corporation ha confrontato prestazioni e consumo di spazio tra PostgreSQL 9.4 e MongoDB 2.6
nell'immagazzinamento di grandi moli di dati di tipo NoSQL.

Il risultato, sorprendente, è stato nettamente a favore di PostgreSQL. Questo DBMS ha dimostrato infatti una netta superiorità rispetto a MongoDB: 2,1
volte più veloce nell'inserimento di grandi moli di dati, oltre che 2,5 volte più performante nelle operazioni di selezione; il tutto risparmiando il 33% di
spazio.

La tabella seguente mette a confronto i numeri dell'esperimento: