Data Base NoSQL multi -modello:OrientDB · INDICE 4 Il tratto caratteristico dei database NoSQL e...

Scuola Politecnica e delle Scienze di Base Corso di Laurea Specialistica in Ingegneria Informatica Tesi di Laurea Triennale in Basi di Dati

Data Base NoSQL multi-modello:OrientDB

Anno Accademico 2017/2018 candidato Stefano Silvestri matr. N46002755

Indice

Introduzione 3

1 Dai database relazionali ai NoSQL 51.1 Il database relazionale . . . . . . . . . . . . . . . . . . . . . . . . 51.2 SQL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61.3 Sistemi NoSQL . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71.4 Modelli di database NoSQL . . . . . . . . . . . . . . . . . . . . . 8

1.4.1 Archivi chiave-valore (Key-Values stores) . . . . . . . . . 81.4.2 Archivi a documento (Document-Oriented stores) . . . . 91.4.3 Archivi a colonne (Column oriented) . . . . . . . . . . . 101.4.4 Archivi a grafo (Graph Database) . . . . . . . . . . . . . 11

1.5 Teorema CAP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 131.5.1 Il modello BASE . . . . . . . . . . . . . . . . . . . . . . . 14

1.6 Ambiti in cui non si usa il database NoSQL . . . . . . . . . . . . 15

2 Il database OrientDB 162.1 Struttura di Orientdb . . . . . . . . . . . . . . . . . . . . . . . . 17

2.1.1 Classi astratte . . . . . . . . . . . . . . . . . . . . . . . . 182.1.2 Sicurezza . . . . . . . . . . . . . . . . . . . . . . . . . . . 182.1.3 Regole . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 182.1.4 Ruoli . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 182.1.5 Utenti . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19

2.2 Esempio Applicativo . . . . . . . . . . . . . . . . . . . . . . . . . 192.2.1 Creazione della base di dati . . . . . . . . . . . . . . . . . 202.2.2 Primo aspetto: classi schema-less . . . . . . . . . . . . . . 212.2.3 Secondo aspetto: Non ci sono vincoli . . . . . . . . . . . . 222.2.4 Terzo aspetto: campo embedded . . . . . . . . . . . . . . 232.2.5 Quarto aspetto: i campi containers . . . . . . . . . . . . . 242.2.6 Analogie con schemi relazionali: i vincoli . . . . . . . . . . 252.2.7 Analogie con schemi relazionali: Relazioni tra classi . . . 25

Conclusioni 29

Bibliografia 30

2

Introduzione

Negli ultimi decenni, con lo sviluppo e la diffusione di internet, chiunque ha avu-to l’opportunita di possedere un computer e di connettersi alla rete per gestiremolteplici servizi, quindi e risultato necessario dare agli utenti la possibilita dimanipolare o modificare i dati in maniera semplice ed efficace, per far fronte atutto questo sono stati creati i database.Un database puo essere definito come un insieme di dati tra loro correlati, me-morizzati su un supporto di memoria di massa, costituenti un tutt’uno, chepossono essere manipolati da piu programmi applicativi.Il termine database e stato a lungo sinonimo di SQL o meglio di RDBMS, e– per almeno quattro decenni – sembrava che non ci fosse alcuna alternativapraticabile. Recentemente, tuttavia, il mondo della memorizzazione dei dati haa disposizione una nuova ed interessante possibilita: NoSQL.NoSQL sta per “Not Only SQL” e questo sottolinea che la tecnologia NoSQLnon e del tutto incompatibile con SQL (Structured Query Language), anzi, inalcuni casi e possibile utilizzare lo stesso linguaggio SQL per interrogare i data-base NoSQL, seppure con alcune importanti limitazioni come le JOIN.Il database NoSQL ha avuto il suo inizio come una soluzione in-house per risol-vere problematiche sperimentate da aziende di grandi dimensioni come Google,Amazon e Facebook. Inizialmente, queste aziende hanno cercato di risolvere iloro problemi con SQL, ma ben presto hanno scoperto che cio non poteva sod-disfare le loro esigenze e si sono scontrati con tre requisiti fondamentali:• Volumi delle transazioni senza precedenti• La necessita di bassa latenza di accesso ai set di dati enormi• La disponibilita del servizio

NoSQL non e sicuramente indicato per tutti gli utilizzi e non e un rimpiaz-zo dei database RDBMS tradizionali, ma puo affiancarli o in parte sostituirli, ei suoi vantaggi principali lo rendono utile, se non addirittura indispensabile, inalcune occasioni. Tra i database NoSQL ricodiamo 4 tipi differenti:• Key-value• Document• Column-family• Graph

3

INDICE 4

Il tratto caratteristico dei database NoSQL e l’abbandono della rigidita delmodello relazionale, in cui i dati sono precisamente strutturati, infatti un recordpuo contenere qualsiasi tipo di dato, senza che i suoi contenuti debbano esserenormalizzati con quelli degli altri record. Puo ridurre in modo significativo itempi di sviluppo perche elimina la necessita di affrontare query SQL complesseper estrarre dati strutturati, infine i database NoSQL, se utilizzati correttamen-te, restituiscono i dati in modo rapidissimo rispetto ad un database tradizionale.

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, attraversocui presenteremo un piccolo esempio pratico che ci permettera di evidenziarequanto sia semplice e intuitivo lavorare con un database di questo tipo.

Capitolo 1

Dai database relazionali aiNoSQL

