Database NoSQL: OrientDB - ingegneria- · PDF fileScuola Politecnica e delle Scienze di Base...

Scuola Politecnica e delle Scienze di BaseCorso di Laurea in Ingegneria Informatica

Elaborato finale in Basi di Dati

Database NoSQL: OrientDB

Anno Accademico 2015/2016

Candidato:

Stefano De Vincenzo

matr. N46001320

Ai miei genitori,cui devo ogni cosa.

Indice

Introduzione 1

1 Dai database Relazionali ai database NoSQL 21.1 Cos’e un database relazionale . . . . . . . . . . . . . . . . . . . . 21.2 Il modello ER . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31.3 SQL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41.4 Cos’e un database NoSQL . . . . . . . . . . . . . . . . . . . . . . 51.5 Perche sono nati i database NoSQL . . . . . . . . . . . . . . . . . 51.6 I vantaggi dei database NoSQL . . . . . . . . . . . . . . . . . . . 71.7 NoSQL: a cosa si rinuncia . . . . . . . . . . . . . . . . . . . . . . 8

1.7.1 Teorema CAP . . . . . . . . . . . . . . . . . . . . . . . . 81.8 Come cambiano le regole: da ACID a BASE . . . . . . . . . . . . 91.9 Big Data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 111.10 Tipologie di database NoSQL . . . . . . . . . . . . . . . . . . . . 111.11 Dove non si usa un database NoSQL . . . . . . . . . . . . . . . . 15

2 OrientDB 172.1 Struttura OrientDB . . . . . . . . . . . . . . . . . . . . . . . . . 18

2.1.1 Classi astratte . . . . . . . . . . . . . . . . . . . . . . . . 192.1.2 Sicurezza . . . . . . . . . . . . . . . . . . . . . . . . . . . 192.1.3 Regole . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 192.1.4 Ruoli . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 202.1.5 Utenti . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 202.1.6 Sicurezza a livello di record . . . . . . . . . . . . . . . . . 21

2.2 Esempio applicativo . . . . . . . . . . . . . . . . . . . . . . . . . 212.2.1 Primo approccio ad OrientDB . . . . . . . . . . . . . . . . 212.2.2 Creazione della base di dati . . . . . . . . . . . . . . . . . 242.2.3 Prima potenzialita: classi schema-less . . . . . . . . . . . 262.2.4 Seconda potenzialita: noncuranza dei valori . . . . . . . . 292.2.5 Terza potenzialita: campo embedded . . . . . . . . . . . . 302.2.6 Quarta potenzialita: campi containers . . . . . . . . . . . 302.2.7 Analogia a schemi relazionali: vincoli . . . . . . . . . . . . 312.2.8 Analogia a schemi relazionali: relazioni-JOIN . . . . . . . 33

2.3 OrientDB: graph-database . . . . . . . . . . . . . . . . . . . . . . 36

Conclusioni 40

Bibliografia 41

Introduzione

L’obiettivo di questa tesi e quello di fornire nella maniera piu chiara e sem-plice possibile una descrizione completa di una nuova tecnologia ancora in fasedi sviluppo, quella dei database NoSQL. Evidenzieremo i motivi per i quali taletecnologia risulta necessaria al giorno d’oggi in alcuni contesti, le migliorie cheapporta ad alcune dinamiche e, contemporaneamente, i difetti che presenta.

Con la semplificazione dell’accesso alla rete, con la possibilita per chiunque dipossedere un terminale che possa collegarsi ad Internet e quindi con l’aumentodi utenza, applicazioni, con la semplicita offerta dalla rete nel gestire/forniremolteplici servizi e con la nascita del Cloud-Computing, e diventato necessarioper ogni tipo di fornitore di servizi, dal piccolo imprenditore alle grandi aziende,avere la possibilita di memorizzare e manipolare in maniera semplice ed efficacequalsiasi tipo di informazione: strutturata e non strutturata che sia.

• I dati strutturati sono quelli che possono essere memorizzati nei databaserelazionali; possono cioe risiedere all’interno di tabelle e schemi attraversorelazioni e vincoli.

• I dati non strutturati non hanno la possibilita di essere conservati all’inter-no di tabelle fisse ma hanno bisogno di essere gestiti attraverso tecniche adhoc; tali tecniche fanno parte di quella branca dell’informatica denominataInformation-Retrieval.

Nelle applicazioni software moderne c’e sempre piu spesso la necessita di maneg-giare una gran quantita di dati che risultano essere non strutturati. In questoscenario, i database relazionali, nati per gestire solo dati schematizzabili, nonrisulterebbero la scelta progettuale piu corretta. E’ questo uno dei principalimotivi che ha contribuito allo sviluppo dei database NoSQL.

I database NoSQL sono un prodotto ancora sostanzialmente giovane, realizzatiper soddisfare le moderne necessita per quanto riguarda la gestione di grandiquantita di dati, spesso senza uno schema fisso o con uno schema che puo va-riare molto quando il software e in fase di sviluppo. Per di piu tutti questi datipossono essere relazionati tra loro in molteplici modi. Un esempio pratico elampante lo si trova oggigiorno nei social networks.

Prima di entrare nel merito dei database NoSQL, daremo un accenno a quelloche e il mondo dei database relazionali. Successivamente differenzieremo i duemacro approcci evidenziando caratteristiche e vantaggi di ognuno di essi.

Infine ci concentreremo su OrientDB, un database non relazionale, attraver-so cui presenteremo un piccolo esempio pratico che ci permettera di evidenziarequanto sia semplice, intuitivo e soddisfacente lavorare con un database di questotipo.

Capitolo 1

Dai database Relazionali aidatabase NoSQL

Per comprendere al meglio le dinamiche che hanno forzato la realizzazione deidatabase NoSQL, risulta necessario mostrare le caratteristiche del modello che,fino a pochi anni fa, dominava sul mercato: il modello relazionale. L’intento diquesto capitolo e, appunto, fornire una breve ma calzante descrizione degli aspet-ti fondamentali di tali database, sottolineando quelle che sono le caratteristicheoggigiorno piu proibitive per il loro utilizzo.

1.1 Cos’e un database relazionale

Il cuore di un database relazionale e il DBMS (Data Base Management System/-Sistema di gestione di una base di dati). Concettualmente e possibile inquadrareil DBMS assimilandolo ad un sistema operativo, ovvero quel software che, inter-facciandosi con l’utente, semplifica la comunicazione con l’hardware sottostante;allo stesso modo lavora un DBMS per una base di dati.

L’unione tra il database ed il DBMS da vita al cosiddetto RDBMS.

I compiti fondamentali di un DBMS sono molteplici e si raggruppano nelle parolechiave DDL e DML:

• DDL sta per Data Definition Language ed indica il linguaggio con il qualesi definisce come i dati sono organizzati in informazioni. Alcuni esem-pi sono: CREATE TABLE, ALTER TABLE, DROP TABLE, CREATE SCHEMA,

CREATE TABLE ecc.

• DML e l’acronimo di Data Manipulation Language e si riferisce al linguag-gio con il quale il DBMS si interfaccia con i dati all’interno del database.Attraverso il DML e possibile operare sulla base dati sia per interrogarlache, eventualmente, modificarla. Alcune istruzioni sono: INSERT INTO,

SELECT, SET, UPDATE ecc. Le istruzioni che permettono tali comunica-zioni sono le cosiddette query.

2

CAPITOLO 1. DAI DATABASE RELAZIONALI AI DATABASE NOSQL 3

Le query sono il linguaggio attraverso il quale si interagisce con una base didati; l’interazione prevede le operazioni di inserimento, modifica, cancellazionee visualizzazione.

Tutte le operazioni svolte su una base di dati relazionale prendono il nome ditransazioni. Il concetto cardine del modello relazionale sta nel soddisfacimentodi quattro proprieta, le ACID, da parte di ogni singola transazione. Tali pro-prieta sono:

Atomicita: ogni transazione e indivisibile; essa deve essere eseguita (com-mit) o annullata completamente (abort).

