Nonostante il paradigma dei database relazionali abbia quasi cinquanta anni di vita, esso non è affatto obsoleto e continua tutt'oggi ad ispirare il lavoro di molti progettisti. D'altro canto, l'informatica attuale dominata da Social Network, Cloud Computing ed alta connettività - ormai diffusa anche in mobilità - ha evidenziato alcuni limiti di tale modello, soprattutto in termini di elasticità e scalabilità.
Le principali alternative al modello relazionale ricadono nell'ambito del cosiddetto movimento NoSQL. Contrariamente a quanto alcuni sostengono, il termine NoSQL significa "Not only SQL", pertanto i DBMS che aderiscono a questa filosofia non solo non rinnegano SQL ma talvolta ne integrano alcune funzionalità. Tra i vantaggi degli approcci NoSQl, citiamo i seguenti:
- strutturazione dei dati: NoSQL va oltre le rigide strutture dell'approccio relazionale, che impone una forte strutturazione dei dati. Questi nuovi approcci, infatti, conferiscono una maggiore centralità alle informazioni e alla loro varietà, supportando l'uso di dati non omogenei pur mantenendo le possibilità di interrogazione, analisi ed elaborazione efficiente;
- scalabilità: a differenza dei database relazionali, quelli di tipo NoSQL sono generalmente basati su strutture fisiche che si prestano meglio alla distribuzione dei dati su più nodi di una rete (sharding), permettendone pertanto un'espandibilità maggiore;
- prestazioni: la maggiore distribuibilità dei dati sulle reti è un elemento che permette, tra l'altro, migliori performance.
Infatti la replica dei dati su più macchine le mette queste in condizione di rispondere più rapidamente alle richieste degli utenti. Non è un caso, quindi, che la crescita del movimento NoSQL sia coincisa con la diffusione dei Social Network, caratterizzati da grandi moli di dati ma anche da un enorme numero di accessi simultanei; - flessibilità nella progettazione: si è detto che la struttura flessibile usata nei database NoSQL non obbliga necessariamente ad una stereotipazione dei dati durante la progettazione, ma lascia liberi i programmatori di risolvere eventuali casi particolari direttamente in fase di sviluppo dell'applicazione.
Tutti i tipi di NoSQL
Le attuali soluzioni NoSQL possono essere usate per molteplici scopi, e possono essere classificate in alcune categorie comuni:
- database a "documenti": una delle tipologie più diffuse. Raccoglie i dati in collezioni di oggetti, ognuno dei quali costituito da più campi. Tali oggetti non richiedono una struttura fissa e questo permette di renderli differenti l'uno dall'altro nell'ambito della stessa collezione. MongoDB rappresenta il principale prodotto di questa serie e, secondo le stime, è uno dei database NoSQL più diffusi al mondo;
- database a grafo: riproducono una delle strutture dati più duttili dell'informatica, soprattutto per alcune tipologie di problematiche. I due elementi principali della stuttura sono i vertici e gli archi: i primi contengono le informazioni, i secondi stabiliscono relazioni;
- key/value (o chiave/valore): ispirati dalle strutture dati conosciate come mappe o dizionari, immagazzinano oggetti associando loro una chiave univoca che ne permetterà un agevole recupero. Redis è probabilmente uno dei prodotti di questo tipo più conosciuti;
- Column-oriented: sono database che immagazzinano dati in sezioni di colonne. La rapida aggregazione che permettono è stata apprezzata dai grandi produttori di motori di ricerca e Social Network, tanto che i alcune delle principali soluzioni di questo tipo (Cassandra, Big Table, SimpleDB) sono state realizzate rispettivamente da colossi come Facebook, Google ed Amazon.
OrientDB: cos'è e dove si colloca
Come si evince dal titolo di questa lezione introduttiva, nella guida che segue ci occuperemo di OrientDB, una soluzione prodotta e sviluppata da Orient Technologies. OrientDB viene definito come un database multi-model, cioè un modello "ibrido" che include diverse funzionalità delle tipologie di database NoSQL precedentemente elencate.
Alla base dei suoi vari modelli, si colloca l'Object Model, ispirato dalla programmazione ad oggetti, che permette di definire classi di dati supportando anche ereditarietà e polimorfismo.
Il Document Model costituisce invece l'anima a documenti di OrientDB. Ci permetterà di raccogliere i documenti in strutture molto flessibili (le collezioni), e tali oggetti saranno legati tra loro da link. Il Document Model è un parte fondamente delle API di OrientDB, e l'affronteremo all'inizio della guida.
Il Graph Model rappresenta una delle finalità principali di OrientDB: raccogliere documenti in nodi collegati tra loro da relazioni. La rete di interconnessioni che si verrà così a creare permetterà di estrapolare ulteriori informazioni utili.
Infine il Key/Value Model è forse quello che consente di utilizzare OrientDB in modo concettualmente più semplice concettualmente: gli oggetti saranno immagazzinati in strutture indicizzate tramite chiavi.
A differenza di quanto avviene in altri gestori di database, OrientDB è realmente Multi-Model, nel senso che i vari approcci appena descritti non sono solo delle interfacce offerte dal sistema, ma quattro veri modelli di gestione dei dati di cui il motore del DBMS è stato dotato.
La varietà di usi cui si presta OrientDB è proprio uno dei fattori che ne ha determinato la rapida diffusione. Tra i vari paradigmi NoSQL non ne esiste uno migliore degli altri, ma alcuni di essi possono essere particolarmente adatti ad alcuni tipi di progetti. A seconda delle circostanze quindi si possono sfruttare i vantaggi di un approccio piuttosto che degli altri.
Nella guida, vedremo inizialmente come realizzare database a documenti con OrientDB, continuando poi con la sua natura di DBMS a grafo, evidenziando in questo caso particolari tipologie di soluzioni in cui esso può essere impiegato.