In questo capitolo tratteremo gli aspetti fondamentali di un database relazio-nale, spiegheremo il significato di una base di dati SQL, introdurremo tutti iconcetti di un database NoSQL, le sue proprieta e infine metteremo a confrontoi due modelli con i rispettivi vantaggi e svantaggi annessi.

1.1 Il database relazionale

Una base di dati relazionale e l’insieme di informazioni associato a collezioni didati tra di loro correlati e dotati di un’opportuna descrizione. L’insieme dei datioggi viene gestito da uno strato software che prende il nome di DBMS (DataBase Management System).Alcuni concetti chiave di un database relazionale sono:• La tabella e la struttura dati fondamentale di un database relazionale.• Con le tabelle si rappresentano le entita e le relazioni dello schema concet-tuale.• Ogni riga della tabella rappresenta un’ istanza ed e anche chiamata tupla.• Ogni colonna della tabella rappresenta un attributo della relazione.• L’insieme dei campi i cui valori identificano univocamente un record all’inter-no di una tabella e detto Primary key(chiave primaria).In ogni tabella deveesistere sempre una chiave primaria e questa non puo avere alcun valore nullo.• Un vincolo di integrita referenziale tra due o piu tabelle e detto Foreignkey(chiave esterna). Essa identifica una o piu colonne di una tabella (referen-ziante) che referenzia una o piu colonne di un’altra tabella (referenziata).

5

CAPITOLO 1. DAI DATABASE RELAZIONALI AI NOSQL 6

Figura 1.1: Esempio database relazionale

Tutte le operazioni svolte su una base di dati relazionale prendono il nome ditransazioni, esse devono rispettare alcune proprieta fondamentali, le cosiddetteACID :• Atomicita: ogni transazione e atomica, o e eseguita nella sua interezza oppurenon e proprio eseguita.• Consistenza: una transazione e una trasformazione di uno stato consistentedella base di dati ad un altro stato consistente. Un DBMS deve assicurare chetutti i vincoli definiti siano soddisfatti.• Isolamento: le transazioni devono essere eseguite in modo indipendente l’unadalle altre.• Durability o Persistenza: gli effetti di una transizione terminata con ”commit”devono essere registrati in modo permanente nella base di dati e non devonoessere persi per alcun motivo.

1.2 SQL

SQL e l’acronimo di Structured Query Language e indica un linguaggio di pro-grammazione per database che permette di creare, trasformare e recuperareinformazioni in un RDBMS. Nasce nel 1974 in uno dei laboratori IBM da Do-nald Chamberlin, nel 1986 e stato adottato come standard dall’ANSI e nel 1987da ISO.Lo Structured Query Language e un linguaggio di programmazione dichiarativo,permette di interrogare e gestire i database per mezzo di costrutti di program-mazione denominati query.Lo SQL si compone di cinque parti fondamentali:• DDL (Data Definition Language) consente di creare o cancellare database omodificarne la struttura.• DML (Data Manipulation Language) permette di inserire, cancellare e modi-ficare dati.• DCL (Data Control Language) da la possibilita di gestire gli accessi e i per-messi dei vari utenti del database.


• DL (Query language) consente l’interrogazione di un database per estrarre oaggiornare i dati che soddisfano un certo criterio di ricerca.• DMCL (Device Media Control Language) permette di amministrare i sup-porti dove vengono salvati i dati.

1.3 Sistemi NoSQL

Il termine NOSQL fu introdotto da Carlo Strozzi nel 1998 per indicare il suodatabase relazionale open-source che non aveva una interfaccia SQL standard.Il termine attualmente indica tutti quei database che sono: non relazionali, di-stribuiti, open-source (spesso) e scalabili orizzontalmente.Per comprendere lo sviluppo dei database NoSQL conviene partire dalle ragio-ni che hanno portato alcune aziende nel corso degli anni a superare il modellorelazionale, a favore di un database che fosse in grado di meglio gestire certiproblemi.Aziende come Google, Amazon o Facebook avevano la necessita di gestire volu-mi di dati eccezionalmente grandi, con la necessita di avere dei tempi di rispostabassi anche con insiemi di dati enormi, pur mantenendo una elevata disponibi-lita del servizio. Queste problematiche difficilmente erano risolvibili attraversoun database relazionale.La ragione per cui un database relazionale non e in grado di gestire volumienormi di dati deriva in parte dal modo in cui esso viene utilizzato nella mag-gior parte dei casi: per gestire dati organizzati su tabelle normalizzate. Questoschema porta ai seguenti problemi:• Non flessibilita, aggiungere una colonna e un’ operazione estremamentecomplicata.• Query complesse, chiamate JOIN-queries, difficili da implementare e checomportano un elevato consumo di risorse per essere eseguite.• Aggiornamento dei dati: aggiornare i dati nelle tabelle e probabilmenteuno degli scenari piu critici, specialmente se cio deve essere fatto in una transa-zione; inoltre mantenere a lungo una transazione fa calare le performance.• Scalabilita: I database relazionali hanno sempre fatto affidamento allo sca-ling verticale 1 che ha portato ad avere prestazioni sempre piu potenti; evidente-mente pero l’aumento di utenza ha reso necessario scalare anche orizzontalmente2 per fornire prestazioni piu elevate in termini di accesso e maggiore sicurezzasui dati. Lo scaling orizzontale pero entra in conflitto con le restrizioni del mo-dello ACID, legato indissolubilmente alla consistenza dei dati.