Consistenza: in ogni momento il database deve trovarsi in uno stato con-sistente; devono quindi essere rispettati tutti i vincoli di integrita dei dati

come quello di chiave primaria, vincoli di tupla, vincoli di integrita referenziale.

Isolamento: ciascuna transazione deve essere eseguita come se fosse l’unicapresente nel database; deve quindi risultare indipendente da tutte le altre.

Una transazione che fallisce non deve interferire con le altre transazioni presenti.

Durabilita/Persistenza: indica la capacita di non perdere i cambiamentidovuti ad una qualsiasi query. I risultati di una transazione sono quindi

permanenti, anche in presenza di failures.

1.2 Il modello ER

Il binomio costituito dalla base di dati e dalle applicazioni che operano su essaprende il nome di applicazione di base di dati.

La progettazione di una applicazione di base di dati prevede:

1. La progettazione della base di dati vera e propria;

2. Lo sviluppo delle applicazioni che dovranno interagire.

La prima parte della progettazione della base di dati viene chiamata progettazio-ne concettuale dato che viene fatta ad un alto livello di astrazione attraverso cuisi modella progettando il database in maniera indipendente dal modello logicodei dati. In tale fase si traducono le informazioni risultanti dall’analisi di undeterminato dominio in uno schema concettuale. La seconda fase e chiamataprogettazione logica la quale traduce il modello concettuale in un particolaremodello logico dei dati. Infine si passa alla progettazione fisica.

Uno dei concetti chiave su cui si fondano i database relazionali e quello di un par-ticolare modello di progettazione concettuale chiamato ER (Entity-Relationship),formalizzato dal prof. Peter Chen nel 1976. I concetti cardine di tale modello


sono quello di Entita, Attributi e Relazioni.

Le entita rappresentano classi di oggetti che posseggono delle proprieta comunied hanno esistenza autonoma all’interno dell’applicazione di interesse. Si parlaquindi di occorrenza di entita per riferirsi ad un concetto che esprime un oggettoesistente nel mondo reale. Un’occorrenza di entita ha un’esistenza indipendentedalle proprieta ad essa associate.

Gli attributi sono appunto le proprieta che descrivono un’entita. Essi posso-no essere semplici o composti.

Un’associazione rappresenta il legame esistente tra due o piu entita. Proprioperche ad una associazione possono partecipare piu entita, si parla di grado diuna associazione. Anche le associazioni possono avere attributi oltre che cardi-nalita.

Attraverso il concetto di attributo, possiamo mettere in evidenza un altro aspet-to significativo dei database relazionali: lo schema. Uno schema di relazione eun nome, seguito dall’insieme degli attributi ad esso associato. Ad esempio:LIBRO(TITOLO, AUTORE, EDITORE). Uno schema ci permette di fornire una de-scrizione pratica di un’entita.

L’attributo di consistenza esposto precedentemente nelle proprieta ACID si ri-flette proprio sugli schemi; ogni istanza degli stessi infatti deve rispettare unvincolo di integrita (IC/Integrity Constraint) attraverso cui i dati dello schemasiano corrispondenti al modello descritto.

Riassumendo: nei database relazionali i dati reali assumono valore di entita;piu entita possono avere relazioni ed ogni entita possiede degli attributi. Leentita si traducono in maniera pratica in tabelle e le tabelle memorizzano datiben definiti in termini di tipo, dimensione ed altri vincoli.

1.3 SQL

SQL e l’acronimo di Structured Query Language. Esso e il linguaggio utilizzatodai DBMS relazionali attraverso cui e possibile comunicare con qualsiasi data-base.

SQL nasce (con l’acronimo SEQUEL) grazie ad IBM ed in particolare con Do-nald Chamerlin e Raymond Boyce nel 1974. Nel 1986 e stato adottato comestandard dall’ANSI e nel 1987 da ISO. La prima versione prende il nome diSQL/86 poi evolutasi in SQL-92 ed infine in SQL-2003.

La differenza fondamentale con gli altri linguaggi (procedurali) risiede nel fattoche SQL risulta essere dichiarativo: l’utente decide cosa fare e non specificaanche il come, ovvero l’ordine di esecuzione.


Esempio Query (1):

INSERT INTO utenti VALUES (‘123’,‘Stefano’,‘De Vincenzo’,

to date(‘01-11-1992’,‘dd-mm-yyyy’),‘Italia’,‘Napoli’,80126);

Esempio Query (2):

DELETE FROM utenti WHERE nome LIKE ‘S%’;

La prima query si occupa dell’inserimento di alcuni valori all’interno di unatabella chiamata utenti. La seconda query elimina dalla suddetta tabella tuttele righe il cui campo nome inizia con la lettera S.

1.4 Cos’e un database NoSQL

Il termine NoSQL compare per la prima volta nel 1998 per merito del professorCarlo Strozzi, grazie alla presentazione del suo database Strozzi NoSQL rela-tional database: un database molto leggero di tipo relazionale che pero non sifondava sul linguaggio SQL.

Oggi il termine NoSQL e utilizzato per riferirsi ad ogni datastore che non segue ilmodello RDBMS cioe dove il dato immagazzinato non e relazionale e non vieneutilizzato SQL come linguaggio per le query. Molti di essi in realta supportanoanche SQL, pur prediligendo altri linguaggi; per questo motivo il significato piucorretto dovrebbe essere Not Only SQL. Inoltre ci si riferisce ai database chenon seguono i principi RDBMS soprattutto per quanto riguarda le proprietaACID; i database non relazionali infatti sono progettati specificatamente perfornire velocita e scalabilita, attributi non certamente garantiti dalle ACID.

Alcuni dei primi prodotti NoSQL nascono per merito dell’Apache SoftwareFoundation (logo in fig.1.1), una comunita no-profit dedita allo sviluppo dimoltissimi progetti software; ne citiamo alcuni:

• Hadoop: e un framework scritto in Java che permette un elevato accessoai dati; lavora su applicazioni distribuite.

• Lucene: programmato anch’esso in Java; e un’ API utilizzata per il retrie-val di informazioni; Wikipedia ne fa uso.

• Cassandra: DBMS NoSQL; utilizzato da Digg e Twitter.

• ZooKeeper: applicazione progettata per fornire servizi di configurazione esincronizzazione ai sistemi distribuiti; si tratta di un insieme di processiinterconnessi tra loro la cui comunicazione avviene sotto forma di scambiodi messaggi.

1.5 Perche sono nati i database NoSQL

Il modello relazionale e tuttora largamente il piu utilizzato. Tuttavia a causa delproliferare, ormai da anni, di software che lavorano su quantita enormi di dati


Figura 1.1: Logo dell’Apache Software Foundation

provenienti da domini dinamici, quest’ultimo inizia a mostrare tutti i suoi limiti.Un esempio lampante e quello dei social network che si basano sull’utilizzo dimolteplici varieta di dati i quali, chiaramente, necessitano di una particolare ge-stione che si differenzia notevolmente da quella di un classico database RDBMS.Si parla infatti di dati non piu “normalizzabili” cioe dati che difficilmente sonocoerenti all’interno di una/uno entita/schema RDBMS.

Un altro aspetto critico e quello dell’elevata mole di dati. Sappiamo che unadelle operazioni fondamentali dei database relazionali e quella di JOIN che ser-ve a combinare (unire) le tuple di due o piu relazioni di un database tramitel’operazione di congiunzione. E’ evidente che con l’aumentare della dimensionedel dataset, l’operazione di JOIN cresce linearmente/esponenzialmente, fino adiventare ingestibile.

E’ a questo punto che nasce l’esigenza di poter lavorare con un database di-verso, che riesca ad integrare tutti i dati eterogenei che gli vengono forniti e chesia capace di mantenere alte le prestazioni anche con l’aumentare del datasetalla base. Un database che quindi si sappia evolvere, non piu statico e legato aschemi predefiniti. Che supporti anche l’assenza di vincoli e integrita referen-ziale. Tutto questo, magari, supportando il modello ACID.

Abbiamo appena visto un quadro generale del perche il movimento NoSQLsi sia sviluppato cosı rapidamente. Vogliamo adesso raggruppare in manierasemplice e schematica i fattori negativi legati ai database relazionali e vedere,nel prossimo paragrafo, come il modello NoSQL preveda di risolvere tali pecche.Abbiamo sintetizzato le principali problematiche del modello relazionale in talicaratteristiche evidenziate di seguito:

↓ Inflessibilita sugli schemi: i modelli RDBMS sono piuttosto inflessibili nel lorodesign. Molto spesso aggiungere una colonna e un’ operazione estremamentecomplicata. E’ possibile creare nuove tabelle ed accrescere la complessita intro-ducendo relazioni tra le tabelle stesse.

↓ Query complesse: molto spesso l’interazione con una base di dati relazionale


avviene mediante query complesse, chiamate JOIN-queries, difficili da implemen-tare e che comportano un elevato consumo di risorse per essere eseguite.

↓ Aggiornamento dei dati: aggiornare i dati nelle tabelle e probabilmente unodegli scenari piu critici, specialmente se cio deve essere fatto in una transazione;inoltre mantenere a lungo una transazione fa calare le performance. Esiste poiil rischio di opf (one point failure) nel caso in cui si vogliano propagare gli ag-giornamenti a nodi vicini e il sistema non supporti molteplici scritture da partedi un master o la scrittura simultanea su piu nodi.

↓ Scaling (scalabilita) orizzontale: precisiamo che quando si parla di scalabilitasi intende la capacita di un sistema informatico di lavorare, conseguentementeal fatto che il carico di lavoro diminuisca/aumenti. Lo scaling verticale prevedel’aumento delle prestazioni del sistema andando ad operare sulle risorse hard-ware gia presenti mentre lo scaling orizzontale si basa sull’aumento di postazionihardware. Lo scaling orizzontale, appunto, comporta tutta una serie di proble-mi che riguardano la gestione di grandi moli di dati come la consistenza, lacomunicazione e la sincronizzazione. I database relazionali hanno sempre fattoaffidamento allo scaling verticale che ha portato ad avere postazioni sempre piupotenti; e evidente pero che con l’aumento di utenza si e reso necessario scalareanche orizzontalmente per fornire prestazioni piu elevate in termini di accesso emaggiore sicurezza sui dati. Lo scaling orizzontale pero entra in conflitto con lerestrizioni del modello ACID, legato indissolubilmente alla consistenza dei dati.

↓ Natura sempre piu dinamica dei domini: come abbiamo gia avuto modo diaccennare, i database relazionali si basano sul modello ER che gestisce i suoidati tramite il concetto di entita, difficilmente associabile a tutti i tipi di datigestiti da un database NoSQL.

↓ Gestione di grandi moli di dati: le basi di dati relazionali, in genere, nonsono in grado di gestire (o meglio di gestire in maniera ottimale) elevate quan-tita di dati; questo perche si tiene conto del modello ACID che predilige (comevedremo a breve) consistenza dei dati rispetto alla disponibilita immediata deglistessi.

1.6 I vantaggi dei database NoSQL

Presentiamo i vantaggi dei database NoSQL anch’essi in maniera schematica,in modo da poter ottenere un confronto diretto con le problematiche esposteprecedentemente:

↑ Strutturazione dei dati: NoSQL non adopera le strutture ben poco flessibi-li dell’approccio relazionale. Questi nuovi approcci, infatti, conferiscono unamaggiore centralita alle informazioni e alla loro varieta, supportando l’uso didati non omogenei pur mantenendo le possibilita di interrogazione, analisi edelaborazione efficiente; si parla di Schemaless data representation.

↑ Scalabilita: a differenza dei database relazionali, quelli di tipo NoSQL sonogeneralmente basati su strutture fisiche che si prestano meglio alla distribuzione


dei dati su piu nodi di una rete (sharding), permettendone pertanto un’espandi-bilita maggiore. Tutta la complessita che e richiesta per le transazioni orientedRDBMS non esiste nei database NoSQL che, quasi sempre, non sono conformialle ACID (CouchDB e Neo4j sono esempi particolari di database NoSQL con-formi alle ACID).

↑ Prestazioni: la maggiore distribuzione dei dati sulle reti, dovuta allo scalingorizzontale, e un elemento che permette migliori performance. Le tecnologieRAID sono un esempio lampante di come la replica dei dati su piu strutturepermetta di rispondere piu rapidamente a tutte le richieste simultanee. Non e uncaso, quindi, che la crescita del movimento NoSQL sia coincisa con la diffusionedei social network, caratterizzati da un elevato numero di accessi simultanei.

↑ Flessibilita nella progettazione: la struttura flessibile usata nei database No-SQL non obbliga necessariamente ad avere dati stereotipati durante la proget-tazione ma lascia liberi i programmatori di risolvere eventuali casi particolaridirettamente in fase di sviluppo dell’applicazione. In fase di sviluppo e possibilepartire con NoSQL e migrare a RDBMS e viceversa. E’ possibile anche averescenari in cui serve un mix dei due database. Ad esempio Netflix e passatadall’avere Oracle RDBMS ad Apache Cassandra.

↑ Tempi di sviluppo: i database NoSQL non hanno il supporto per creare re-lazioni o avere chiavi esterne. Non ci sono piu query complesse e operazioni diJOIN. Questo comporta che affinche una query possa attraversare piu tabelle enecessario implementare piu query ma piu semplici. Tutto cio contribuisce aduna drastica diminuzione dei tempi di sviluppo.

1.7 NoSQL: a cosa si rinuncia

Uno degli aspetti piu critici dei database NoSQL e quello che viene messo inluce dal teorema CAP.

Cio che dimostra tale teorema e probabilmente il fattore principale che influen-za la scelta, in fase di pre-progettazione, della tipologia di database (RDBMS oNoSQL) da utilizzare.

1.7.1 Teorema CAP

Il teorema CAP (o teorema di Brewer) dimostra come sia impossibile per unqualsivoglia sistema informatico distribuito, riuscire a garantire contemporanea-mente questi tre aspetti (fig.1.2):

• Consistenza: ogni nodo ha la garanzia di osservare il dato corretto in ognimomento.

• Disponibilita: garantisce che ad ogni richiesta effettuata, venga fornitauna risposta (positiva o negativa).

• Tolleranza di partizione: indica la capacita del sistema distribuito dicontinuare a funzionare nonostante ci siano stati errori e/o perdite dimessaggi.


Inizialmente nato come congettura esposta all’Universita della California dal-lo scienziato informatico Eric Brewer (figura molto nota nel campo dell’IT edattualmente professore di ruolo all’universita di Berkeley in California), nel 2002,

Figura 1.2: Teorema CAP

grazie alla dimostrazione for-nita da Seth Gilbert e NancyLynch del MIT, ha assunto ilrango di teorema.

Il teorema, appunto, affermache un sistema distribuito puoessere in grado di soddisfarecontemporaneamente solo duedelle tre proprieta presenta-te.

Il teorema CAP e centrale neldiscorso che stiamo affrontan-do perche i database NoSQL,basandosi sul modello di con-sistenza BASE che vedremo abreve, forniscono elevata dispo-nibilita e tolleranza a discapitodella consistenza. Invece il mo-dello RDBMS, legato al modello ACID, garantisce consistenza e tolleranza dipartizione, a discapito della disponibilita.

1.8 Come cambiano le regole: da ACID a BASE

Siamo in grado di analizzare gli aspetti piu significativi dei database NoSQLidentificando un modello di appartenenza, equivalente all’ACID dei databaserelazionali. Cio grazie, ancora una volta, ad Eric Brewer che ha trasformato leregole ACID in regole BASE:

• Basic Availability (alta disponibilita): per ogni request e garantitauna response che puo indicare il successo o il fallimento dell’esecuzione.

• Soft state (stato dinamico): lo stato del sistema puo cambiare piuvolte, anche senza input.

• Eventual consistency (consistenza eventuale): il database puo es-sere momentaneamente inconsistente ma alla fine risultera tale. Que-sto significa che cio che e immagazzinato non deve essere consistentenecessariamente in fase di scrittura ma anche direttamente a tempo dilettura.