1Scaling verticale: Con scaling verticale, si intende la sostituzione di una risorsa IT peruna con maggiore o minore capacita di gestione del carico. Quando sostituiamo una risorsaper una con maggiore capacita, stiamo scalando in alto; se invece la sostituiamo per una conminore capacita stiamo scalando in basso.

2Scaling orizzontale: Con scaling orizzontale, si intende l’allocazione o il rilascio dellerisorse IT dello stesso tipo con la possibilita di intervenire sulla propria struttura aggiungendoo eliminando Cloud Server.


Proprio per le difficolta elencate precedentemente in alcuni ambiti si prediligeusare i database NoSQL. I principali vantaggi derivanti si possono riassumere in:

• Elevata velocita computazionale anche al crescere del volume dei dati,legata alla mancanza di operazioni di aggregazione dei dati (no join) e ad unaimplementazione del database ottimizzata per la gestione di enormi quantita didati; questa velocita e anche il frutto di alcune semplificazioni introdotte nellamaggior parte dei database NoSQL: il mancato supporto delle transazioni ACIDe la sostituzione con transazioni BASE.

• Riduzione dei tempi di sviluppo grazie alla definizione di logiche dilettura dati molto piu semplici rispetto a quelle da scrivere con database rela-zionali che operano su dati normalizzati.

• Scalabilita: i database NoSQL sono pensati da zero per gestire i datidistribuiti su un cluster di nodi. L’approccio NoSQL vuole tra l’altro che i nodisiano autonomi fra loro, quindi e facile aggiungere un nuovo nodo quando servepiu potenza complessiva e la gestione delle query e molto veloce: il primo nodoche puo ”rispondere” con i dati giusti lo fara.

• Schemaless: i database NoSQL sono privi di schema in quanto l’entitacontiene tutti i campi necessari, senza necessita di una definizione formale erigida del suo contenuto. In questo modo, e possibile arricchire le applicazionidi nuovi dati e informazioni, senza dover sottostare ad una rigida struttura deidati.

• elevato livello di disponibilita del servizio grazie al supporto delladata-replication (database distribuiti), piu semplice da realizzare per i databaseNoSQL.

1.4 Modelli di database NoSQL

I database NoSQL sono classificati in base al tipo di modello che utilizzano perla memorizzazione dei dati. Possono essere individuate quattro grandi famiglie:

1.4.1 Archivi chiave-valore (Key-Values stores)

Sono costituite come strutture dati conosciute in informatica come dizionari omappe: al loro interno vengono inseriti due valori alla volta, una chiave e ilvalore ad essa associato. Quest’ultimo contiene l’informazione vera e propria,mentre il primo e l’identificatore che permette l’estrazione rapida del valore daldatabase. Sono impiegati quando si predilige la velocita di accesso al dato,quindi particolarmente indicati quando si vogliono esaltare le operazioni CRUD


(create, read, update, delete) e quando non c’e correlazione tra i dati da me-morizzare. I key-value store vengono anche utilizzati molto spesso per salvarele sessioni degli utenti in ambito web o per i cosiddetti “carrelli della spesa”,infatti, hanno come vantaggio l’altissima disponibilita dei dati e altissime per-formance per quel che riguarda l’accesso ai dati, in quanto, l’indirizzamento ditipo hash ha un costo molto basso che va da O(1) a O(log (n)) dove n corrispon-de alla quantita di dati presenti nel db.E’particolarmente adatto per casi d’usoquali i videogiochi, le tecnologie pubblicitarie e l’IoT. Redis e probabilmenteuno dei prodotti di questo tipo piu conosciuti; altri esempi sono: Oracle NoSQLDatabase, DynamoDB, MemcachedDB e Aerospike.

Figura 1.2: Esempio database chiave-valore

1.4.2 Archivi a documento (Document-Oriented stores)

Sistemi di questo tipo possono essere implementati come strato sopra un DBrelazionale o a oggetti. I dati non sono memorizzati piu in tabelle con campiuniformi per ogni record come nei database relazionali, ma ogni record e salva-to come documento. Quest’ultimo possiede determinate caratteristiche e gli sipossono aggiungere un qualsiasi numero di campi con qualsiasi lunghezza senzail bisogno di doversi preoccupare di inserire valori di default.I documenti possono essere messi in relazione tra loro con dei riferimenti, e ciorende questa tipologia di database NoSQL particolarmente adatta a rappresen-tare delle gerarchie e alla programmazione Object Oriented (OO Programming).Gli oggetti infatti possono essere serializzati in un documento eliminando ilproblema dell’impedance mismatching3. Spesso sono presenti delle API o unospecifico linguaggio di interrogazione (query), per realizzare il recupero delleinformazioni sulla base del contenuto, esempio il valore di uno specifico campo.Il fine ultimo di questa tipologia di database non e quello di garantire un’altaconcorrenza, ma quello di permettere la memorizzazione di grandi quantita didati e di fornire un sistema di interrogazione sui dati performante. MongoDB

3impedance mismatching: Con il termine impedance mismatch ci si riferisce ad un insiemedi problematiche concettuali e tecniche che si incontrano quando si vuole far dialogare unRDBMS, basato su un modello relazionale cioe un modello matematico con un programmascritto con un linguaggio di programmazione orientato agli oggetti


rappresenta il principale prodotto di questa serie e, secondo le stime, e uno deidatabase NoSQL piu diffusi al mondo. Altri database NoSQL sono: ApacheCouchDB, ApacheCassandra, Couchbase Server, Clusterpoint.Un altro grandevantaggio risulta quello di poter esprimere i dati attraverso il formato JSON. IlJSON (Javascript Object Notation) e un formato utilizzato per l’interscambiodi dati fra applicazioni client-server.Di seguito riportiamo un esempio di JSON:

Figura 1.3: Esempio database a documento

1.4.3 Archivi a colonne (Column oriented)

Le colonne che costituiscono una column-family non devono essere definite apriori. Ogni record potra avere informazioni differenti all’interno e le colonnevuote, per le quali non si ha alcun valore, non saranno presenti all’interno diuna column-family.Sono database che immagazzinano dati in sezioni di colonne a differenza deiRDBMS che utilizzano le righe. Uno dei piu grandi vantaggi e quello di poteraggiungere colonne senza il bisogno di doversi preoccupare di inserire valori didefault; questo giova alla fessibilita del modello permettendo di prepararsi perscenari futuri.Il punto di forza dei database colonnari riguarda l’immagazzinamento dei da-ti. Offrono un elevato grado di compressione dei dati e non sprecano spazioper campi vuoti. Utili con serie di dati storici o dati provenienti da piu fonti(sensori, dispositivi mobile e siti web), quindi spesso differenti tra loro, e conelevata velocita. Indicati per per sistemi di datawarehousing e read/only repor-ting, principalmente OLAP (On Line Analytical Processing), infatti sono adattiall’uso di tecniche software per l’analisi interattiva e veloce di grandi quantitadi dati.Tali strutture sono molto utilizzate nel campo dei Big Data in quantoforniscono un modello organizzato e essibile. In particolare soluzioni di questotipo sono state adottate da Facebook, Google ed Amazon. Alcuni esempi diquesto modello sono: Apache Cassandra, Hypertable, HBase, Google Datasto-re.


Forniamo un piccolo esempio per far capire come opera un database columnoriented: consideriamo la seguente tabella:

Matricola Nome CognomeN46755 Stefano SilvestriN46877 Sergio ZavotaN46933 Marco Onzo

In un database RDBMS (row-based) i valori sarebbero memorizzati in que-sto modo:N4655 , Stefano , SilvestriN46877 , Sergio , ZavotaN46933 , Marco , OnzoUn database orientato alle colonne, invece, serializza tutti i valori di una colon-na assieme, poi serializza i valori della seconda colonna e cosı via. Allora in undatabase di questo tipo i dati apparirebbero cosı:N4655 , N46877 , N46933Stefano , Sergio , MarcoSilvestri , Zavota , Onzo

1.4.4 Archivi a grafo (Graph Database)

Nascono dall’esigenza di dover gestire dati fortemente connessi tra loro (specienon tabulari), in cui il concetto di relazione tra i dati ha un elevato potenzialeinformativo.Occupano meno spazio rispetto al volume di dati con cui sono fatti e memoriz-zano molte informazioni sulla relazione tra i dati. Questi DB si prestano moltobene alla rappresentazione di dati semistrutturati e interconnessi come pagineWeb, hiperlink e Social Network. Non esiste il concetto di relazione, cio compor-ta una maggiore complessita nelle interrogazioni e negli aggiornamenti. I GraphDB sono ottimizzati alla rappresentazione e alla navigazione efficiente dei dati,infatti non hanno uno schema rigido, si adattano molto bene a cambiamentinelle strutture dei dati e svolgono facilmente operazioni sui collegamenti.Tra idatabase di questo tipo ricordiamo: Neo4J, AllegroGraph, InfiniteGraph, Gira-ph, OrientDB, Virtuoso, Stardog.


Figura 1.4: Esempio database a grafo

In figura 1.5 possiamo rapidamente confrontare i modelli appena descrittisulla base di alcune caratteristiche.

Figura 1.5: Contronto tra database


1.5 Teorema CAP

Un’altra motivazione della diffusione dei sistemi NoSQL e anche spiegato dalteorema CAP. Inizialmente nato come congettura esposta all’Universita del-la California dallo scienziato informatico Eric Brewer (figura molto nota nelcampo dell’IT ed attualmente professore di ruolo all’universita di Berkeley inCalifornia), nel 2002, grazie alla dimostrazione fornita da Seth Gilbert e NancyLynch del MIT, ha assunto il rango di teorema, il quale afferma che qualsiasisistema informatico non puo fornire contemporaneamente questi 3 aspetti, masolo 2 su 3 :

• Consistenza (Consistency): se viene scritto un dato in un nodo e vie-ne letto da un altro nodo in un sistema distribuito, il sistema ritornera l’ultimovalore scritto (quello consistente).

• Disponibilita (Availability) : Ogni nodo di un sistema distribuito devesempre rispondere ad una query a meno che non sia indisponibile.

• Tolleranza di partizione (Partition-Tolerance) : e la capacita di unsistema di essere tollerante ad una aggiunta o una rimozione di un nodo nelsistema distribuito (partizionamento) o alla perdita di messaggi sulla rete.

teorema.png

Figura 1.6: Teorema CAP

Il teorema CAP ci fa capire anche un altro aspetto molto importante che staportando ad un uso e uno sviluppo sempre maggiore dei database non rela-zionali, infatti i sistemi NoSQL basandosi sul modello concettuale BASE (cheaffronteremo a breve) prediligono la disponibilita e tolleranza a discapito invecedella consistenza a differenza dei RDBMS che con il modello ACID garantiscetolleranza e consistenza a discapito della disponibilita.


1.5.1 Il modello BASE

Siamo in grado di analizzare gli aspetti piu significativi dei database NoSQLidentificando un modello in cui si identificano, come l’ACID per i database re-lazionali. Questo grazie, ancora una volta, ad Eric Brewer che ha trasformatole regole ACID in regole BASE:• Alta disponibilita (Basic Availability) : per ogni request e assicuratauna response che puo indicare la buona riuscita o il fallimento dell’esecuzione.• Stato dinamico (Soft State) : stato del sistema puo essere modificato piuvolte, anche senza input.• Consistenza eventuale (Eventual consistency) : L’eventual consistencyquindi non e una garanzia di consistenza ma solo una caratteristica del sistemadi integrazione, non promette una istantanea e complessiva consistenza dei datidistribuiti ma solo una tendenza delle basi dati ad allinearsi, senza pero potergarantire l’istante in cui cio accadra.

Spesso il modello ACID e quello BASE vengono messi in cotrapposizionee si cerca di capire quale sia il migliore, in realta possiedono entrambi grandivantaggi, ma anche qualche svantaggio:

Figura 1.7: ACID vs BASE

Una base di dati che sfrutta il teorema BASE assicura la disponibilita manon concede garanzia di consistenza a tempo di scrittura. Oltretutto, il modelloBASE fornisce meno garanzia dell’ACID: i dati saranno consistenti nel futuro odirettamente a tempo di lettura.Siccome il modello BASE garantisce poca consistenza, una scelta di questo tiporicade sulle spalle degli sviluppatori che dovranno lavorare molto accuratamentesulla consistenza dei dati con cui lavorano.


ACID consente di lavorare in un ambiente sicuro garantendo alla fine di ognitransazione che i suoi dati si trovino in uno stato consistente e al sicuro sul disco.La scrittura consistente puo essere una grande vantaggio per gli sviluppatori maessa ha bisogno di meccanismi di locking che tipicamente implicano un patternmolto pesante per molti dei casi d’uso.

Il modello ACID risulta quindi perfetto nelle applicazioni che richiedonoaffidabilita e coerenza dei dati immessi al contrario del modello BASE chegarantisce scaling elevato e disponibilita immediata.

1.6 Ambiti in cui non si usa il database NoSQL

NoSQL non e sicuramente il paradigma che si utilizza in ogni applicazione comeabbiamo gia visto non bisogna credere che abbia solo aspetti positivi; non e dun-que la soluzione a tutti i problemi che possono incorrere utilizzando RDBMS.Il paradigma NoSQL pecca nel momento in cui il nostro dominio di interesseha bisogno di transazioni sicure e affidabili (ambito finanziario), in cui istanta-neamente dobbiamo avere la certezza di lavorare con dati consistenti; non e unmodello che si basa sull’affidabilita e sull’integrita dei dati. Non e un model-lo utile quando il dominio di interesse non intende espandersi e soprattutto esconsigliabile utilizzarlo se si lavora con dati facilmente normalizzabili cioe conapplicazioni che fanno uso di dati predefiniti, che riescano quindi a rispettare ivincoli imposti da una tabella RDBMS. Quindi riassumendo possiamo dire chegli ambiti in cui e preferibile non usare il database NoSQL sono:• Ambito economico-finanziario• In ambienti che non si devono espandere• Quando utilizziamo dati normalizzabili

Mettiamo una tabella riassuntiva che spiega sinsteticamente le differenze trai due sistemi:

Capitolo 2

Il database OrientDB

Figura 2.1: Logo Orientdb

OrientDB e il primo sistema di gestione di database NoSQL, open sour-ce, multi-modello che combina la potenza dei grafici con modelli di documenti,chiavi / valori, reattivi, orientati agli oggetti in un unico database operativoscalabile e ad alte prestazioni.Nasce in Italia (attraverso Orient Technologies) nel 2004, oggi l’ultima versionedisponibile e la 3.0.12 GA Community Edition, rilasciata il 10 Dicembre 2018.Come risposta diretta alla domanda di mercato sono emersi database multi-modello per soddisfare la necessita di piu modelli di dati, combinandoli perridurre la complessita operativa e mantenere la coerenza dei dati. Siccome laJVM e l’unico requisito per utilizzare un server OrientDB, tale sistema puo es-sere installato su ogni macchina che supporti la piattaforma JAVA.OrientDB e stato progettato da zero per soddisfare le esigenze degli sviluppatorimoderni di prestazioni elevate. A tal fine, e veloce sia nelle operazioni di letturache di scrittura:

• Memorizza fino a 120.000 record al secondo.• Le relazioni sono collegamenti fisici ai record; non c’e bisogno di join.• La soluzione all-in-one garantisce un migliore utilizzo della RAM.

16

CAPITOLO 2. IL DATABASE ORIENTDB 17

• Attraversa parti di interi alberi e grafici di record in millisecondi.• La velocita non e influenzata dalle dimensioni del database; grandi set di datisono facilmente accomodabili.

La maggior parte dei DBMS NoSQL sono utilizzati come database secon-dari. OrientDB, d’altra parte, e abbastanza potente e flessibile da poter essereutilizzato come DBMS operativo.

Le funzionalita principali di OrientDB:

• Supporto alla customizzazione del linguaggio (per scrivere funzioni Java.personalizzate).• Supporto alle JOIN e alle proprieta ACID.• Console per amministrare tramite linea di comando.• Supporta le query-sql.• Supporta alcune modalita di storage: document, graph, key/value.• Funzionamento embedded, in memory, client/server.• Supporto delle JSON.• Console web-based per amministrare tramite interfaccia grafica: OrientDB-Studio.• Libreria API per java.

2.1 Struttura di Orientdb