I modelli ACID e BASE sono i due piu comuni modelli di approccio per lacreazione di un database (fig.1.3). Molto spesso vengono visti come modellicontrapposti e si cerca di stabilire quale sia il migliore in tutto e per tutto; inrealta entrambi hanno i loro vantaggi e svantaggi e quasi mai nessuno dei duesi adegua perfettamente al caso d’uso.


Figura 1.3: ACID vs BASE

ACID consente di operare in un ambiente sicuro per i dati garantendo allafine di ogni transazione che i suoi dati si trovino in uno stato consistente e alsicuro sul disco. La scrittura consistente puo essere una grande vantaggio per glisviluppatori ma essa richiede meccanismi di locking che tipicamente presentanoun pattern pesantissimo per molti dei casi d’uso.

In effetti, in alcune applicazioni, le transazioni ACID sono piu pessimistichedi quanto il dominio ne richieda effettivamente; in molti scenari reali si sonopersi i requisiti per l’immediata consistenza e aggiornamento dei dati al fine diottenere altri benefici come lo scaling e l’elasticita garantiti da BASE.

Una base di dati BASE valorizza la disponibilita ma non offre garanzia di consi-stenza a tempo di scrittura. Oltretutto, il modello BASE fornisce meno garanziadell’ACID: i dati saranno consistenti nel futuro o direttamente a tempo di let-tura.

Siccome il modello BASE offre poca consistenza, una scelta di questo tipo ricadesulle spalle degli sviluppatori che dovranno lavorare molto accuratamente sullaconsistenza dei dati con cui lavorano. Cioe e essenziale essere familiari con ilmodello di sviluppo BASE prima di poter procedere a lavorare con esso; cio puoessere un grave svantaggio rispetto alla semplicita delle transazioni ACID.

Il modello ACID risulta quindi perfetto nelle applicazioni che richiedono for-te affidabilita e coerenza dei dati immessi al contrario del modello BASE chegarantisce scaling elevato e disponibilita.


1.9 Big Data

I database NoSQL trovano molto spazio nelle applicazioni Big Data grazie allasemplicita della struttura, allo scaling orizzontale piu semplice e alla maggioredisponibilita fornita.

Quando si parla di Big Data ci si riferisce ad una raccolta dati molto estesa, nonsolo in termini di volume, ma anche (e soprattutto) in termini di eterogeneitadei dati; tutto supportato da elevate velocita operazionali.

I dati con cui si lavora sono strutturati e non strutturati; basti pensare a tut-te le informazioni reperite dai social come messaggi, conversazioni, foto, video,registrazioni vocali oppure a dati di altro tipo come dati di geo-localizzazione,immagini, email ecc. Si parla quindi di domini al cui interno e presente unamole gigantesca di dati che puo essere dell’ordine degli Zettabyte.

Associato ai Big Data c’e il concetto delle cinque V (fig.1.4), ovvero cinqueparole chiave che consentono di mettere in luce schematicamente tutti i concettifondamentali di tale applicazione:

• Volume: si riferisce chiaramente alla mole di dati con cui opera il database.

• Velocity (velocita): la velocita e attribuita sia alla capacita di generaredati nuovi, sia a come essi viaggiano all’interno della struttura.

• Veriety (varieta): attribuito alla grande eterogeneita dei dati con cui siopera; si calcola che circa l’80% dei dati attuali mondiali risulta essereunstructured.

• Veracity (veridicita): ossia la qualita dei dati intesa come il valore infor-mativo che si riesce ad estrarre da essi. Si riferisce all’attendibilita (qualitae accuratezza) dei dati che viene messa a dura prova a causa dei moltissimidati a disposizione.

• Value (valore): la capacita di fornire servizi attraverso tale strumento ela trasformazione dei dati utilizzati in valori monetari. E’ chiaramenteun elemento fondamentale di tutto il processo, che pero si distacca dallequattro precedenti proprieta che si focalizzano sulle prestazioni.

Come abbiamo visto in precedenza, sono le soluzioni NoSQL quelle che fornisco-no la capacita ad un sistema di interagire con grandi volumi di dati eterogeneitra loro fornendo garanzia di velocita e scalabilita. E’ per questo motivo chenon e permesso in questo ambito l’utilizzo dei RDBMS.

1.10 Tipologie di database NoSQL

Essendo quello NoSQL un dominio ancora acerbo, non e ancora possibile rife-rirsi ad uno standard che riesca a dettare le linee guida per lo sviluppo di undatabase e che quindi riesca a classificare tutti i modelli gia esistenti sul mercato.

In generale pero, tra le decine e decine di esempi applicativi che ci vengono


Figura 1.4: Le cinque V

forniti, riusciamo ad evidenziare quattro categorie principali che si distinguonoper il tipo di memorizzazione che implementano, ognuna delle quali soddisfaparticolari esigenze: database a documenti (document-oriented-db), databasea grafo (graph-oriented-db), database chiave/valore (key/value-db), database acolonna (column-oriented-db):

• Document: una delle tipologie piu diffuse grazie alla sua flessibilita. Sonoutilizzati per archiviare (quindi inserire, ricercare e manipolare) grandiquantita di dati eterogenei. I dati vengono memorizzati come records(righe) come nei RDBMS; i records pero possono aderire o meno ad unospecifico schema. Fornisce infatti la possibilita di avere schemi variabilio anche documenti senza schemi: due records, ad esempio, possono avereset completamente differenti di campi o colonne.

Il vantaggio principale risulta proprio quello di non avere schemi da segui-re. Cio e molto utile in applicazioni web dove c’e bisogno di memorizzaredifferenti tipi di contenuto che puo evolvere nel tempo.

Inoltre la ricerca attraverso molteplici tipi di entita risulta molto piu sem-plice se comparata a quella dei relazionali. Infatti adesso scompare ilconcetto di tabella il che comporta che una query possa attraversare irecord a prescindere dal contenuto sottostante; in altre parole la query eeffettuata all’intero database.

Un altro grande vantaggio risulta quello di poter esprimere i dati attraversoil formato JSON.

Il JSON (Javascript Object Notation) e un formato utilizzato per l’in-terscambio di dati fra applicazioni client-server. Attraverso i documentiJSON e possibile memorizzare i dati in maniera schemaless. Di seguitoriportiamo un esempio di JSON:

{” Studente ” :[{

” Matr i co la ” :” N46001320 ” ,”Nome” :” Ste fano De Vincenzo ” ,”Eta ” :23


} ]}

Un altro documento potrebbe avere un insieme di attributi molto diverso;ad esempio:

{” Studente ” :[{

” Matr i co la ” :” M53192990 ” ,”Nome” :” Mario ” ,”Cognome ” :” Ross i ” ,”Eta ” : 35 ,” Cit ta ” :” Napol i ” ,” I n d i r i z z o ” :” Via Manzoni 86”

} ]}

Alcuni dei database piu popolari che implementano questo modello: Apa-che CouchDB, ApacheCassandra, Couchbase Server, Clusterpoint, Do-cumentDB, HyperDex, Lotus Notes, MarkLogic, OrientDB, Qizx, Re-thinkDB. MongoDB rappresenta il principale prodotto di questa serie e,secondo le stime, e uno dei database NoSQL piu diffusi al mondo.

• Graph: riproducono una delle strutture dati piu duttili dell’informatica,soprattutto per alcune tipologie di problematiche.

E’ particolarmente indicato quando si ha a che fare con dati fortemen-te connessi e si vuole avere una struttura performante per conoscere lerelazioni tra i dati.

I due elementi principali della struttura sono i vertici e gli archi : i primicontengono le informazioni mentre i secondi stabiliscono relazioni (link).

Questo modello ha una grossa rilevanza in molti problemi che spaziano invari domini: shortest path calculation, geodesic paths ed altri ancora.

Se non esistono relazioni tra i dati che si immagazzinano, il modello risultainutile.