Orientdb non ha una struttura ben precisa, e infatti considerato un modelloibrido che include diverse funzionalita tipiche dei sistemi NoSQL.Alla base dei suoi vari modelli, si colloca l’Object Model, incentrato sullaprogrammazione ad oggetti, che consente di creare classi e supportando ancheereditarieta e polimorfismo.Il Document Model costituisce invece l’anima a documenti di OrientDB. Cipermette di raccogliere i documenti in strutture molto flessibili (le collezioni), etali oggetti saranno legati tra loro da link.Il Graph Model simboleggia uno degli aspetti principali di OrientDB: riuniredocumenti in nodi collegati tra loro da relazioni.Il Key/Value Model e la parte che consente di utilizzare OrientDB in modopiu semplice concettualmente: gli oggetti saranno immagazzinati in struttureindicizzate tramite chiavi. A differenza di quanto avviene in altri gestori didatabase, OrientDB e realmente Multi-Model, nel senso che i vari approcci ap-pena descritti non sono solo delle interfacce offerte dal sistema, ma quattro verimodelli di gestione dei dati di cui il motore del DBMS e stato dotato.In OrientDB i cluster1 sono le strutture principali utilizzate per organizzare idati, i quali possono non avere uno schema.Ci sono due tipi di clusters: physicale in-memory. Il primo e persistente, il secondo volatile, ovvero viene distrutto

1cluster : (dall’inglese grappolo), e un insieme di computer connessi tra loro tramite unarete telematica che lavorano in parallelo.


quando il server va in shutdown. Per ogni clusters OrientDB crea uno o piu file.Dato che Orientdb si basa sulla programmazione ad oggetti, le classi occupanoun ruolo centrale in questo sistema, esse si dividono in :• Schema-less (non sono definiti vincoli).• Schema-full (vincoli obbligatori)• Mixed-mode.

Quando andiamo a creare una classe, OrientDB la definisce come schema-less. Questo determina che ogni record appartenente ad una determinata classepuo avere un tipo di dato diverso da un altro record della stessa classe, e pos-sono esserci anche due record identici ma che hanno dei tipi di dati diversi.Glischemi senza vincoli sono utilizzati in casi in cui non si sa gia a prescindere qualidati verranno inseriti. Chiaramente come abbiamo gia visto Oriebtdb supportaanche degli schemi definiti con vincoli, e quindi quelle classi accetteranno solodei particolari tipi di dati.I tipi che possiamo trovare in Orientdb li possiamo dividere in semplici o con-tainers:• Tra i tipi semplici ricordiamo: binary, boolean, byte, date, double, integer,float ecc.• Tra i tipi containers ricordiamo: linklist, linkset, linkmap, embeddedlist,embeddedset,embeddedmap.

2.1.1 Classi astratte

Come nel paradigma OOP e presente il concetto di classe astratta. Sono utiliper definire le proprieta che ogni classe derivata dovra 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.

2.1.3 Regole

Le regole definiscono i criteri di sicurezza applicati a risorse specifiche. Una re-gola allora e l’insieme di una risorsa e dell’operazione applicabile a quella risorsastessa.

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 (puu leggere, creare, ag-


giornare e cancellare records), reader (puu solo leggere). E’ comunque possibilecreare nuovi utenti e anche ruoli personalizzati.

2.1.5 Utenti

Ogni utente deve avere una password e almeno un ruolo. I ruoli associati all’u-tente definiscono i diritti che ha l’utente per operare sul database. Di defaultogni nuovo database ha tre utenti, associati ai tre ruoli dichiarati precedente-mente (admin, writer e reader).

Figura 2.2: Sicurezza in Orientdb

2.2 Esempio Applicativo

L’ultima sezione di questo elaborato sara dedicata ad un esempio pratico conl’utilizzo di Orientdb su piattaforma windows.

Orientdb infatti fornisce un database predefinito chiamato temp.


2.2.1 Creazione della base di dati

Nell’esempio applicativo faremo una piccola base di dati che gestista un ramodella FedericoII.Vogliamo gestire le interconnessioni e le relazioni che si instaurano tra studente,Corso e docente.

Figura 2.3: Creazione

Come possiamo vedere abbiamo delle relazioni molti a molti tra studentee corso poiche lo studente puo seguire piu corsi e i corsi possono essere seguitida piu studenti e una relazione di uno a molti tra corso e docente poiche eper una scelta progettuale abbiamo deciso che un docente puo avere un soloinsegnamento invece il corso puo avere piu docenti.

Allora come primo passo andiamo a creare un database dove andremo alavorare, per crearlo utilizziamo i seguenti comandi:

Figura 2.4: Creazione

A questo punto andiamo a connetterci al database:

Figura 2.5: Connessione

Nella figura 2.5 ci connettiamo al database chiamato unidb con usernameroot e password root che precedentemente era stata immessa direttamente dalfile XML orientdb-server-config.xml.Fatto cio modifichiamo i permessii di degli utenti writer,reader e admin e lofacciamo nel seguente modo:


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”

Dopo aver modificato i permessi gli utenti che dovranno connettersi al da-tabase Unidb non dovranno ricordarsi particolari password, ma sara nient’altroche il loro username ripetuto.Creiamo le classi che ci serviranno nel nostro esempio:orientdb > create class Studenteorientdb > create class Corsoorientdb > create class Docente

Figura 2.6: Creazione classi

2.2.2 Primo aspetto: classi schema-less