Alcuni esempi sono : Neo4J, AllegroGraph, InfiniteGraph, Giraph, Mar-kLogic, OrientDB, Virtuoso, Stardog.

• Key/value: immagazzinano oggetti associando loro una chiave univoca chene permettera un agevole recupero.

Nascono per gestire con la massima efficienza semplici coppie chiave-valore, ad esempio per essere utilizzati come cache; la base di dati e vistacome una grossa hash-table.

Sono utilizzati quando si predilige la velocita di accesso al dato, quindiparticolarmente indicati quando si vogliono esaltare le operazioni CRUD(create, read, update, delete) e quando non c’e correlazione tra i dati damemorizzare.

Redis e probabilmente uno dei prodotti di questo tipo piu conosciuti; al-tri esempi sono: Oracle NoSQL Database, DynamoDB, MemcachedDB,


Aerospike, Couchbase, FairCom c-treeACE, FoundationDB, HyperDex,MemcacheDB, MUMPS, OrientDB, Riak, Berkeley DB.

• Column-oriented: sono database che immagazzinano dati in sezioni dicolonne a differenza dei RDBMS che utilizzano le righe.

Uno dei piu grandi vantaggi e quello di poter aggiungere colonne senza ilbisogno di doversi preoccupare di inserire valori di default; questo giovaalla flessibilita del modello permettendo di prepararsi per scenari futuri.

Le colonne non sono definite a priori e possono essere diverse per ogni riga,aggiunte o rimosse dinamicamente.

Quando si parla di database orientato alle colonne ci si riferisce sia allastruttura fisica vera e propria che ad una forte ottimizzazione per i carichidi lavoro.

Un altro punto a favore riguarda le molteplici possibilita per quanto ri-guarda l’ottimizzazione per la compressione dei file memorizzati, concettoassente nei row-oriented nei quali applicazioni di questo tipo comporte-rebbero risultati minori

Sottolineiamo in ogni caso che l’efficacia dei database dipende in granparte dal carico di lavoro sottostante. Ad esempio operazioni che ricercanotutti i dati per un singolo oggetto (una riga) risultano lenti nei databasea colonna mentre nei row-based un’operazione di questo tipo e effettuatain una singola lettura del disco. Ad ogni modo queste operazioni sonoabbastanza rare; nella maggior parte dei casi viene ricercato solo un subsetdi un particolare oggetto.

Forniamo un piccolo esempio per chiarire come opererebbe un databaseorientato alle colonne a differenza di uno orientato alle righe; supponiamodi voler memorizzare questo insieme di dati:

Matricola Nome CognomeN2301 Lucia RossiM0091 Mauro VerdiL7623 Marco Gialli

In un database RDBMS (row-based) i valori sarebbero memorizzati inquesto modo:

N2301 , Lucia , Ross iM0091 , Mauro , VerdiL7623 , Marco , G i a l l i

Un database orientato alle colonne, invece, serializza tutti i valori di unacolonna assieme, poi serializza i valori della seconda colonna e cosı via.Allora in un database di questo tipo i dati apparirebbero cosı:

N2301 , M0091 , L7623Lucia , Mauro , MarcoRossi , Verdi , G i a l l i


Tali strutture sono molto utilizzate nel campo dei Big Data in quantoforniscono un modello organizzato e flessibile. In particolare soluzioni diquesto tipo sono state adottate da Facebook, Google ed Amazon.

La prima applicazione ad usare questo tipo di memorizzazione fu, nel 1969,TAXIR: un’applicazione per la biologia dedita all’information retrieval.

Alcuni esempi di questo modello sono: Apache Cassandra, Hypertable,HBase, Google Datastore, Big Table, SimpleDB, Accumulo, Druid, Verti-ca, Microsoft SQL Server 2012 Enterprise Edition.

E’ bene notare che alcuni nomi compaiono in piu categorie perche sono difficilida classificare oppure perche effettivamente implementano diverse modalita distorage; questi ultimi sono detti multi-storage. Alcuni di essi sono: AlchemyDatabase, ArangoDB, CortexDB, FoundationDB, MarkLogic, OrientDB.

Come vederemo successivamente, OrientDB supporta le prime tre modalita disviluppo. In figura 1.5 possiamo rapidamente confrontare i modelli appenadescritti sulla base di alcune caratteristiche.

Figura 1.5: Confronto database

Esistono poi altre tipologie di database NoSQL quali gli Object Databeses e iMultidimensional Databases che pero non saranno oggetto di questa discussione.

1.11 Dove non si usa un database NoSQL

NoSQL non e certamente il modello che bisogna utilizzare in ogni applicazionene bisogna credere che abbia solo aspetti positivi; non e dunque la soluzione atutti i problemi che possono incorrere utilizzando RDBMS.

Il paradigma NoSQL pecca nel momento in cui il nostro dominio di interesse habisogno di transazioni sicure (tutto l’ambito finanziario), in cui istantaneamente


dobbiamo avere la possibilita di lavorare con dati consistenti; non e certamen-te un modello che si basa sull’affidabilita ne tanto meno sull’integrita dei dati.Non e un modello utile quando il dominio di interesse non intende espandersi esoprattutto e sconsigliabile utilizzarlo se si lavora con dati facilmente normaliz-zabili cioe con applicazioni che fanno uso di dati predefiniti, che riescano quindia rispettare i vincoli imposti da una tabella RDBMS. In breve:

↓ Non si utilizza in ambito economico-finanziario.

↓ Non si utilizza in ambienti che non hanno bisogno di espandersi.

↓ Non si utilizza in ambienti che fanno uso di dati “normalizzabili”.

In fig.1.6 riassumiamo le principali caratteristiche dei due approcci.

Figura 1.6: SQL vs NoSQL

Capitolo 2

OrientDB

Figura 2.1: Logo OrientDB

OrientDB e un database NoSQL di tipo document-graph-key/value, scritto inJava e con licenza open source (Apache 2.0).

Nasce in Italia (attraverso Orient Technologies) alla fine dell’ultima decade;oggi l’ultima versione disponibile e la 2.2.10 GA Community Edition, rilasciatail 15 Settembre 2016.

OrientDB e un database molto versatile dato che permette l’utilizzo di una mo-dalita di memorizzazione senza schema, con schema, oppure ibrida, supportandoal tempo stesso il linguaggio SQL; gestisce i permessi di accesso alla strutturaattraverso utenti, ruoli e regole.

Utilizza un particolare algoritmo di indicizzazione derivato dall’Albero RB edal B+tree chiamato MVRB-Tree, che gli permette di avere benefici sia nell’in-serimento che nella ricerca.

Siccome la JVM e l’unico requisito per utilizzare un server OrientDB, tale siste-ma puo essere installato su ogni macchina che supporti la piattaforma JAVA.

17

CAPITOLO 2. ORIENTDB 18

Quali sono le funzionalita principali di OrientDB:

• Supporto alle JOIN e alle ACID.

• Supporto a multiple modalita di storage: document, graph, key/value.

• Query SQL-like.

• Libreria API per Java.

• Supporto alla customizzazione del linguaggio (per scrivere funzioni Javapersonalizzate).

• Console per amministrare tramite linea di comando.

• Console web-based per amministrare tramite interfaccia grafica: OrientDB-Studio.

• Funzionamento embedded, in memory, client/server.

• Supporto nativo a JSON.

Alla base della struttura di questo database c’e la modalita document; cio edovuto al fatto che quando si parla di document ci si riferisce ad un tipo didato generico che puo essere associato a interi, stringhe, dati binari o addirit-tura riferimenti ad altri documenti. Attraverso tale modello siamo in grado dimemorizzare i documenti in strutture molto flessibili che prendono il nome dicollezioni.

La potenzialita di questo modello e dovuta al fatto che un documento nonha necessariamente una struttura fissa (come accennato prima, OrientDB ha unapproccio molto lasco) ma puo contenere un numero variabile, nel numero e neltipo, di campi.

2.1 Struttura OrientDB

In OrientDB i clusters sono le strutture principali utilizzate per organizzare idati. E’ possibile pensare ai clusters come ad un gruppo di records. Nel mondorelazionale non esiste un concetto simile.