Le classi di un sistema NoSQL inizialmente non hanno uno schema defini-to,quindi vi si puo inserire qualsiasi valore. Per capire bene questo concettoandiamo a popolare una delle 3 classi.

Figura 2.7: Popolazione classe Studenti

Come possiamo vedere nella figura (2.7) non abbiamo progettato alcunastrutturazione dei dati, come sarebbe avvenuto nei database relazionali. Piut-


tosto abbiamo definito un’entita logica, una classe, senza neanche definirne leproprieta. La sua definizione ha automaticamente prodotto un nuovo cluster;i record inseriti hanno tutti strutture interne diverse. Immettendo dei campidiversi per ogni record, il sistema automaticamente andra ad inserire valori nullinei record in cui non c’era un determinato attributo. Ogni record ha un nume-ro progressivo che, congiuntamente all’identificativo del cluster, contribuisce aformare il RID, vero elemento di riconoscimento univoco del record.Nella figura 2.8 possiamo vedere il risultato dell’operazione di SELECT sullatabella Studente e nella 2.9 come possiamo aumentare le prestazioni in terminidi velocita della query andando a fare le opportune operazioni proprio sul RID.

Figura 2.8: Select su Studente

Figura 2.9: Confronto tra query

2.2.3 Secondo aspetto: Non ci sono vincoli

Prima di proseguire abbiamo popolato anche le altre tabelle. Adesso vediamoun altro aspetto molto importante di Orientdb, infatti in questi sistemi non cisono vincoli da rispettare come succede nei database relazionali. Mostriamo latabella di Corso:


Osserviamo nella foto sottostante come l’inserimento di una stringa ove do-vrebbe esserci un intero non causa alcun errore. Questa e una delle potenzialitapiu ricercate in quegli ambienti in cui si deve operare con dati eterogenei perche,appunto, ci consente di operare con qualsiasi dato senza la necessita di dovercioccupare dei vincoli.

2.2.4 Terzo aspetto: campo embedded

OrientDB fornisce la possibilita di utilizzare un campo di tipo document-embedded.Attraverso questo tipo possiamo associare a qualsiasi campo una stringa JSON.


Andiamo ad inserire un nuovo Docente non considerando i campi nome ecognome ma andando ad inserire un campo embedded che ne specifichi la dataed il luogo di nascita.

Inoltre su questi nuovi records possiamo tranquillamente eseguire delle queryperche anche loro sono dotati di un RID come possiamo vedere in figura 2.10:

Figura 2.10: Query su campo embedded

2.2.5 Quarto aspetto: i campi containers

I containers sono dei campi speciali che possono contenere un insieme di altricampi.Ricordiamo 3 tipi di containers:• 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 sono strin-ghe e i valori possono essere qualsiasi tipo consentito, anche altri containers.Inseriamo un docente di cui specifichiamo solo il campo container:


Figura 2.11: Insert su campo container

2.2.6 Analogie con schemi relazionali: i vincoli

Fino ad ora abbiamo fatto degli esempi pratici con i sistemi schema-less,macome gia abbiamo detto in precedenza Orientdb offre anche altri aspetti e adesempio possiamo creare dei vincoli nello schema. Possiamo allora dichiarare seuna 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:

orientdb > create property Corso.annoFondazione date

Ora cerchiamo di inserire l’anno di fondazione come stringa e non come data,a questo punto se il vincolo e stato creto con successo il sistema ci dara un errore:

Figura 2.12: Errore dovuto al vincolo

In figura 2.12 possiamo osservare comevenga alzata un’eccezione causata dalfatto che si e tentato di convertire il valore Duemila in una data che, invece, haun formato del tipo yyyy-MM-dd.

Un altro vincolo molto importante fornito da OrientDB e il comando STRICT-MODE che,se attivato, evita che un utente possa con un’operazione di INSERTaggiungere campi precedentemente non dichiarati. Abbiamo gia visto (fig 2.8)che potevamo aggiungere campi senza che ci fosse un messaggio di errore, orainvece andiamo ad attivare questa modalita e vediamo gli sviluppi.

2.2.7 Analogie con schemi relazionali: Relazioni tra classi

In OrientDB esiste il concetto di relazione, analogamente agli schemi relaziona-li, pero questo concetto assume sfumature diverse. Innanzitutto quando si creauna relazione in OrientDB, si crea una connessione fisica tra i documenti.


Figura 2.13: STRICTMODE attivata

Questo comporta che un’ operazione di JOIN che debba recuperare un docu-mento non abbia costo computazionale. Per questo motivo OrientDB risultamolto veloce quando si maneggiano milioni di records correlati tra loro. Le re-lazioni 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 tra docu-menti che hanno un ciclo di vita dipendente.Le associazioni molti a molti e uno a molti del nostro esempio possono esserecreate tramite un campo di tipo LINK che, accettando valori di tipo RID, creaun collegamento fisico tra i documenti.

Nel nostro esempio sappiamo dal modello ER che ad ogni corso e associatouno o piu docenti, invece ad ogni corso e associato solo un docente. Facciamoin modo che da ogni docente sia possibile risalire al corso,per fare questo utiliz-ziamo:

orientdb > create property Docente.corso link Corso.

Figura 2.14: Creazione collegamento tra le due classi

Vediamo come la classe Docente e stata modificata, infatti in figura 2.14 ve-diamo un altro campo chiamato corso, collegato (LINKED) alla classe Corso.Daquesto momento in poi andiamo ad inserire dei collegamenti tra le due classi inquesto modo:


Figura 2.15: Inserimento