I clusters possono non avere uno schema e colonne, i loro records sono chiamatidocuments e ogni documento puo essere differente da altri che appartengonoallo stesso clusters.

Ci sono due tipi di clusters: physical e in-memory. Il primo e persistente, ilsecondo volatile, ovvero viene distrutto quando il server va in shutdown. Perogni clusters OrientDB crea uno o piu file.

Il concetto di classe si posiziona ad un grado piu elevato di astrazione rispettoai clusters ed e assimilabile come il duale di una tabella nel mondo relazionale,cioe una struttura che immagazzina records. Le classi possono essere:


• Schema-full (vincoli obbligatori).

• Schema-less (non sono definiti vincoli).

• Mixed-mode.

Particolarita: i records di una classe possono essere memorizzati in differenticlusters. Cio e utile quando si ha un largo dataset di records che risulta conve-niente partizionare.

All’atto della creazione di una classe, OrientDB la definisce schema-less. Questosignifica che ogni record appartenente ad una classe puo avere differenti campidi qualsiasi tipo di dato supportato e puo accadere che due o piu records possa-no avere gli stessi campi ma con differenti tipi di dato. Chiaramente OrientDBsupportando anche le classi schema-full, cioe classi in cui sono dichiarati esplici-tamente i tipi di dato a loro associati, puo specificare se sono permessi o menovalori nulli e se sono obbligatori o opzionali.

E’ evidente che lo schema-less ha il vantaggio di poter essere utilizzato neicasi in cui non si conosce quale valore verra inserito, come un campo che devememorizzare un input arbitrario dell’utente. Lo schema-full invece controllerala validita dell’inserimento alzando un’eccezione se il valore non e coerente.

I tipi di dato disponibili in OrientDB si suddividono in due macro categorie:semplici e containers:

• I tipi di dato semplici sono: binary, boolean, byte, date, double, embedded,float, integer, long, short, string, link.

• I tipi di dato containers sono: linklist, linkset, linkmap, embeddedlist,embeddedset, embeddedmap.

2.1.1 Classi astratte

Come nel paradigma OOP e presente il concetto di classe astratta. Le classiastratte non sono associate ad alcun cluster (cluster ID = -1) e non possono me-morizzare records ma sono utili per definire le proprieta che ogni classe derivatadovra avere.

2.1.2 Sicurezza

OrientDB ha un modello di sicurezza molto solido che si basa su tre aspetti:utenti, ruoli e regole. Ogni database ha i suoi utenti associati, ogni utente hauno o piu ruoli e ogni ruolo ha delle regole da rispettare (fig.2.2).

2.1.3 Regole

Le regole definiscono i criteri di sicurezza applicati a risorse specifiche. Unaregola allora e l’insieme di una risorsa e dell’operazione applicabile a quellarisorsa stessa. Le operazioni consentite sono:

• NONE 0 bitmask # 0000


• CREATE 1 bitmask # 0001

• READ 2 bitmask # 0010

• UPDATE 4 bitmask # 0100

• DELTE 8 bitmask # 1000

• ALL 15 bitmask # 1111

E’ possibile effettuare combinazioni di piu regole al fine di personalizzarle. Adesempio:READ + UPDATE + DELETE= 2 + 4 + 8 = #1110

2.1.4 Ruoli

OrientDB utilizza i ruoli per capire se una operazione e consentita ad uno spe-cifico utente. Ogni ruolo e associato ad una o piu regole. I ruoli di default sonotre: admin (ha completo accesso al database), writer (puo leggere, creare, ag-giornare e cancellare records), reader (puo solo leggere). E’ comunque possibilecreare nuovi utenti e anche ruoli personalizzati.

2.1.5 Utenti

Gli utenti sono memorizzati nella classe OUser, ad eccezione di quelli definitinel file di configurazione XML (orientdb-server-config.xml), ovvero admin, roote guest. Ogni utente deve avere una password e almeno un ruolo. I ruoliassociati all’utente definiscono i diritti che ha l’utente per operare sul database.Di default ogni nuovo database ha tre utenti, associati ai tre ruoli dichiaratiprecedentemente (admin, writer e reader).

Figura 2.2: Sicurezza in OrientDB


2.1.6 Sicurezza a livello di record

La sicurezza a livello di record e una delle features piu potenti di OrientDB.Utilizzando questa funzionalita gli sviluppatori possono applicare un accessomolto fine attraverso dei permessi di sicurezza associati ad ogni singolo recorddi una classe. Con questa funzione ogni record avra dei campi addizionali cheindicheranno se un utente puo accedere e con quali privilegi.

2.2 Esempio applicativo

Prima di inoltrarci nel vero e proprio esempio pratico, mostriamo quali sono iprimi passi da effettuare per lavorare con OrientDB.

Ricordiamo che l’ambiente di lavoro attraverso cui presentiamo l’esempio e lashell Windows.

2.2.1 Primo approccio ad OrientDB

Scarichiamo una qualsiasi versione dal sito ufficiale: http://orientdb.com/

download/

Scompattiamo il file scaricato, rechiamoci nella cartella bin appena estrattae facciamo partire il server attraverso il comando:

orientdb> start server.bat

Fatto cio ci colleghiamo, tramite console.bat, al database predefinito (fig.2.3) inquesto modo:

orientdb> connect remote:127.0.0.1/temp admin admin

Figura 2.3: Connessione al server temporaneo

OrientDB infatti fornisce un database predefinito chiamato temp.

http://orientdb.com/download/

http://orientdb.com/download/


A questo punto vediamo cosa comporta la creazione di una classe (fig.2.4):

orientdb> create class Prova e poi diamo il comando info.

Figura 2.4: Creazione di una classe

All’interno della tabella che contiene tutti i clusters presenti nel database ap-pare un nuovo cluster denominato proprio come la nostra classe (in minuscolo).Notiamo poi che ogni cluster ha il suo proprio ID.

Anche all’interno della tabella delle classi appare il nome della classe appe-na creata. Inoltre ci vengono mostrate delle informazioni sintetiche come adesempio il numero di records inseriti (per adesso 0).

Equivalentemente ai clusters, anche ad ogni record e associato un unico ID, de-nominato RID. Un RID ha una struttura del tipo #<cluster-id>:<position>.I RID sono dei veri e propri puntatori fisici ai records; cio significa che le ope-razioni di attraversamento e di LINK attraverso i documenti sono molto velociperche non ci sono overheads di consultazioni. Questa e la piu grande featuredi OrientDB rispetto ai database relazionali: conoscendo la posizione fisica deirecords e possibile raggiungerli senza effettuare ricerche ad indice al contrariodei RDBMS che devono effettuare questo tipo di ricerca che, genericamente, eeseguita in un tempo O(log(n)) (logaritmico) mentre OrientDB esegue in O(1)(costante) (fig.2.5).

Infine attraverso il comando ? possiamo visualizzare tutti i comandi disponibili.Una parte di essi e visibile in fig.2.6.


Figura 2.5: Classificazione complessita degli algoritmi

Figura 2.6: Parte dell’elenco dei comandi disponibili


2.2.2 Creazione della base di dati

Passiamo adesso all’esempio pratico vero e proprio. Supponiamo di voler creareuna base di dati che gestisca (una piccola parte) dell’universita di Napoli Fede-rico II.

Si vogliono gestire le relazioni che intercorrono tra i corsi di studio previstidall’universita e i diversi insegnamenti per ognuno di essi; inoltre gestiamo tuttii rappresentanti, ognuno per ogni tipo di insegnamento.

Creiamo una prima classe (CorsoDiStudio) contenente i corsi di studio:

• Ingegneria.

• Economia.

• Scienze.

Creiamo poi una seconda classe (Insegnamento) contenente gli insegnamentiassociati ad ogni corso di studio:

• Ingegneria: informatica, civile, edile.

• Economia: aziendale, finanza.

• Scienze: chimica, fisica, biologia.