Vediamo come i collegamenti li possiamo fare tramite i RID, inoltre in figura2.15 vediamo quindi come il Docente Nicola Romano sia collegato al corso conRID=25:0 che rappresenta il corso di Basi di Dati. Dopo aver associato ad ognidocente un corso, facciamo lo stesso procedimento per l’altra associazione. Allafine avremo questo risultato:

Figura 2.16: Select su Docente

L’ultimo aspetto che andiamo a vedere e il comando TRAVERSE, un’opzionemolto potente, di frequente utilizzato nei document database. Viene utilizzatospesso perche, assegnata una tabella, fornisce tutti i records collegati ad essaevitando di stampare due records identici. Risulta molto simile all’operatoreJOIN dei database relazionali.


Figura 2.17: Traverse

Conclusioni

In questo elaborato abbiamo visto gli aspetti piu significativi dei database No-SQL.Abbiamo cercato di mettere in evidenza che i database NoSQL, in alcuni ambiti,possono essere una valida alternativa ai database relazionali o addirittura i duesistemi possono coesistere per un servizio migliore.

Nella prima parte e stata fatta una breve introduzione dei database relazionali,siamo passati alle cause per la quale si e ricercata una soluzione alternativa ede stato fatto un breve discorso su tutti i modelli di database non relazionali.Abbiamo analizzato le sostanziali differenze tra i DB relazionali e i NoSQL, conle modifiche delle proprieta ACID in proprieta BASE e il teorema CAP.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.

Nella seconda parte e stato fatto un discorso piu approfondito su un particolaredatabase NoSQL: OrientDB, dalla nascita di questo sistema fino allo sviluppo,i vantaggi che offre, tutte le funzionalita principali e la struttura in generale.Infine abbiamo fatto un piccolo esempio pratico che ci ha permesso di mostrarealcuni dei vari aspetti positivi di tali database come la flessibilita sugli schemi,l’introduzione di campi particolari come gli embedded-document e la capacita dipoter lavorare con dati non strutturati i quali sono aspetti peculiari che hannoreso possibile lo svlippo e il largo uso di questi sistemi nel mondo lavorativo.

29

Bibliografia

[1] Wikipedia, NoSQL, https://it.wikipedia.org/wiki/NoSQL

[2] Wikipedia, OrientDB, https://en.wikipedia.org/wiki/OrientDB

[3] A.Chianese, V.Moscato, A.Picariello, L.Sansone, Basi di dati per lagestione dell’informazione McGraw-Hill, Milano, 2010.

[4] C.Tesoriero, Getting Started with OrientDB Pack Publishing, Birmin-gham, 2013.

[5] Guida OrientDB , http://www.html.it/guide/guida-orientdb

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

[7] Dati non relazionali e NoSQL https://docs.microsoft.com/it-it/

azure/architecture/data-guide/big-data/non-relational-data

[8] Cos’e NoSQL? https://aws.amazon.com/it/nosql/

[9] Da SQL a NoSQL https : / / www . isaacbigdata . com / it /

da-database-oracle-a-database-nosql/

[10] I database NoSQL http://databasemaster.it/database-nosql/

[11] NoSQL http : / / www . strozzi . it / cgi-bin / CSA / tw7 / I / en _ US /

nosql/Home%20Page

[12] Database NoSQL https : / / www . oracle . com / technetwork /

database / database-technologies / nosqldb / learnmore /

nosql-database-data-sheet-498054.pdf

30

Ringraziamenti

Alla fine dell’elaborato vorrei fare dei ringraziamenti a tutte le persone che mihanno aiutato e supportato in questo periodo.

Innanzitutto voglio ringraziare i miei genitori, cui devo tutto. Mi hannoinsegnato lo spirito di sacrificio, mi hanno sempre spronato e aiutato nei mo-menti di difficolta, hanno sempre creduto in me e spero che questo mio primotraguardo sia una piccola soddisfazione per loro.

Ringrazio Leonardo, mio fratello, che si e sempre interessato alla mia car-riera universitaria e per me e stato un grande esempio di correttezza, lealta ededizione.

Ringrazio Chiara che ha subito tutte le mie lamentele, le mie crisi istericheed ha avuto sempre una parola di conforto. Sempre pronta ad ascoltarmi met-tendo da parte le sue cose, e stata una persona fondamentale nel mio percorso.

Ringrazio Sergio che oltre ad essere mio coinquilino e diventato un sinceroamico, sempre presente e pronto ad aiutarmi in ambito universitario e non. Ungrazie particolare anche a Giovanni per tutti i consigli che mi ha dato, ma ancheper il suo lato comico e divertente che ha fatto passare le giornate piu veloce-mente.

Ringrazio Antonio e Valentina che nel primo anno lontano da casa mi hannoaiutato ad ambientarmi a Napoli e che sono state delle persone molto importantinel mio persorso di crescita.

Ringrazio Zaffy, Christian, Sdadino, Elio, Tomacelli, Andrea e Achille cheoltre ad essere dei validissimi colleghi si son mostrati dei grandi amici.

Infine un grazie particolare va a casa Ciab, ringrazio Lorena, il ”collega”Stefano, Ilaria e gli altri per tutte le giornate passate insieme a ridere, scherzare,divertirci e ogni tanto anche a studiare.

31

Data Base NoSQL multi -modello:OrientDB · INDICE 4 Il tratto caratteristico dei database NoSQL e...

Documents

Transcript of Data Base NoSQL multi -modello:OrientDB · INDICE 4 Il tratto caratteristico dei database NoSQL e...