Si ottiene una relazione 1−N tra CorsoDiStudio - Insegnamento e una relazione1− 1 tra Insegnamento - Rappresentante. In figura 2.7 abbiamo rappresentatoil modello ER (non rappresentando gli attributi di ogni entita e le associazionitra le stesse) del database.

Figura 2.7: Modello ER

Connettiamoci al server e creiamo una base di dati chiamata uniFEDERICOIIdi tipo document, utilizzando come memorizzazione la plocal (persistente).

orientdb> create database remote:localhost/uniFedericoII


root E5FFDC71E1BD6D3EF09832AD177EAD180A9558

E795E9B5298440ED54A3E8C38B document

Per fare cio abbiamo utilizzato l’account root per il quale ricaviamo la pas-sword (generata automaticamente) direttamente dal file XML orientdb-server-config.xml.

Ci connettiamo al database appena creato (fig.2.8):

orientdb> connect remote:localhost/uniFedericoII admin admin

Figura 2.8: Connessione al server uniFedericoII

Modifichiamo le password dei tre utenti predefiniti (admin, reader, writer) perconsentire, in futuro, un accesso piu semplice (fig.2.9):

orientdb> update OUser set password=admin where name=“admin”orientdb> update OUser set password=reader where name=“reader”orientdb> update OUser set password=writer where name=“writer”

Figura 2.9: Cambio password utenti predefiniti

Creiamo le tre classi (fig.2.10):

orientdb> create class CorsoDiStudio

orientdb> create class Insegnamento


orientdb> create class Rappresentante

Figura 2.10: Creazione classi

Siamo adesso in grado di poter interagire con il database per mostrare le prin-cipali potenzialita di OrientDB, presenti in ogni tipo di database NoSQL.

2.2.3 Prima potenzialita: classi schema-less

Inizialmente le classi sono definite schema-less quindi e possibileinserirvi qualsiasi campo.

Definiamo i tre corsi di studio (fig.2.11) inserendo un campo qualsiasi, ad esem-pio nome:

orientdb> insert into CorsoDiStudio (nome) values (“Ingegneria”)orientdb> insert into CorsoDiStudio (nome) values (“Economia”)orientdb> insert into CorsoDiStudio (nome) values (“Scienze”)

Figura 2.11: Popolamento classe CorsoDiStudio

Effettuiamo a questo punto un’operazione di SELECT che stampera a video tuttala classe per verificare la correttezza dell’inserimento precedente (fig.2.12):


orientdb> select from CorsoDiStudio

Figura 2.12: Esempio di SELECT su CorsoDiStudio

Infine evidenziamo come le operazioni di SELECT possano essere effettuate, alfine di aumentare le prestazioni, direttamente sul RID del record di interesse(fig.2.13). L’esecuzione della query infatti passa da 0.019 secondi a 0.013 secondi.

Figura 2.13: Confronto tra query


Per proseguire con l’esempio pratico popoliamo anche la classe Insegnamento(fig.2.14) e la classe Rappresentante (fig.2.15).

Figura 2.14: Popolamento classe Insegnamento

Figura 2.15: Popolamento classe Rappresentante


2.2.4 Seconda potenzialita: noncuranza dei valori

Inseriamo nella tabella Insegnamento il numero di studenti che si iscrivono inmedia ogni anno (fig.2.16).

Modifichiamo poi il campo numeroStudenti dell’ insegnamento Fisica edichiariamo una stringa al posto di un intero.

Figura 2.16: Inserimento del numero di studenti

Osserviamo (fig.2.17) come l’inserimento di una stringa ove (dovrebbe) esserciun intero non causa alcun errore. Questa e una delle potenzialita piu ricercatein quegli ambienti in cui si deve operare con dati eterogenei perche, appunto, ciconsente di operare con qualsiasi dato senza la necessita di doverci occupare deivincoli.

Figura 2.17: Seconda potenzialita


2.2.5 Terza potenzialita: campo embedded

OrientDB fornisce la possibilita di utilizzare un campo di tipodocument-embedded. Attraverso questo tipo possiamo associare a

qualsiasi campo una stringa JSON.

Inseriamo un nuovo rappresentante non considerando i campi nome e cogno-me ma andando ad inserire un campo embedded che ne specifichi la data ed illuogo di nascita (fig.2.18).

Figura 2.18: Campo embedded

Ovviamente anche i record embedded possono essere oggetto di una query (2.19).

Figura 2.19: SELECT su campo embedded

2.2.6 Quarta potenzialita: campi containers

I containers sono dei campi speciali che possono contenere un insiemedi altri campi.

Ci sono tre tipi di containers: set, list e map:

• Set e un insieme di elementi non ordinato.


• List e una sequenza ordinata di elementi.

• Map e un insieme formato da coppie chiave/valore ove le chiavi sonostringhe e i valori possono essere qualsiasi tipo consentito, anche altricontainers.

Inseriamo un nuovo rappresentante di cui specifichiamo solo un campo containerche memorizzera i due indirizzi ove tale insegnante riceve gli studenti (fig.2.20).

Figura 2.20: INSERT campo container

Figura 2.21: SELECT campo containers

Notiamo (fig.2.21) che effettuando una SELECT per stampare a video il valore diun campo container, non viene mostrato il contenuto del campo ma solo la suacardinalita che in questo caso risulta essere pari a 2. Per mostrare il contenutoe sufficiente il comando:

orientdb> select flatten(embset) from Rappresentante where embset is

not null

2.2.7 Analogia a schemi relazionali: vincoli

Fino ad ora abbiamo visto come si utilizzano le classi nella modalita schema-less. OrientDB pero fornisce anche la possibilita di specificare per ogni campo,il tipo a cui deve sottostare; ovvero permette di creare un vincolo nello schema.Possiamo allora dichiarare se una classe deve essere schema-full o anche mixed-mode.

Supponiamo di voler associare ad ogni insegnamento l’anno in cui e stato creato,il cui valore deve essere una data; creiamo allora un vincolo (fig.2.22):


orientdb> create property Insegnamento.annoFondazione date

A questo punto inseriamo un nuovo insegnamento utilizzando come anno difondazione un valore che non rispetti il vincolo, ad esempio una stringa:

orientdb> insert into Insegnamento (tipologia,annoCreazione) values

(“Economia delle Imprese Finanziarie”,“Duemiladue”)

Figura 2.22: Esempio di vincolo non rispettato

In figura 2.22 possiamo osservare come stavolta venga alzata un’eccezione cau-sata dal fatto che si e tentato di convertire il valore Duemiladue in una datache, invece, ha un formato del tipo yyyy-MM-dd.

Inoltre e possibile attraverso il comando STRICTMODE, evitare che una opera-zione di INSERT possa aggiungere dei campi precedentemente non dichiarati.

Ad esempio se prima di dichiarare la classe in modalita STRICTMODE, provassimoad inserire un nuovo campo anni, non ci sarebbe restituito errore (fig.2.23):

Figura 2.23: STRICTMODE assente

Utilizziamo allora la modalita STRICTMODE (fig.2.24):

orientdb> ALTER CLASS Insegnamento STRICTMODE true


In questo modo bisogna rispettare i campi presenti (Nome,Cognome,anni) enon e possibile aggiungerne altri.

Infatti provando ad inserire dei valori del genere:

orientdb> insert into Rappresentante (Nome,Cognome,anni,luogoNascita)

values (“Stefano”,“De Vincenzo”,23,“Napoli”)

alzeremmo un’eccezione dato che il campo luogoNascita non e stato preven-tivamente dichiarato.

Figura 2.24: STRICTMODE presente

2.2.8 Analogia a schemi relazionali: relazioni-JOIN

Nonostante anche in OrientDB esita il concetto di relazione, analogamente aglischemi relazionali, tale concetto assume sfumature differenti.

Innanzitutto quando si crea una relazione in OrientDB, si stabilisce una con-nessione fisica tra i documenti.

Cio comporta che un’ operazione di JOIN che debba recuperare un documentoassociato ad un altro documento non abbia costo computazionale.

Per questo motivo OrientDB risulta molto veloce quando si maneggiano mi-lioni di records correlati tra loro.

Le relazioni tra records possono essere di due tipi:

• Referenced: utilizzati per creare associazioni tra documenti.

• Embedded: sono relazioni piu forti, simili alla composizione nei diagrammiUML. Questo tipo di relazione e utile per modellare i collegamenti tradocumenti che hanno un ciclo di vita dipendente.

Le associazioni 1− 1 e 1−N del nostro esempio possono essere create tramiteun campo di tipo LINK che, accettando valori di tipo RID, crea un collegamentofisico tra i documenti.


Nel nostro esempio ad ogni corso di studio sono associati uno o piu insegna-menti. Ad ogni insegnamento e associato un solo corso di studio. Facciamo inmodo che da ogni insegnamento sia possibile risalire al corso di studio. Per farecio utilizziamo:

orientdb> create property Insegnamento.corsodistudio link

CorsoDiStudio

Vediamo come e stata modificata la classe Insegnamento: e stato aggiunto(fig.2.25) un nuovo campo chiamato corsodistudio di tipo LINK, collegato (LINKED)alla classe CorsoDiStudio ed e stato associato (fig.2.26) ad ogni insegnamentoil corso di studio corrispondente che, inizialmente, e un campo vuoto (null).

Figura 2.25: Associazione 1-N

Figura 2.26: SELECT su associazione 1−N


Popoliamo inizialmente solo il campo corsodistudio relativo all’insegnamento In-formatica (fig.2.26); effettuiamo poi una query per verificare che effettivamenteappaia il corso di studio di ingegneria (fig.2.26).

Figura 2.27: Comando TRAVERSE

Associamo quindi ad ogni Insegnamento il CorsoDiStudio e utilizziamo il co-mando TRAVERSE (fig.2.27).

Il comando TRAVERSE e un comando molto potente, di frequente utilizzato neidocument database. Viene utilizzato spesso perche, assegnata una tabella, for-nisce tutti i records collegati ad essa evitando di stampare due records identici.Risulta molto simile all’operatore JOIN dei database relazionali.

Dopo aver associato ad ogni insegnamento il corrispettivo corso di studio, asso-ciamo il rappresentante (relazione 1− 1) (fig.2.28).

Figura 2.28: SELECT su tabella, post inserimento relazioni

A questo punto riutilizziamo il comando TRAVERSE che ci consente in questocaso di rilevare tutto il database (fig.2.29).


Figura 2.29: Comando TRAVERSE che rileva tutto il database

2.3 OrientDB: graph-database

L’ultima applicazione che riportiamo riguarda OrientDB-graph, sottolineandoche l’architettura a grafo discende direttamente da quella document dal momen-to che ogni nodo risulta essere un vero e proprio documento.

Supponiamo di voler utilizzare tale struttura per fornire una sorta di mappapolitica nella quale memorizzeremo le citta italiane e, per ogni coppia di esse,ne evidenzieremo la distanza in chilometri. Per motivi pratici e per rendere iltutto piu fruibile faremo un esempio molto semplice in cui consideriamo quattrocitta italiane: Napoli, Roma, Venezia e Firenze.

Innanzitutto, come abbiamo fatto precedentemente, creiamo tramite shell Win-dows (dopo aver fatto partire server.bat) un nuovo database che chiameremoMappa. Fatto cio utilizziamo console.bat per connetterci (fig.2.30) al suddettodatabase.

A questo punto passiamo alla vera e propria parte pratica: creiamo quindi ivertici (fig.2.30), ognuno corrispondente ad una citta e, per ogni coppia di ver-tici (nel nostro caso il numero di coppie totali e pari a 6: Napoli-Roma, Napoli-Venezia, Napoli-Firenze, Roma-Venezia, Roma-Firenze, Venezia-Firenze), unedge (fig.2.31) che ne rappresentera la distanza.


Figura 2.30: Collegamento al database e creazione dei vertici

Figura 2.31: Creazione dei collegamenti


Accediamo tramite browser al database appena creato attraverso l’indirizzohttp://localhost:2480/, scegliendo il database Mappa e utilizzando le cre-denziali di accesso admin admin (fig.2.32).

Figura 2.32: OrientDB studio

Accedendo alla sezione Graph possiamo visualizzare la struttura grafica del da-tabase (fig.2.33).

Infine presentiamo un’applicazione di una query ad un database di questo tipo.Ad esempio potremmo ricercare tutte le citta (e le relative distanze) che sonocollegate ad una fornita dall’utente (fig.2.34).

http://localhost:2480/


Figura 2.33: OrientDB graph

La query seleziona i nomi delle citta tra i risultati della TRAVERSE e della WHERE.In particolare l’operazione di TRAVERSE ritorna tutti i vertici ed i collegamentiche partono dal RID #8:0 (Napoli) e si ferma quando viene raggiunta la pro-fondita (depth) di 2. L’operatore WHERE serve ad eliminare i link, a manteneresolo i vertici e ad escludere il nodo radice, cioe quello di partenza.

Figura 2.34: SELECT su Graph-DB

Conclusioni

Nonostante la tecnologia NoSQL non abbia alla base delle linee guida che neriescano ad identificare e differenziare gli aspetti fondamentali, abbiamo vistocome tale modello si sia nel corso degli anni sviluppato molto velocemente.

Ad oggi sono moltissime (piu di 220) le tipologie e le applicazioni in circola-zione (in gran parte Open Source) che si distinguono tra loro per tantissimecaratteristiche peculiari.

Cio che pero le accomuna tutte e il fatto di poter essere una valida alterna-tiva a quello che e stato fino ad ora il modello piu utilizzato in tutti gli scenariapplicativi, ovvero il modello relazionale.

Per avere un quadro della situazione piu chiaro, sono state messe in eviden-za tutte le lacune di tale modello, come la scarsa disponibilita e l’inflessibilitadei suoi schemi.

Fatto cio abbiamo apprezzato in che modo i database NoSQL vogliano risolvere iproblemi che vengono riscontrati con i relazionali, enfatizzando le caratteristichepiu richieste nei casi d’uso moderni come velocita, scalabilita e alta disponibilita.

Successivamente e stata posta l’attenzione sui modelli di sviluppo che stannoalla base di tali strutture: ACID e BASE. Di tali modelli ne sono state espostele caratteristiche, evidenziandone le differenze.

E’ stata poi fornita una breve spiegazione del perche i database NoSQL nonpossano essere la soluzione di tutti i problemi applicativi che intercorrono con idatabase RDBMS e abbiamo quindi differenziato, per entrambe le tecnologie, icasi d’uso in cui sarebbe piu opportuno utilizzarli.

Infine abbiamo presentato un piccolo esempio attraverso OrientDB, un data-base NoSQL di tipo document-graph-key/value che ci ha permesso di mostrare,in maniera pratica, alcuni dei vari aspetti positivi di tali database (in partico-lare dei document e dei graph) quali la flessibilita sugli schemi, l’introduzionedi campi particolari come gli embedded-document e la capacita di poter lavorarecon dati non strutturati ; parametri che oggigiorno prevalgono sul mercato.

Bibliografia

[1] G.Vaish, Getting Started with NoSQL, Packt Publishing, Birmin-gham, 2013.

[2] A.Chianese, V.Moscato, A.Picariello, L.Sansone, Basi di dati perla gestione dell’informazione, McGraw-Hill, Milano, 2010.

[3] C.Tesoriero, Getting Started with OrientDB, Pack Publishing,Birmingham, 2013.

[4] The Apache Software Foundation, URL: https://www.apache.

org/

[5] Database NoSQL, URL: http://nosql-database.org/

[6] Guida OrientDB, URL: http://www.html.it/guide/

guida-orientdb/

41

https://www.apache.org/

https://www.apache.org/

http://nosql-database.org/

http://www.html.it/guide/guida-orientdb/

http://www.html.it/guide/guida-orientdb/

Database NoSQL: OrientDB - ingegneria- · PDF fileScuola Politecnica e delle Scienze di Base...

Documents

Transcript of Database NoSQL: OrientDB - ingegneria- · PDF fileScuola Politecnica e delle Scienze di Base...