Valutazione sperimentale di tecnologie per la gestione dei dati per workflow scientifici

UNIVERSITA’ DEGLI STUDI DI TRIESTEDIPARTIMENTO DI MATEMATICA E INFORMATICA

Corso di laurea magistrale in Informatica

TESI DI LAUREA

Valutazione sperimentale di tecnologie per la

gestione dei dati per workflow scientifici

Relatore Laureando

Prof. Eric Medvet Francesco De Giorgi

Correlatore

Dott. Paolo Vercesi

Indice

Introduzione 4

1 Scenario 71.1 I workflow di simulazione . . . . . . . . . . . . . . . . . . . . 71.2 Caratteristiche dei dati trattati . . . . . . . . . . . . . . . . . 81.3 Ottimizzazione multiobiettivo . . . . . . . . . . . . . . . . . . 81.4 Casi d’uso . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10

1.4.1 Ottimizzazione di traiettoria . . . . . . . . . . . . . . 10

2 Analisi della problematica 132.1 Gestione dei dati . . . . . . . . . . . . . . . . . . . . . . . . . 132.2 Problematiche nella gestione di dati . . . . . . . . . . . . . . 142.3 Ipotesi di soluzione . . . . . . . . . . . . . . . . . . . . . . . . 162.4 Related works . . . . . . . . . . . . . . . . . . . . . . . . . . . 16

3 Le tecnologie NoSQL 183.1 Definizione . . . . . . . . . . . . . . . . . . . . . . . . . . . . 183.2 Limitazioni del modello relazionale . . . . . . . . . . . . . . . 18

3.2.1 Da ACID a BASE . . . . . . . . . . . . . . . . . . . . 193.2.2 Scalabilita del modello relazionale . . . . . . . . . . . 193.2.3 Scalabilita verticale . . . . . . . . . . . . . . . . . . . 20

3.3 Caratteristiche dell’approccio non relazionale . . . . . . . . . 213.3.1 Scalabilita orizzontale . . . . . . . . . . . . . . . . . . 213.3.2 Mappature tra oggetti e relazioni . . . . . . . . . . . . 223.3.3 Prestazioni ma non a�dabilita . . . . . . . . . . . . . 22

3.4 Modelli di dati . . . . . . . . . . . . . . . . . . . . . . . . . . 223.4.1 Orientati alle colonne . . . . . . . . . . . . . . . . . . 223.4.2 Chiave/valore . . . . . . . . . . . . . . . . . . . . . . . 233.4.3 Orientati ai documenti . . . . . . . . . . . . . . . . . . 23

3.5 Orientarsi nella scelta . . . . . . . . . . . . . . . . . . . . . . 23

4 Sperimentazione 254.1 Obiettivo della sperimentazione . . . . . . . . . . . . . . . . . 254.2 Strumento di sperimentazione . . . . . . . . . . . . . . . . . . 264.3 Individuare i candidati . . . . . . . . . . . . . . . . . . . . . . 26

4.3.1 OrientDB . . . . . . . . . . . . . . . . . . . . . . . . . 284.3.2 MongoDB . . . . . . . . . . . . . . . . . . . . . . . . . 294.3.3 Cassandra . . . . . . . . . . . . . . . . . . . . . . . . . 31

4.4 Implementazione . . . . . . . . . . . . . . . . . . . . . . . . . 324.4.1 Pianificazione . . . . . . . . . . . . . . . . . . . . . . . 324.4.2 Strumenti hardware . . . . . . . . . . . . . . . . . . . 344.4.3 Strumenti software . . . . . . . . . . . . . . . . . . . . 34

1

4.4.4 Interconnessione . . . . . . . . . . . . . . . . . . . . . 354.5 Struttura dei test . . . . . . . . . . . . . . . . . . . . . . . . . 354.6 Significato dei test . . . . . . . . . . . . . . . . . . . . . . . . 384.7 Metodologia . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39

4.7.1 Rilevazione dei risultati . . . . . . . . . . . . . . . . . 40

5 Analisi dei risultati 415.1 Dati sperimentali . . . . . . . . . . . . . . . . . . . . . . . . . 41

5.1.1 Inserimento . . . . . . . . . . . . . . . . . . . . . . . . 425.1.2 Lettura . . . . . . . . . . . . . . . . . . . . . . . . . . 445.1.3 Lettura con selezione . . . . . . . . . . . . . . . . . . . 465.1.4 Mappatura dei campi delle entita . . . . . . . . . . . . 48

5.2 Analisi riassuntiva dei risultati . . . . . . . . . . . . . . . . . 50

Conclusioni 52

Bibliografia 53

Elenco delle figure

1 Il workflow di simulazione e una funzione matematica chericeve in ingresso le variabili decisionali e restituisce in uscitale variabili di risposta. . . . . . . . . . . . . . . . . . . . . . . 7

2 Il workflow di simulazione e una funzione matematica chericeve in ingresso le variabili decisionali e restituisce in uscitale variabili di risposta. . . . . . . . . . . . . . . . . . . . . . . 10

3 Traiettoria ottimizzata del boomerang. . . . . . . . . . . . . . 114 Rappresentazione del workflow principale. . . . . . . . . . . . 125 Classificazione database non relazionali, secondo caratteristi-

che di persistenza diverse. Sono presentati database che me-morizzano dati su disco o in memoria, collocati rispetto al-le caratteristiche di ridondanza e localita dei dati (databasedistribuito su piu nodi - database non distribuito). . . . . . . 24

6 Le caratteristiche principali dei tre candidati server NoSQL.CRUD e abbreviazione per Create, Read, Delete, Update,cioe le operazioni di creazione, lettura, cancellazione, aggior-namento. OM e abbreviazione per Object Mapping, cioemappatura di oggetto. . . . . . . . . . . . . . . . . . . . . . . 27

7 Proposta di mappatura tra query SQL nel RDBMS MySQL elinea di comando JavaScript utilizzata nell’interrogazione inMongoDB. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30

8 Sistema di visualizzazione dei risultati. . . . . . . . . . . . . . 33

2

9 Rappresentazione informale della procedura di sperimentazio-ne e misurazione implementata. In grigio sono rappresentatiblocchi sviluppati per il lavoro di tesi, in giallo parti softwaregia disponibili, API native del server NoSQL o librerie di terzeparti. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39

10 Metodologia di rilevazione dei risultati. . . . . . . . . . . . . . 4011 Inserimento nel database di SimpleBean. . . . . . . . . . . . . 4212 Inserimento nel database di CompositeBean. . . . . . . . . . 4313 Inserimento nel database di MapBean. . . . . . . . . . . . . . 4314 Lettura di SimpleBean. . . . . . . . . . . . . . . . . . . . . . 4415 Lettura di CompositeBean. . . . . . . . . . . . . . . . . . . . 4516 Lettura di MapBean. . . . . . . . . . . . . . . . . . . . . . . . 4517 Lettura di SimpleBean con selezione della popolazione. . . . . 4718 Facilita di mappatura delle entitita considerate per i tre server

NoSQL. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48

3

Introduzione

L’argomento di questo lavoro di tesi e la gestione dei dati generati in work-flow scientifici. In particolare si a↵rontano le problematiche connesse allascelta dello strato di persistenza dove vengono memorizzati dati prodotti daprogetti di simulazione.

Lo scenario preso in considerazione e stato proposto da Esteco S.p.A.,societa insediata presso AREA Science Park, Padriciano, Trieste, dove estata svolta la tesi. I sistemi software che Esteco o↵re sul mercato consen-tono l’ottimizzazione multiobiettivo tramite workflow di simulazione, cioel’esecuzione di un processo automatico che minimizzi o massimizzi una seriedi funzioni obiettivo sulle quali sono stati posti dei vincoli. Tale approcciotrova applicazioni in campo industriale e in numerose discipline di tipo in-gegneristico [9].

Gli strumenti di simulazione usati da Esteco e dai suoi clienti comporta-no la produzione e l’utilizzo di dati la cui persistenza deve essere garantita,con l’obiettivo di interrogare i dati stessi in un tempo diverso da quello disimulazione. Attualmente la memorizzazione dei dati di progetto avviene at-traverso basi di dati relazionale e metodi proprietari non basati su standard.

In base all’esperienza di Esteco la gestione della base di dati tramiteRDBMS (Relational Data Base Management System) risulta non soddisfa-cente per quanto concerne:

• la mappatura di oggetti software da strato applicativo a strato dipersistenza;

• la memorizzazione di tipi di dati eterogenei (file binari, CAD, video,ecc.);

• la memorizzazione di dati scarsamente strutturati o non strutturati;

• l’impossibilita di definire a priori uno schema fisso, poiche non e notaa priori la struttura dei dati.

Ipotesi della tesi e che, in riferimento all’ambito sopra descritto, il mo-dello relazionale non sia il migliore possibile.

Obiettivo del lavoro e quindi verificare le alternative ai RDBMS utilizzatiper gestire la persistenza dei dati provenienti dalle simulazioni. In partico-lare sono stati sottoposti a indagine i database definiti NoSQL (Not OnlyStructured Query Language), che si basano generalmente su un modello didati non relazionale.

4

Oggetto dell’indagine e stata la gestione della persistenza e l’interroga-zione di entita software su tali database non relazionali. I termini utilizzatiper verificare la qualita di un database non relazionale sono stati:

• il tempo di esecuzione necessario a completare le operazioni di inseri-mento, lettura, aggiornamento, cancellazione;

• la possibilita di eseguire mappature definite dall’utente sugli entitasoftware, cioe definire come viene trasferita l’informazione dal livelloapplicativo allo strato di persistenza;

• la possibilita di modificare lo schema di un database a livello applica-tivo.

L’esperimento consta delle seguenti fasi:

• analisi dello scenario di riferimento, della problematica, dello statodell’arte;

• studio di soluzioni alternative per la risoluzione della problematica;

• sperimentazione su architettura client-server di tre candidati serverNoSQL;

• verifica e analisi dei risultati.

Il linguaggio di programmazione utilizzato e Java, che e il linguaggiousato all’interno di Esteco per lo sviluppo delle applicazioni prodotte.

Il risultato atteso e un contributo alla conoscenza di Esteco relativamenteall’argomento delle basi di dati non relazionali. Nel concreto, lo strumentosoftware progettato non costituira un elemento da aggiungere alla produzio-ne attuale dell’azienda, ma o↵rira la possibilita di verificare alternative allagestione di dati di progetto tramite RDBMS.

Il Capitolo 1 dell’elaborato e incentrato sulla descrizione dello scenario.Viene qui a↵rontato il concetto di workflow di simulazione.

Il Capitolo 2 e una analisi delle problematiche di memorizzazione deidati di workflow di simulazione.

Il Capitolo 3 e un’analisi delle caratteristiche principali delle tecnologieNoSQL.

Il Capitolo 4 e dedicato alle motivazioni che supportano la scelta deicandidati server NoSQL selezionati per la sperimentazione.

5

Nel Capitolo 5 viene discusso l’esperimento condotto e i risultati da essoprodotti, grazie all’ausilio di grafici e tabelle.

Chiudono l’elaborato considerazioni generali sul successo dell’esperimen-to e sugli sviluppi futuri.

6

1 Scenario

1.1 I workflow di simulazione

Il problema che l’elaborato di tesi a↵ronta e relativo alla gestione di datinell’ambito di simulazioni nel campo della progettazione assistita al calco-latore (CAE, Computer Aided Engineering).Tali applicazioni sono, in informatica, software che agevolano la risoluzionedi problemi tecnologici tramite il calcolo numerico. Molti problemi dell’in-gegneria sono descrivibili da equazioni che possono essere risolte con l’ausiliodi programmi CAE. Si citano ad esempio le simulazioni analogiche e digitalidi circuiti elettronici e il calcolo statico o dinamico di strutture in ingegneriacivile o meccanica.

In particolare verra discussa e a↵rontata la gestione dei dati di progettoassociati a workflow di simulazione definiti mediante software CAE, doveper progetto si intende un’entita composta come segue:

• un modello matematico del sistema da simulare (workflow di simula-zione, o f);

• variabili decisionali in ingresso (decision variables, o x)

• variabili di risposta (response variables, o y).

Descrizione del problema

Il problema è relativo alla gestione di dati di progetto nell’ambito delle applicazioni CAE

(Computer Aided-Engineering).

Un progetto è composto da:

● un modello matematico del sistema da simulare (workflow di simulazione, o f)● variabili decisionali in ingresso (decision variables, o x)● variabili di risposta (response variables, o y)

Viene inoltre definito design la tupla che contiene i valori delle variabili decisionali e delle

corrispondenti risposte. E’ possibile riferirsi al workflow di simulazione come ad una funzione

f(x)=y con x e y vettori rispettivamente di output e input. Lo studio del modello matematico e delle

sue caratteristiche non è oggetto di trattazione nella tesi.

Oggetto della tesi è lo studio della gestione della persistenza dei dati associati ai workflow di

simulazione, all’interno di un sistema per la gestione del ciclo di vita di tali workflow.

I componenti dei vettori di input e output possono essere di tipi eterogenei:

● primitivi (numeri in virgola mobile, interi, booleani, stringhe, etc.)

● composti (ad esempio un numero complesso con parte reale e immaginaria, dati di

anagrafica, matrici, etc.)

● file e oggetti binari (CAD, JPEG, VIDEO, etc.)

Si noti inoltre che:

● Le relazioni tra ingresso e uscita non sono note a priori, ogni workflow di simulazione è

creato dall’utente e ha un insieme differente di variabili decisionali e di risposta.

● Nuove versioni di uno stesso workflow di simulazione possono portare modifiche alle

relazioni esistenti, o rimozione di variabili.

● La struttura dei dati, analogamente a quelle delle relazioni, può non essere nota a priori.

● Una variabile decisionale può essere vincolata ad assumere valori su un dominio, in base

al suo tipo. Ad esempio giorni della settimana, per una stringa, oppure valori interi

compresi in un intervallo, nel caso di temperature di lavaggio di una lavatrice.

Figura 1: Il workflow di simulazione e una funzione matematica che riceve iningresso le variabili decisionali e restituisce in uscita le variabili di risposta.

Viene inoltre definito design la tupla che contiene i valori delle variabilidecisionali e delle corrispondenti risposte.

Come si evince dalla Figura 1 e possibile riferirsi al workflow di simula-zione come ad una funzione f(x)=y con x e y vettori rispettivamente di inputoutput. Il workflow di simulazione e quindi una funzione di trasferimento

7

che opera sui valori delle variabili in ingresso, cioe sullo spazio decisiona-le da esplorare, per ottenere i valori calcolati delle variabili in uscita. Lostudio del modello matematico e delle sue caratteristiche non e oggetto ditrattazione nella tesi.

1.2 Caratteristiche dei dati trattati

In riferimento ai dati di progetto discussi nella sezione precedente, i compo-nenti dei vettori di input e output possono essere di tipi eterogenei:

• primitivi: numeri in virgola mobile (x e y), interi, booleani, stringhe,etc.;

• composti: ad esempio un numero complesso con parte reale e imma-ginaria, dati di anagrafica, matrici;

• file e oggetti binari: CAD, immagini, video, etc..


La struttura dei dati, analogamente a quelle delle relazioni, puo non es-sere nota a priori.

Le relazioni tra ingresso e uscita non sono note a priori, ogni workflow disimulazione e creato dall’utente e ha un insieme di↵erente di variabilidecisionali e di risposta.

Nuove versioni di uno stesso workflow di simulazione possono portaremodifiche alle relazioni esistenti, o rimozione di variabili.

Una variabile decisionale puo essere vincolata ad assumere valori su undominio, in base al suo tipo. Ad esempio giorni della settimana, peruna stringa, oppure valori interi compresi in un intervallo, nel caso ditemperature di lavaggio di una lavatrice.

1.3 Ottimizzazione multiobiettivo

All’interno dell’azienda dove e stato svolto il lavoro di tesi, Esteco, vengonosviluppati il software modeFRONTIER e il software SOMO.

modeFRONTIER e un software per l’ottimizzazione multidisciplinare[8] e multiobiettivo che puo essere accoppiato a qualsiasi strumento perl’ingegneria assistita al calcolatore (CAE). SOMO (Service Oriented Mul-tidisciplinary Orchestration) e una piattaforma web che supporta la ge-stione della complessita delle simulazioni multidisciplinari, organizzando edorchestrando dati e workflow di simulazione.

8

Obiettivo comune di entrambi e fornire uno strumento per l’ottimizza-zione multiobiettivo, delineata nei paragrafi successivi.

L’algoritmo che risolve un problema di ottimizzazione multiobiettivo de-ve trovare e comparare le soluzioni ammissibili riferite a obiettivi multipli;allo stesso tempo deve soddisfare i vincoli.

Il fronte di Pareto rappresenta l’insieme delle soluzioni ottime per lequali non esiste nessuna soluzione che sia migliore contemporaneamente pertutti gli obiettivi considerati nella procedura di ottimizzazione. Puo essereconsiderato come un compromesso sulle varie funzioni obiettivo. Tali so-luzioni rappresentano inoltre l’insieme di output atteso da un algoritmo diottimizzazione multiobiettivo.

In molti campi dell’ingegneria si presentano problemi con obiettivi mul-tipli, soggetti a vincoli specifici. I classici metodi di ottimizzazione sonogeneralmente non applicabili a causa della conflittualita degli obiettivi diprogetto: questo classe di problemi e generalmente conosciuta come MDCM(MultiCriteria Decision Making). I problemi MCDM vengono comunementerisolti tramite una procedura di ottimizzazione, che nel caso di due o piuobiettivi in conflitto simultaneamente e soggetti a determinati vincoli vienechiamata Ottimizzazione Multiobiettivo.

Gli algoritmi di ottimizzazione trovano i punti proprio sulla frontiera diPareto. Si noti inoltre che la selezione di un punto del fronte di Pareto,opzione comunemente preferita, richiede un livello di conoscenza maggioredi quello o↵erto dalle funzioni obiettivo. Per operare tale decisione e neces-saria una figura professionale (Decision Maker), il cui operato si inseriscenel processo di decisione come rappresentato in Figura 2, che abbia unacomprensione profonda del problema e che possa esprimere preferenze sullediverse soluzioni.

Il decision maker, il cui contributo e necessario per risolvere un problemaMCDM, e aiutato nella scelta da strumenti di supporto alle decisioni, qualiil Post Processing e il Decision Making.

Nei problemi multiobiettivo non esiste una sola soluzione ottima ma nu-merose soluzioni sul fronte di Pareto. La ricerca di queste soluzioni puoportare all’esplorazione dello spazio del progetto con la generazione di cen-tinaia di migliaia di design. Una situazione analoga si puo presentare conproblemi mono-obiettivo in presenza di numerosi vincoli, per i quali spessonon e possibile trovare neanche un design ammissibile.

9

Figura 2: Il workflow di simulazione e una funzione matematica che riceve iningresso le variabili decisionali e restituisce in uscita le variabili di risposta.

1.4 Casi d’uso

Tra i casi di utilizzo di workflow di simulazione per l’ottimizzazione multio-biettivo possiamo citare:

• l’ottimizzazione di un motore a combustione interna quattro cilindri,alla ricerca dell’ottimo nella riduzione delle emissioni di ossidi di azotoe nel consumo del carburante (obiettivi in conflitto);

• l’ottimizzazione del volume del cordone di saldatura e di quello del-la trave saldata, nella progettazione di una mensola alla quale vieneapplicata una forza all’estremita libera. Problema di ottimizzazionemultiobiettivo che coinvolge nove parametri di input, quattro outpute due funzioni obiettivo;

Viene di seguito approfondito un caso d’uso relativo ad un ottimizzazioneingegneristica condotta grazie al software modeFRONTIER.

1.4.1 Ottimizzazione di traiettoria

Viene simulata la traiettoria di un boomerang [16] per ottimizzarne la forma(Figura 4).

Viene utilizzato un modello dinamico, che permette di calcolare i coe�-cienti aerodinamici del boomerang. Le variabili in questione sono i parametri

10

Figura 3: Traiettoria ottimizzata del boomerang.

di progettazione geometrica per la modifica della forma del boomerang.

Essi sono:

Range : la massima distanza raggiunta dal boomerang durante il volo; econsiderato come un vincolo durante l’ottimizzazione.

Precisione (accuracy), ovvero la di↵erenza tra la posizione di lancio delboomerang e la posizione in cui arriva (questa quantita e ottimizzatadal processo interno per ogni soluzione candidata).

Energia (energy): rappresenta l’energia (traslazionale piu rotazionale) ne-cessaria per lanciare il boomerang, ed e una quantita da minimizzare(per evitare eccessivi sforzi per il lanciatore).

In Figura 4 viene ra�gurato il workflow dell’intero processo. Di seguitosi riporta una descrizione concisa degli elementi principali presenti:

Il riquadro verde in alto rappresenta i nodi che definirono il range divariazione di tutti i parametri. Le linee scure centrali rappresentanoil flusso di processo.

11

Il task CAD model costituisce l’interfaccia al programma di CAD chemodifica il modello al variare dei parametri.

Il modo make mesh crea la griglia su cui rappresentare il modello, perogni geometria proposta.

La mesh cosı generata viene fornita al nodo successivo, che esegue in batchun ulteriore progetto modeFRONTIER.

Il nodo create Matlab crea un file RSM (.mex) ed infine viene invocatoun ultimo nodo modeFRONTIER, sempre in modalita batch (launchparameters tuning), che accetta come input i quattro parametri dilancio.

Figura 4: Rappresentazione del workflow principale.

La geometria del boomerang e stata quindi fissata e l’obiettivo e definitodalla minimizzazione della distanza tra la posizione di arrivo e quella dilancio. Per questo scopo viene utilizzato un algoritmo mono-obiettivo, ed ilprogetto esegue uno script Matlab per ogni configurazione dei parametri dilancio.

12

2 Analisi della problematica

In questo capitolo si a↵ronta l’analisi della problematica delineata nel Ca-pitolo 1. A partire quindi dalle considerazioni esposte sulle caratteristichedei dati e sul loro utilizzo, verra proposta un’ipotesi di soluzione.

I vincoli a cui tale soluzione e sottoposta emergono direttamente dal-le caratteristiche dei dati considerati: verranno quindi prese in considera-zione soluzioni che garantiscano la migliore e�cienza nella gestione dellapersistenza dei dati utilizzati e prodotti da workflow di simulazione.

In tale contesto il significato di e�cienza dipendera dal tempo di esecu-zione necessario a gestire le operazioni piu comuni eseguite sulla base di dati,nonche dalla facilita di mappatura di oggetti Java dal livello applicativo allabase di dati [11].

Verranno quindi trattate metodologie alternative per gestire la persi-stenza dei dati di workflow di simulazione. La ricerca di alternative sarasottoposta a vincoli che emergono dalle caratteristiche dei dati e dai vin-coli individuati nelle sezioni successive. Vengono poi proposte ipotesi disoluzione del problema.

2.1 Gestione dei dati

Viene di seguito descritta la gestione dei dati operata dai software sviluppatida Esteco, attualmente gestita attraverso RDBMS e da OODBMS (ObjectOriented Data Base Management System).

In particolare viene delineata la strategia adoperata attualmente per ge-stire i dati associati al workflow di simulazione per il software modeFRON-TIER.

Ogni workflow progettato con modeFRONTIER puo essere interpretatocome una funzione complessa, avente:

• n variabili di input;

• m variabili di output.

Il tipo di dato di una variabile e generico. Puo essere numerico, stringa,una struttura complessa, un array multidimensionale, un Uniform ResourceIdentifier, un file, ecc.

Il significato di ogni variabile e completato da metadati, di tipo generico,che per tipi numerici possono ad esempio rappresentare il dominio di unavariabile che nel caso numerico puo essere rappresentato dal limite inferiore,superiore, etc..

13

Il workflow di simulazione di per se si limita a definire come le variabi-li decisionali vengono trasformate in risposte del sistema, ma un problemadi ottimizzazione contiene anche la definizione di vincoli e obiettivi. Que-sti ultimi sono considerati ulteriori variabili, e sono calcolati a partire dallevariabili gia introdotte, in base ad una espressione fornita dall’utente. L’e-spressione utilizzata per calcolare l’obiettivo o il vincolo e esso stesso unmetadato.

Si definisce Design una tupla contenente i valori delle variabili di input,output, e dei i valori calcolati di obiettivi e vincoli.

Nella situazione attuale modeFRONTIER gestisce due database:

1. DOE-DB (Design of Experiments), che contiene le tulle di valori so-lo per le variabili di input. Questa tabella rappresenta lo spaziodecisionale iniziale che dovra essere esplorato.

2. Design-DB, che contiene i design, cioe le tulle comprendenti input eoutput calcolati dal modello sulla base degli stessi. Contiene inoltreobiettivi e vincoli associati.


• gli input sono replicati nei due database;

• obiettivi e vincoli sono calcolati in fase di valutazione e salvati comecampi aggiuntivi. Non vengono quindi ricalcolati ogni volta.

Oltre a metadati associati ad una variabile, possono esistere anche meta-dati associati ad un design: ad una riga, quindi, invece che ad una colonna.Ad esempio, il tipo di design, per memorizzare l’informazione su un designcorretto oppure su un design errato perche qualche vincolo non e stato ri-spettato. Anche questi metadati possono essere generici.

2.2 Problematiche nella gestione di dati

Le problematiche nella gestione di dati di progetto nei workflow di simula-zione per l’ottimizzazione multiobiettivo si ricavano dalla sezione precedentee dalla Sezione 1.3.

Riassumendo le indicazioni ottenute nelle sezioni precedenti, si conclu-de che i dati trattati dai workflow di simulazione possiedono le seguenticaratteristiche:

14

Volume considerevole dei dati in gioco: l’ottimizzazione multiobietti-vo opera su grandi quantitativi di dati (migliaia, milioni di valorinumerici) per produrne altrettanti.

Scarsa struttura dei dati considerati: i dati prodotti sono semi-strutturatio non-strutturati, quindi di�cili da relazionale tra loro. Per una defini-zione di non-struttura dei dati si rimanda al Capitolo 3, dove vengonodescritte le tecnologie NoSQL.

Eterogeneita di tipo di dato: vengono trattati dati di tipo JSON, binari,CAD, JPEG, video, composti, ecc.

Variabilita nella loro numerosita, tipizzazione, tempo di vita.

Assunte come tali le caratteristiche dei dati, si determinano come seguele di�colta incontrate nell’utilizzo di un RDBMS:

Scalabilita del volume di dati considerato: un RDBMS e un software chee di�cilmente scalabile orizzontalmente, quindi poco adatto a gestirevolumi di dati considerevoli. Per un approfondimento del concetto discalabilita si rimanda alla Sezione 3.1 del Capitolo 3.

Relazionabilita dei dati considerati: un RDBMS e uno strumento utile acondizione che i dati da gestire siano relazionati tra loro. La condi-zione viene a mancare in assenza di relazioni tra dati, come e comunetrattando dati scarsamente strutturati o non strutturati.

Tipizzazione del dato: gli RDBMS piu comuni possono gestire tipi di da-ti eterogenei (valori numerici, stringhe), ma non sono stati progetta-ti per gestire tipo di dato composto, come ad esempio e un numerocomplesso.

Assenza di schema per la gestione dei dati: se non sono nota a priori laquantita e il tipo di dato da memorizzare e complesso definire unoschema noto a priori. I RDBMS non sono stati progettati per poteradattare lo schema fisico in funzione dei dati a seconda dei dati fornitidal livello applicativo.

Si noti inoltre che nelle operazioni di salvataggio dei dati risultano limita-tive le procedure di ORM (Object Relational Mapping), cioe quelle tecnicheche permettono di convertire dati tra sistemi incompatibili nei linguaggidi programmazione orientati agli oggetti. Ne e un esempio la mappatu-ra di implementazioni di Java Collection, in particolare l’implementazionedell’interfaccia Map.

Nel caso in oggetto tali tecniche sono necessarie a trasferire le infor-mazioni dal livello applicativo, sviluppato in linguaggio Java, allo strato di

15

persistenza, o↵erto da sistemi di gestione di basi di dati MySQL o Postgre-SQL.

2.3 Ipotesi di soluzione

In base all’analisi dello scenario del Capitolo 1 e delle problematiche eviden-ziate nel Capitolo 2, viene proposto di utilizzare una tecnologia alternativaper la gestione dello strato di persistenza.

Si noti che il contributo del lavoro di tesi in questo contesto non vuoleessere la creazione di un modulo software basato su tecnologia NoSQL de-stinato ad arricchire le funzionalita di software prodotti presso Esteco. Sivuole invece sviluppare uno strumento di verifica che permetta di valutare,sotto determinati vincoli, la validita di alcuni modelli di basi di dati nonrelazionali.

2.4 Related works

Viene qui analizzato lo stato dell’arte relativo alla problematica delineatain questo capitolo. Si sono in particolare ricercati studi comparativi simili aquello svolto nel lavoro di tesi.

Orend [12] descrive la popolarita guadagnata dalle basi di dati non rela-zionali, prendendone ad esempio alcune e analizzandole. Viene inoltrecondotto uno studio per verificare la loro abilita nel rimpiazzare unostrato di persistenza basato su oggetti e sul modello relazionale. Il la-voro e incentrato nella descrizione delle caratteristiche delle basi di datinon relazionali e come queste possono soddisfare le esigenze di soft-ware per la gestione della conoscenza e il lavoro collaborativo su web.Non e presente uno studio comparativo su piu basi di dati relazionalie su come queste possono gestire la mappatura di entita software Java.

Schram e Anderson [17] espongono come l’acquisizione, l’integrazione ela memorizzazione di grandi quantita di dati da sorgenti diverse sia di-ventata una necessita in molti campi dell’ingegneria. Il lavoro descrivel’esperienza di transizione da una base di dati relazionale ad una archi-tettura di persistenza ibrida basata su tecnologie NoSQL e relazionali.Vengono presentate l’architettura software e le problematiche relativeal modello dei dati incontrate durante la transizione. Lo scenario diriferimento considerato, dato dall’analisi di grandi quantita di aggior-namenti di stato sul servizio di micro-blogging Twitter, e diverso da

16

quello preso in considerazione in questo lavoro di tesi.

Wei-ping, Ming-xin e Huan [22] descrivono le di�colta che incontra unsistema di gestione di dati relazionale nell’a↵rontare la gestione di datiin applicazioni Web. In particolare espone come le tecnologie NoSQLpossono rimpiazzare una tecnologia relazionale, e sperimentalmentedetermina un valore aggiunto rispetto a particolari tipi di interroga-zione sui dati (JOIN multi tabella). Lo scenario preso in esame ediverso da quello considerato nel presente lavoro di tesi.

Braga e De Lucena [6] analizzano alcune basi di dati NoSQL con l’obiet-tivo di indagare la persistenza di oggetti complessi. Il lavoro pero esoprattutto una panoramica dei modelli di dati NoSQL piu comuni,e non o↵re una valutazione sperimentale comparativa rispetto ad unoscenario di riferimento.

17

3 Le tecnologie NoSQL

3.1 Definizione

Dare una definizione di tecnologia NoSQL e complesso, dal momento chenon esiste in letteratura una definizione univoca [20]. I detrattori dellatecnologia preferiscono riferirsi amovimento NoSQL per indicare il fenomenodi crescente attenzione verso un insieme di nuovi prodotti software, chepropongono soluzioni diverse per la gestione di una base di dati attraversoun approccio comune: un modello logico non relazionale. Il termine NoSQLvenne coniato per la prima volta nel 1998 da Carlo Strozzi, per indicaregenericamente un database che non utilizzava il modello relazionale. [21]

Nelle sezioni successive vengono analizzate le motivazioni che hanno por-tato alla nascita del movimento NoSQL, che descrive l’emergere dell’utilizzodi database non relazionali. NoSQL non e un singolo prodotto, ma rappre-senta un insieme di concetti e di tecniche diverse per la memorizzazione ela manipolazione di dati: in questa categoria sono stati sviluppati databaseNoSQL specializzati nella memorizzazione di documenti, o per l’archiviazio-ne di coppie chiave/valore, o orientati alle colonne.

Verranno quindi analizzate diverse tipologie di sistemi NoSQL, per con-frontare le loro caratteristiche di gestione di grandi volumi di dati e studiarnei vantaggi rispetto al classico modello relazionale.

3.2 Limitazioni del modello relazionale

I RDBMS assumono che i dati da trattare siano ben definiti e largamenteuniformi, ma soprattutto che le loro proprieta e relazioni possano essere defi-nite a priori, in modo che l’informazione sia sistematicamente referenziabile.Quando queste assunzioni vengono a cadere, i RDBMS devono gestire ecce-zioni per denormalizzare le tabelle, eliminare costanti, rilassare le garanziesulle transazioni. Appare percio una forzatura l’utilizzo di uno schema rigidoper la gestione di dati eterogenei, scarsamente strutturati e non necessaria-mente relazionati tra loro.

I RDBMS sono stati progettati in un periodo in cui le caratteristichehardware, le necessita degli utenti e il mercato dei database erano profon-damente diversi dallo scenario moderno. I database relazionali modernitraggono le loro radici da System R: DB2 di IBM e un diretto discendentedi System R, come anche Microsoft SQL Server e Oracle. System R erastato sviluppato in riferimento alle caratteristiche hardware del 1970. Daallora e aumentata la frequenza dei processori e la quantita e la velocitadi accesso alle memorie, fattori che ad oggi non costituiscono piu dei limitialla progettazione di un programma di gestione di base di dati [19]. Sivedra quindi come le proprieta ACID, alla base del modello relazionale dei

18

dati, proprieta di cui si discutera nella sezione successiva, possono essereconsiderate un valore aggiunto non necessario in diversi casi di utilizzo.

3.2.1 Da ACID a BASE

Per operare in modo corretto sulle informazioni contenuti in una base di datirelazionale, e necessario che i meccanismi che implementano le transazionisoddisfino le proprieta ACID. ACID deriva dall’acronimo inglese Atomicity,Consistency, Isolation, Durability.

• Atomicita. La transazione non puo essere divisa nella sua esecuzione,che puo essere totale oppure nulla, ma non parziale.

• Coerenza. Il database deve trovarsi in uno stato coerente all’inizioe alla fine della transazione, cioe non deve violare vincoli di inte-grita. Quindi non devono verificarsi incoerenze tra i dati archiviatinel database.

• Isolamento. Ogni transazione deve venir eseguita in modo isolato eindipendente dalle altre transazioni. L’eventuale fallimento di unatransazione non deve interferire con le altre transazioni in esecuzione.

• Durabilita. Detta anche persistenza, si riferisce al fatto che non pos-sono essere persi i cambiamenti richiesti.

Per alcune applicazioni si puo a↵ermare che l’aderenza del modello deidati alle proprieta ACID sia una scelta eccessivamente severa. In particola-re quando si trattano dati semi-strutturati e non-strutturati, si deve poteravere flessibilita di gestione dell’archiviazione e dell’accesso alle informazioni.

Molti database NoSQL sono progettati per perdere il requisito ACID avantaggio della disponibilita del dato. Un sistema che rispetta tali requisitisi puo definire BASE Basically Available, Soft-state, Eventually-consistent,concetto che verra chiarito nella sezione successiva. [15].

3.2.2 Scalabilita del modello relazionale

Uno dei motivi che spiegano la fama crescente guadagnata da database chenon adottano il modello relazionale e data dalla scalabilita. Questo e unrequisito sempre piu importante per alcune applicazioni web, che devonogestire in tempo reale le richieste di un numero crescente di utenti.

Un sistema definibile scalabile deve avere un incremento di prestazioniche e direttamente proporzionale all’aumento di risorse dedicate a gestire

19

l’aumento del carico di lavoro. Se l’aumento delle prestazioni non e diretta-mente proporzionale, il sistema sta sprecando risorse.

Le risorse possono essere aumentate, cioe scalate, attraverso una soluzio-ne orizzontale oppure attraverso una soluzione verticale.

Un sistema scales up, cioe scala orizzontalmente, se l’aumento delle ri-sorse si riferisce all’aumento dei nodi nel sistema, cioe se il sistema riesce aparallelizzare il carico di lavoro [14].

Una applicazione scalabile deve rispettare i seguenti criteri:

1. Scalabilita orizzontale: piu unita di calcolo (piu server) creano piucapacita di calcolo

2. Trasparenza all’applicazione: la logica dell’applicazione deve essereseparata dal problema di scalare le risorse

3. Fault-tolerant: non ci deve essere un singolo punto di fallimento. Unfallimento di un server non deve causare un fallimento dell’applicazio-ne.

Un esempio di scalabilita proveniente dal mondo dell’hardware e un arraydi dischi RAID5:

1. e scalabile orizzontalmente: al crescere del numero di dischi in un arrayRAID5 si ha piu spazio e, generalmente, prestazioni migliori;

2. e trasparente all’applicazione: le applicazioni accedono al RAID comefosse un singolo dispositivo, ed e il controller del RAID array che sioccupa di eseguire la divisione dei dati su piu dischi fisici;

3. non esiste un singolo punto di fallimento. Si puo estrarre un discodall’array senza compromettere la funzionalita dell’applicazione cheutilizza il RAID.

Il vantaggio maggiore di questo genere di scalabilita e il costo, dal mo-mento che la distribuzione del carico di lavoro puo essere e↵ettuata su nodia basso costo.

3.2.3 Scalabilita verticale

Un database relazionale e scalabile soprattutto verticalmente, cioe per au-mentare l’e�cienza nella gestione dei dati e necessario eseguire l’RDBMS suun sistema piu potente e costoso [10]. Si aumentano quindi le risorse delsingolo nodo del sistema: per esempio utilizzando CPU a frequenza maggio-re o incrementando la memoria disponibile.

20

Esistono soluzioni commerciali per rendere un database relazionale sca-labile orizzontalmente, cioe prodotti software che permettono di interrogareun database distribuito su piu nodi di calcolo, ma in generale le operazionidi gestione di basi di dati relazionali in ambiente distribuito sono complessee costose.

Il modo piu semplice ed immediato di scalare un database SQL e ri-dimensionare il server che ospita il database, per guadagnare prestazioni.Questo tipo di soluzione viene definita scalabilita verticale, o scalabilita del-la Legge di Moore. Operare un aggiornamento hardware del sistema cheospita il database comporta i seguenti problemi:

1. e una transazione complicata che usualmente richiede un interventoumano e un’interruzione del servizio;

2. il server sostituito e spesso inutilizzato.

3.3 Caratteristiche dell’approccio non relazionale

Alcune aziende, specialmente quelle che operano sul Web, hanno cominciatoad adottare con successo soluzioni NoSQL, perche le loro necessita di me-morizzazione di dati di↵eriscono in modo sostanziale dalle necessita di forteintegrita e coerenza che, ad esempio, deve avere una banca per gestire tran-sazioni. [20]

Le soluzioni NoSQL sono quindi specializzazioni che, pur non rispettan-do l’integrita e la coerenza dei dati o↵erta dal modello relazionale, o↵ronoprestazioni di uno o due ordini di magnitudo superiori rispetto all’approc-cio dei classici RDBMS, i quali puntano invece a essere contenitori ad unadimensione per tutti gli utilizzi.

Le caratteristiche di un database NoSQL possono essere riassunte nellesezioni successive.

3.3.1 Scalabilita orizzontale

La complessita di elaborazione e memorizzazione in un database aumentacon il volume di dati da elaborare e memorizzare. Come gia enunciato, lesoluzioni per rendere stabili le prestazioni di un database al crescere dellaquantita di dati da trattare possono essere verticali, cioe l’unita di elabora-zione viene ridimensionata coerentemente al problema, oppure orizzontali,cioe viene duplicata l’unita di elaborazione.

La prima scelta e spesso una strada obbligata per i RDBMS di utilizzocomune: tuttavia il costo che ne consegue in termini di infrastruttura, quin-di di acquisto di server di fascia alta, e spesso insostenibile per le piccoleaziende.

21

La seconda soluzione e supportata in origine dai database NoSQL. Idatabase NoSQL sono progettati per scalare in modo distribuito su nodidi calcolo distinti, senza dipendere dalle prestazioni hardware del singolonodo. Possono essere quindi eseguiti su numerosi componenti di commodityhardware, cioe di hardware di fascia non elevata e dal prezzo contenuto. Inodi di esecuzione possono essere aggiunti o rimossi senza compiere lo sforzonecessario a partizionare dati in una soluzione con un RDBMS eseguito suun cluster di nodi di calcolo.

3.3.2 Mappature tra oggetti e relazioni

La maggior parte dei database NoSQL sono progettati per memorizzarestrutture di dati che sono simili a quelle dei linguaggi di programmazioneorientati agli oggetti. Questo permette di evitare costose mappature tra re-lazioni e oggetti quando si utilizza un RDBMS.

Cio diventa un aspetto importante per le applicazioni con strutturedi dati a bassa complessita che di�cilmente trarrebbero beneficio da unamemorizzazione in un database relazionale [18].

3.3.3 Prestazioni ma non a�dabilita

Vi sono scenari di utilizzo dove e preferibile compromettere l’a�dabilita infavore delle prestazioni. Per citare un esempio applicabile con tecnologieNoSQL, le sessioni HTTP che devono essere condivise tra diversi web servere devono essere accessibili per la durata della sessione, ma che non devonoessere memorizzate in modo persistente.

3.4 Modelli di dati

I modelli di dati utilizzati nelle tecnologie NoSQL sono molteplici. Segueuna veloce trattazione dei principali.

3.4.1 Orientati alle colonne

Denominati anche Sorted ordered column-oriented stores, oppure Wide co-lumn store.

Per capire il funzionamento dei database orientati alle colonne si puocitare come esempio BigTable [7], la base di dati proprietaria di Google.BigTable di Google e un database proprietario, compresso e ad alte presta-zioni costruito sul Google File System e altre tecnologie di Google. Non edistribuito e non e utilizzato al di fuori di Google, sebbene Google ne o↵ral’accesso come parte del Google App Engine [13].

22

BigTable e progettato per scalare orizzontalmente su dimensioni di da-ti nell’ordine dei petabyte, su centinaia o migliaia nodi di calcolo, conl’obiettivo di rendere facile l’aggiunta o la rimozione di un nodo.

Le idee sviluppate per BigTable sono state riprese da molti sviluppatoriche hanno prodotto e rilasciato con licenza open-source database consideraticloni di BigTable. Tra questi, Cassandra ha ripreso sia le idee di BigTableche di Dynamo, un prodotto non relazionale sviluppato da Amazon, basatosu modello chiave/valore.

3.4.2 Chiave/valore

Un HashMap o un array associativo e la struttura dati piu semplice che puoospitare un insieme di coppie chiave/valore.

Le coppie chiave/valore sono di diversi tipi: alcune tengono dati in me-moria e alcune forniscono la capacita di memorizzare i dati su disco. Talicoppie possono inoltre essere distribuite e memorizzate su cluster di nodi.Uno dei piu conosciuti archivi basato su questo modello di dati e l’OracleBerkeley DB, sviluppato all’inizio del 1990.

Un altro tipo di archivio chiave/valore comunemente utilizzato e la ca-che. Una cache e un meccanismo utilizzato da sistemi operativi, database,componenti di middleware, applicazioni, che permette di tenere in memoriai dati piu utilizzati da un’applicazione, allo scopo di ridurre gli accessi diI/O su disco.

3.4.3 Orientati ai documenti

Con il termine document database si intendono insiemi debolmente struttu-rati di coppie chiave/valore nei documenti, tipicamente JSON.

I database orientati ai documenti trattano un documento come una sin-gola entita, evitando di dividerlo nelle sue coppie costituenti chiave/valore.

Questo permette di mettere insieme diversi documenti in un’unica colle-zione. I document database permettono l’indicizzazione di documenti sullabase di un identificatore primario e di loro proprieta. Si osservi a tal propo-sito l’esempio di memorizzazione di un oggetto Java su MongoDB, riportatoalle sezioni conclusive del Capitolo 4.

3.5 Orientarsi nella scelta

I progetti di database non relazionali disponibili gratuitamente sono molte-plici (circa 180 a marzo 2013). In Figura 5 vengono riportati i principali,suddivisi secondo caratteristiche di persistenza e parallelismo.

23

'LVWULEXLWRVX�SL��QRGL

1RQ�GLVWULEXLWR

3HUVLVWHQ]DLQ�PHPRULD

3HUVLVWHQ]DVX�GLVFR

&DVVDQGUD+%DVH

+\SHUWDEOH5LDN

9ROGHPRUW

&RXFK'%.XPRIV

0RQJR'%

+D]HOFDVW*LJD6SDFHV,QILQL6SDQ

7HUUDVWRUH &OXVWHU�'%1HWZRUN�)6

0HPFDFKHG /LJKWFORXG

5HGLV 7RN\R/RFDO�)6

Figura 5: Classificazione database non relazionali, secondo caratteristiche dipersistenza diverse. Sono presentati database che memorizzano dati su discoo in memoria, collocati rispetto alle caratteristiche di ridondanza e localitadei dati (database distribuito su piu nodi - database non distribuito).

24

4 Sperimentazione

In questo Capitolo viene descritta la fase sperimentale della tesi. In rife-rimento allo scenario delineato nel Capitolo 1 e alla problematica ad essaa↵erente delineata nel Capitolo 2, si verifica la validita dell’applicazione dellatecnologia presa in considerazione al Capitolo 3.

4.1 Obiettivo della sperimentazione

Oggetto della sperimentazione sono stati i NoSQL server individuati in basealle caratteristiche espresse nella Sezione 4.3.

Obiettivo generale dell’esperimento e verificare, in riferimento allo scena-rio descritto, se le tecnologie NoSQL possano apportare un valore aggiuntonella gestione della base di dati.

La determinazione del valore aggiunto sara verificata:

• sulla misura di un osservabile, che sara il tempo di esecuzione delleoperazioni di inserimento, lettura, aggiornamento, cancellazione di uninsieme di dati;

• sulla facilita di mappatura di oggetti software Java, utilizzati nel livelloapplicativo, sullo strato di persistenza;

Date le caratteristiche della tecnologia NoSQL, il risultato atteso e unvalore aggiunto rispetto alla gestione con modello relazionale per cio cheriguarda dati scarsamente strutturati e non relazionati e per cio che riguar-da la creazione di uno schema, ovvero di un contenitore dei dati, a livelloapplicativo.

Caratteristica peculiare delle basi di dai NoSQL e infatti l’assenza di unoschema predefinito dove collocare le informazioni provenienti dallo strato ap-plicativo. Si ritiene questa una caratteristica interessante nello scenario diriferimento, dove il volume, la quantita, la tipologia del dato prodotto dal-l’applicazione non sono determinabili a priori.

Per raggiungere l’obiettivo sopra delineato e stato implementato unostrumento software di verifica che verra descritto in dettaglio nelle sezionisuccessive di questo capitolo. Lo strumento permettera di verificare la vali-dita delle basi di dati NoSQL individuate nella Sezione 4.3.

Il contributo del lavoro di tesi va quindi identificato sia con l’apporto diuna base di conoscenza in Esteco, relativamente alle basi di dati non rela-zionali, sia in concreto nello strumento software sviluppato. Esso permettedi verificare la validita di alternative alla gestione di dati di workflow di

25

simulazione tramite RDBMS, in particolare utilizzando tecnologie non rela-zionali. Rimane a disposizione di Esteco, che potra utilizzarlo per verificarela qualita di nuove tecnologie NoSQL qualora ne sorgesse la necessita.

4.2 Strumento di sperimentazione

Lo strumento adoperato per e↵ettuare la sperimentazione e ricavare le infor-mazioni necessarie a verificare la validita di una base di dati non relazionalee un software sviluppato in Java.

Tale software dovra essere in grado di compiere le seguenti operazioni.

Creare un test secondo criteri stabiliti dall’utente;

Eseguire il test selezionando la base di dati da sperimentare;

Salvare i risultati del test per elaborazione successiva.

Per una descrizione piu accurata dello strumento si rimanda alla Sezione4.4.

4.3 Individuare i candidati

I server NoSQL disponibili liberamente (con licenza aperta) sono molteplici,come descritto al Capitolo 3. Tra questi sono stati individuati tre candidatiidonei, che verranno utilizzati nella fase di verifica.

I candidati server sono stati individuati in base alle seguenti preferenze:

• il candidato deve poter gestire tipi di dato eterogenei, scarsamentestrutturati, non relazionati tra loro;

• deve esistere la possibilita di interrogare il database con driver Java conAPI gia sviluppate e disponibili liberamente, essendo Java il linguaggiodi programmazione in uso in Esteco;

• devono esistere API per la mappatura di oggetti software Java versoil server NoSQL, in modo similare a quanto proposto dallo standardJPA (Java Persistence API);

• con riferimento al presupposto precedente, e preferibile avere la pos-sibilita di eseguire mappature definite dall’utente, cioe definire comeviene trasferita l’informazione dallo strato applicativo allo strato dipersistenza;

26

• sara privilegiata la scelta di tre candidati che possiedono modelli didati diversi, cioe una situazione ideale potrebbe ad esempio esserecostituita da un candidato column-oriented, uno chiave/valore, unodocument-oriented;

• ogni candidato deve poter supportare l’inserimento e l’interrogazioneschema-less, cioe possedere la possibilita di definire lo schema a partireda cio che viene generato dallo strato applicativo;

• verranno preferiti candidati che presentano la possibilita di essere sca-lati orizzontalmente, in previsione di un aumento del volume di datimemorizzati e quindi la frammentazione degli stessi su piu unita dicalcolo;

• il modello dei dati scelto dovrebbe preferibilmente mantenere le pro-prieta ACID di Atomicita, Coerenza, Isolamento, Durabilita;

• preferibilmente si sceglieranno server NoSQL che possono essere instal-lati in alta a�dabilita e che presentano caratteristiche di tolleranza aiguasti.

In base alle preferenza sopra evidenziate vengono selezionati i tre candi-dati NoSQL server, di cui si riportano le caratteristiche essenziali in Figura6.

Database Modello dei dati Java API - CRUD Java API - OM

MongoDB Document-oriented Nativo - MongoDB Morphia

Cassandra Key-value / row-oriented Hector - Kundera Kundera

OrientDB Multimodel Nativo - OrientDB Nativo - OrientDB

Figura 6: Le caratteristiche principali dei tre candidati server NoSQL.CRUD e abbreviazione per Create, Read, Delete, Update, cioe le operazionidi creazione, lettura, cancellazione, aggiornamento. OM e abbreviazione perObject Mapping, cioe mappatura di oggetto.

Per ognuno dei tre candidati si riportano inoltre le peculiarita nellesezioni successive.

A titolo di completezza si riportano inoltre i server NoSQL esclusi, conuna breve motivazione a supporto della scelta:

• Redis [5] e una base di dati chiave/valore, esclusa per lo scarso sup-porto per la mappatura di oggetti Java;

27

• Hadoop [23] e il framework di Apache che include HBase, una base didati che e stata esclusa a causa della di�colta di implementazione delframework Hadoop stesso;

• CouchDB [2] e una base di dati orientata ai documenti, esclusa perlo scarso supporto verso Java API che supportassero la mappatura dioggetti.

4.3.1 OrientDB

OrientDB [4] e una base di dati NoSQL, open source, sviluppata interamen-te in Java. Sebbene sia un database multimodello, le relazioni sono gestitecome nei database basati su grafi, con connessioni dirette tra i record. Sup-porta modalita senza schema e con schema.

Supporta il linguaggio SQL per la manipolazione dei dati ed esponenativamente HTTP RESTful e JSON senza l’utilizzo di librerie di terzeparti e altre componenti di estensione.

Caratteristica particolarmente interessante di OrientDB sono i link di-rettamente navigabili. Per comprenderne il significato si riporta di seguitoun esempio.

Si supponga di avere due insieme di record, che assumeremo tabellari.Il primo memorizza nomi di nazione, il secondo nomi di citta. Il primo tipodi record ritorna una rappresentazione di questo tipo con una operazioneSELECT.

orientdb> select from country

---+--------+--------------------#| RID |name

---+--------+--------------------0| #22:0|Italy1| #22:1|France2| #22:2|Spain

3 item(s) found. Query executed in 0.012 sec(s).

Il secondo invece viene rappresentato nel seguente modo:

28

orientdb> select from city

---+---------+------------------+--------------------#| RID |name |country

---+---------+------------------+--------------------0| #21:0|Rome |#22:01| #21:1|Paris |#22:12| #21:2|Madrid |#22:2

3 item(s) found. Query executed in 0.012 sec(s).

Si noti quindi che la relazione tra nomi di citta e nazioni (ogni cittaappartiene ad una nazione) viene riportata attraverso un ID numerico, checorrisponde al record stesso a cui la relazione porta.

Tale proprieta rende possibile interrogazioni dove si puo navigare tra irecord. Ad esempio e immediata un’interrogazione complessa come la se-guente, che in una base di dati relazionale avrebbe richiesto un JOIN tra ledue tabelle.

orientdb> select from city where country.name=’Italy’ orcountry.name=’Spain’

---+---------+-----------------+--------------------#| RID |name |country

---+---------+-----------------+--------------------0| #21:0|Rome |#22:01| #21:1|Madrid |#22:2

4.3.2 MongoDB

MongoDB [3] e una base di dati non relazionale, orientata ai documenti, rila-sciata con licenza simile alla GNU General Public License nel febbraio 2009.Viene sviluppato in C++ e utilizza JavaScript come linguaggio di gestionedei dati. Esistono driver per interagire con MongoDB in diversi linguaggi:C, C#, C++, Erlang, Haskell, Java, JavaScript, Perl, PHP, Python, Ruby,Scala.Utilizzato da FourSquare, Shutterfly, Intuit, Github e altri, espone interfac-ce HTTP/REST per la manipolazione.

Particolarmente interessante e la Figura 7, dove viene rappresentata unaipotetica mappatura tra il RDBMS MySQL e il NoSQL MongoDB.

29

Figura 7: Proposta di mappatura tra query SQL nel RDBMS MySQL elinea di comando JavaScript utilizzata nell’interrogazione in MongoDB.

30

4.3.3 Cassandra

Cassandra [1] e un DBMS non relazionale, distribuito e open source, basatosu una struttura di memorizzazione chiave valore.

Sviluppato in Java presso Facebook, con licenza open-source. Nel 2008Cassandra venne donato alla Apache Foundation. I metodi di accesso com-prendono un’interfaccia a linea di comando, Thrift e Java API. Esistonoclient in diversi linguaggi: Java, Python, PHP, Grails, .NET, Ruby.

Viene attualmente utilizzato da Facebook, Digg, Reddit, Twitter.

Il concetto di database orientato alle colonne (columnt-oriented) e leg-germente fuorviante rispetto al modello di dati realmente usato, che e unibrido basato su chiave e valore, ma rappresentato come orientato alle co-lonne.

In Cassandra, le righe contengono colonne. Per accedere alla piu piccolaunita di dato, cioe la colonna, bisogna specificare il nome della riga (cioe lachiave), piuttosto che il nome della colonna. Quindi in una colonna chia-mata Frutta si potrebbe avere una struttura come nell’esempio seguente,che rappresenta due righe, dove i tipi di frutto sono le chiavi delle righe, eciascuna colonna ha un nome e un valore.

mela -> colore peso prezzo varieta"rosso" 100 10 "Golden"

arancia -> colore peso prezzo varieta"arancio" 200 20 "Tarocco"

La di↵erenza con una base di dati relazionale sta nel fatto che in Cas-sandra si possono omettere le colonne. L’arancio puo ad esempio non avereuna varieta. Oppure si possono aggiungere colonne arbitrarie, ad esempiol’origine dell’arancio, in ogni momento. Si puo pensare ai dati rappresentatida cassandra come ad una tabella, ma sparsa e dove molti valori possonoessere vuoti.

Ancora, un modello di dati orientato alle colonne puo essere usato adesempio per liste e serie temporali, dove ogni colonna e unica. Nell’esempioseguente abbiamo solo una riga, ma possiamo avere migliaia o milioni dicolonne.

temperatura -> 2013-03-15 2013-03-16 2013-03-17 ...3.5 4.5 6.8 ...

31

Questo approccio di↵erisce sostanzialmente dal modello relazionale, doveintuitivamente si sarebbero elencati i valori di una serie temporale per righee non per colonne.

4.4 Implementazione

Viene di seguito descritto l’ambiente hardware e software nel quale sonostati eseguiti gli esperimenti. La descrizione dell’ambiente e preceduta daun breve paragrafo dove si delinea la metodologia di implementazione dautilizzare.

4.4.1 Pianificazione

Come descritto brevemente nella Sezione 4.2, lo strumento software svilup-pato dovra essere in grado di creare delle entita di test e sottoporle a verificasul database di riferimento. Infine dovra essere in grado di memorizzare irisultati per una loro elaborazione.

Tenendo conto di tutti gli elementi necessari a sviluppare un tale stru-mento, si e deciso di procedere secondo i seguenti passi per cio che riguardala parte server:

installazione delle basi di dati candidate;

verifica della funzionalita della base di dati operando via linea di comando.

Per cio che riguarda la parte client invece:

installazione delle API Java nel progetto NetBeans;

verifica della funzionalita delle API creando connessioni con i server attivi;

creazione di un test per l’inserimento di informazioni generiche sul server(no Java API per Object Mapping);

verifica dell’e↵ettiva scrittura dell’informazione sul server;

creazione degli oggetti Java scelti per sottoporre a test le basi di dati;

creazione di un test per l’inserimento degli oggetti Java sui server e verificadell’e↵ettiva scrittura;

esecuzione batch di un insieme di test e salvataggio dei risultati.

Si noti inoltre che nella fase di memorizzazione dei risultati si e utilizzatouno stesso database NoSQL, in particolare OrientDB. Tale procedura si edimostrata di facile implementazione e ha permesso inoltre di interrogare

32

Figura 8: Sistema di visualizzazione dei risultati.

33

una base di dati di risultati attraverso il protocollo HTTP. Grazie a questapossibilita e stato creato il sistema di visualizzazione dei risultati, ra�guratoin Figura 8.

4.4.2 Strumenti hardware

L’hardware utilizzato consta di due computer portatili:

MacBook Pro, utilizzato per implementare l’architettura server. Le speci-fiche principali sono una CPU Intel Core 2 Duo a 2.33Hz in frequenza,3GB RAM.

MacBook Pro, utilizzato per implementare l’architettura client. Le speci-fiche principali sono una CPU Intel Core i7 a 2.9GHz in frequenza,8GB RAM.

Si noti che l’obiettivo dell’esperimento e analizzare le prestazioni dellabase di dati, non del client. L’architettura hardware rispecchia questa scelta:il server e in esecuzione su una architettura Intel prodotta nel 2006, mentreil client su una macchina del 2012. La frequenza del processore, il bus diinterconnessione, la RAM presentano e�cienza maggiore sul client.

4.4.3 Strumenti software

Il software utilizzato sul computer client consiste in:

• sistema operativo Mac Os X 10.8.2;

• Java Development Kit 6;

• ambiente integrato di sviluppo NetBeans 7.2.1 per la creazione di unprogetto Java ai fini della sperimentazione;

• strumento per build automatici Maven;

• API Java per l’interrogazione dei database server, come descritto inFigura 1 al Capitolo 2;

• sistema di versionamento GIT.

Il software utilizzato sul computer server consiste in:

• sistema operativo Mac Os X 10.6.1;

• sistema di virtualizzazione VirtualBox 5.1;

• sistema operativo Ubuntu 10.04.3 32 bit, virtualizzato;

• server NoSQL: Cassandra, OrientDB, MongoDB.

34

4.4.4 Interconnessione

La rete di connessione stabilita tra il client e il server e una connessione back-to-back (punto-punto) tra i due computer portatili utilizzati per il server eper il client. Poiche la connessione punto-punto ha creato un collegamentotra i nodi fisici ma non tra il nodo client (fisico) e quello server (virtuale,si ricordi che la parte server e in esecuzione su macchina virtuale), si ecreato un tunnel SSH (Secure Shell) per permettere il trasporto dei dati diconnessione verso l’interfaccia di rete della macchina virtuale.

Ai fini dell’obiettivo della tesi e dello scenario considerato si riterra tra-scurabile nei risultati di esperimento il contributo aggiuntivo, in termini ditempo, dato dal tunnel stesso.

4.5 Struttura dei test

Vengono qui presentati le classi Java utilizzati per sperimentare i serverNoSQL. In base alle specifiche JPA ci si riferira ad esse, nel seguito dellatrattazione, anche come entita di persistenza.

SimpleBean e una classe che istanzia un oggetto Java molto semplice,contiene un dato di tipo intero e un dato di tipo stringa;

CompositeBean e una classe per istanziare un oggetto Java piu complesso,che contiene un riferimento a oggetti SimpleBean, cioe un riferimentoad un tipo di dato creato dall’utente;

MapBean e una classe che istanzia un oggetto Java che contiene due imple-mentazioni dell’interfaccia Collection, in particolare una lista di Sim-pleBean e una mappa che associa una chiave (tipo di dato stringa) adun valore (tipo di dato SimpleBean).

Tali oggetti dovranno venir memorizzati dai server NoSQL e la loro strut-tura informativa conservata, cioe mappata sulla base di dati. Cio significa adesempio che i tipi di dato intero e stringa dell’oggetto SimpleBean dovrannoessere ricreati come tipo di dato intero e stringa sullo strato di persistenzao↵erto dalla base di dati.

Si noti che mentre l’oggetto SimpleBean rappresenta il minimo indi-spensabile che il server NoSQL deve essere in grado di memorizzare, non eassicurata la mappatura degli oggetti CompositeBean e MapBean. In questocaso si verifichera quindi la loro serializzazione e deserializzazione.

Si riportano di seguito i listati di codice per ogni oggetto software pre-sentato. Si noti che il listato contiene solo le linee di codice interessanti cheforniscono indicazioni sul tipo di dato trattato e sulla sua mappatura versola base di dati. Non contengono quindi import, setters, getters, eventuali

35

metodi aggiuntivi.

SimpleBean

package it.nosql.tests;

@Embedded // simpleBean will be embedded in compositebean@Entity // this is an entity (see JPA specification)@Table(name = "SBCF", schema = "KunderaExamples@cassandra_pu") //

defines what ColumnFamily to use when loading and saving (ifomitted name of the class is used as the ColumnFamily)

public class SimpleBean implements Bean, Serializable {

@Idprivate UUID cassandraId;

@Column(name = "str")private String str;

@Column(name = "integer")private Integer integer;

public SimpleBean(int integer, String str) {this.integer = integer;this.str = str;

}

// setters, getters

}

36

CompositeBean

@Entity // signals the EntityManager to make the bean available forpersistence management

@Table(name = "CBCF", schema = "KunderaExamples@cassandra_pu") //defines what ColumnFamily to use when loading and saving (ifomitted name of the class is used as the ColumnFamily)

public class CompositeBean implements Bean, Serializable {

// MONGO -- ID ANNOTATION FROM MORPHIA LIBRARY@Idprivate ObjectId id;

// CASSANDRA -- ID ANNOTATIONS FROM [email protected] UUID cassandraId; // cassandra

@Column(name = "simplebean1")private SimpleBean simpleBean1;



public CompositeBean() {this.setSimpleBean1(new SimpleBean());this.setSimpleBean2(new SimpleBean());this.setSimpleBean3(new SimpleBean());

}

public SimpleBean getSimpleBean1() {return simpleBean1;

}

// setters, getters

}

37

MapBean

@Entity@Table(name = "MBCF", schema = "KunderaExamples@cassandra_pu") //

defines what ColumnFamily to use when loading and saving (ifomitted name of the class is used as the ColumnFamily)

public class MapBean implements Bean, Serializable {

// MONGO -- ID ANNOTATION FROM MORPHIA LIBRARY@Idprivate ObjectId id;

// CASSANDRA -- ID ANNOTATIONS FROM [email protected] UUID cassandraId; // cassandra

@Column(name = "SimpleBeanList")private List<SimpleBean> sbList;//@Column(name = "SimpleBeanMap") // -- UNSUPPORTED IN

CASSANDRA --private Map<String, SimpleBean> sbMap;

public MapBean() {}

// setters, getters

}

4.6 Significato dei test

Le caratteristiche delle tre entita software presentate nella sezione preceden-te sono state progettate per cercare di simulare l’interazione che avviene tralo strato applicativo e lo strato di persistenza, in riferimento allo scenario ealle problematiche delineate al Capitolo 1 e 2.

Sebbene gli oggetti software scelti siano semplici e di complessita minoredi quanto trattato in produzione dai software SOMO e modeFRONTIER,durante l’implementazione della logica dei workflow di simulazione, essi pos-sono venir considerati una prima approssimazione dei dati di progetto, adat-ta a verificare il validita di una soluzione di gestione basata su server NoSQL.

In particolare i POJO (Plain, Old, Java Objects) presi in considerazionepossono essere il risultato di una lettura dalla base di dati, quindi un input

38

o in generale un dato gia esistente, oppure un dato da salvare sulla base didati.

4.7 Metodologia

La metodologia di sperimentazione e le fasi che compongono un esperimentovengono ra�gurate, in modo informale, in Figura 9.

6WDUW�7HVW

6FHOWD�VHUYHU

&UHD]LRQH�GDWDVHW

'$7$6(7

6% &% 0%

6% &% 0%

6% &% 0%

��

(QWLW\�PDQDJHU

&ODVV�UHJLVWHUHU

6% &% 0%

SHUVLVW��6%

1R64/�VHUYHU

ZLUHG�/$1

EHIRUH� �FXUUHQW7LPH0LOOLV��

��

WLPH� �FXUUHQW7LPH0LOOLV��EHIRUH

&/,(17 6(59(5

6%

Figura 9: Rappresentazione informale della procedura di sperimentazione emisurazione implementata. In grigio sono rappresentati blocchi sviluppatiper il lavoro di tesi, in giallo parti software gia disponibili, API native delserver NoSQL o librerie di terze parti.

• inizio dell’esecuzione, con argomenti specificati dall’utente (numero dielementi da testare, tipo di operazione, scelta del server);

39

• creazione dell’insieme di test in base a quanto specificato dall’utente.La struttura utilizzata e una

Map<Class<? extends Bean>, List<Bean>>

dove Bean e una superclasse per SimpleBean, CompositeBean, Map-Bean. La mappa contiene quindi liste di istanze SimpleBean, Compo-siteBean, MapBean;

• registrazione delle classi sull’Entity Manager del driver per l’ObjectMapping della base di dati di riferimento;

• memorizzazione dell’entita Java nella base di dati, o altra operazione;

• rilevazione del tempo di esecuzione dell’operazione in base a coordinatedi tempo fornite da sistema operativo (System.currentTimeMillis());

• memorizzazione del risultato su file e su altra base di dati.

4.7.1 Rilevazione dei risultati

La metodologia di rilevazione dei risultati viene invece ra�gurata in Figura10. Come visualizzato in figura, viene creato un insieme di dati che contieneuna lista di istanze SimpleBean, una lista di istanze CompositeBean, unalista di istanze MapBean.

&%

��

&%

&%

&%

'$7$6(7

/,67

6%

6%

6%

6%

��

/,67

0%

��

0%

0%

0%

/,67

&%

��

&%

&%

&%

WLPHBVWDUW� �6\VWHP7LPHIRU�%HDQ�E�LQ�/LVW

SHUVLVW�E��ORDG�E��FUHDWH4XHU\�VHOHFW�IURP��ZKHUH��

HQGIRUWLPHBHQG� �6\VWHP7LPH��WLPHBVWDUW

Figura 10: Metodologia di rilevazione dei risultati.

Le liste sono utilizzate poi per ottenere gli oggetti su cui si eseguira, perciascuno, la chiamata della libreria che deve gestire la persistenza dell’ogget-to. Il tempo di rilevazione e il tempo totale per eseguire questa operazioneper tutti gli elementi della lista.

40

5 Analisi dei risultati

Si presentano in questo capitolo i risultati ottenuti nel corso della sperimen-tazione. Si ricordi che l’obiettivo dell’esperimento e verificare la validita diuna soluzione basata su tecnologia NoSQL in riferimento al contesto presen-tato al Capitolo 1 e alla problematica delineata al Capitolo 2.

Riassumendo, si vuole indagare l’e�cienza di basi di dati non relazionalinella gestione di dati trattati da workflow di simulazione. Per e�cienza siintende un concetto basato su due tipi di informazioni, che sono state rica-vate nel corso di ogni ripetizione dell’esperimento:

• un informazione misurabile, cioe il tempo di esecuzione delle operazionidi inserimento, lettura, cancellazione, aggiornamento di dati sulla basedi dati sperimentata;

• un informazione non misurabile, cioe la facilita di eseguire una mappa-tura tra campi dell’oggetto software preso in considerazione (con tipodi dato eterogeneo) e campi della base di dati.

In base al valore di queste due informazioni prese in esame verra ricavato:

una conclusione generale, presentata a chiusura dell’elaborato, sulla vali-dita dell’utilizzo della tecnologia NoSQL rispetto alla base di dati uti-lizzata nel contesto di riferimento (PostgreSQL, MySQL, OODBMS,Oracle, MSSQL Server);

una classifica di preferenza delle basi di dati prese in considerazione. Taleclassifica non vuole esprimere giudizi di merito in assoluto, ovveroapplicabili in ogni contesto, ma deve essere sempre rapportata alloscenario di riferimento.

5.1 Dati sperimentali

Vengono di seguito presentate le misure di dati sperimentali, con l’ausilio digrafici.

Si noti che, mentre per quanto riguarda le operazioni CRUD viene for-nita la rilevazione del tempo di esecuzione dell’operazione, nel caso dellamappatura di oggetto viene fornito un giudizio sulla facilita di mappatura,espresso utilizzando aggettivi.

Nei grafici, le ascisse corrispondono al numero di operazioni, mentre leordinate al tempo di esecuzione per concludere l’operazione di riferimento.

41

5.1.1 Inserimento

Vengono di seguito presentati i risultati ottenuti per l’operazione di inseri-mento. Si considerano quindi popolazioni di:

SimpleBean in Figura 11. Nonostante il comportamento delle tre basidi dati sia simile, si rileva come MongoDB o↵ra tempo di esecuzioneminore per questo tipo di operazione, per tipo di entita SimpleBean.

CompositeBean in Figura 12. La scrittura di CompositeBean nel serverOrientDB impiega un tempo nettamente maggiore rispetto a Mon-goDB, il migliore, e a Cassandra, vicina a MongoDB. La scrittura dientita composite e quindi penalizzante per OrientDB.

MapBean in Figura 13. Analogamente a quanto riportato per l’inseri-mento di CompositeBean, la scrittura di oggetti compositi MapBeane un’operazione onerosa in termini di tempo per OrientDB.

Figura 11: Inserimento nel database di SimpleBean.

42

Figura 12: Inserimento nel database di CompositeBean.

Figura 13: Inserimento nel database di MapBean.

43

5.1.2 Lettura

Analogamente alla presentazione dei risultati di scrittura, si considerano perla lettura popolazioni di:

SimpleBean in Figura 14. Il tempo di lettura per OrientDB e nettamentesuperiore rispetto a Cassandra e MongoDB. Per 100000 elementi iltempo di OrientDB e maggiore fino a 20 ordini di grandezza rispettoa MongoDB, il migliore anche in questo test.

CompositeBean in Figura 15. La lettura di CompositeBean, analoga-mente alla scrittura, e penalizzante per OrientDB. Per questo databa-se si osservano risultati discontinui per letture di popolazioni superioria 60000 elementi.

MapBean in Figura 16. La lettura di MapBean e onerosa per OrientDB.Il comportamento di Cassandra e MongoDB e invece quasi identicofino a 100000 elementi (circa 7 secondi per leggere 100000 elementi).

Figura 14: Lettura di SimpleBean.

44

Figura 15: Lettura di CompositeBean.

Figura 16: Lettura di MapBean.

45

5.1.3 Lettura con selezione

Si presentano qui i risultati di letture con selezione. Per selezione si intendeuna operazione di filtraggio, eseguita sul campo Integer presente in istan-ze della classe SimpleBean. Tale numero intero assume un valore casualesull’intervallo 0 - RANDOMINTERVAL, dove RANDOMINTERVAL e paria 1000000. Il filtro seleziona in particolare SimpleBean con valori di Inte-ger minori di RANDOMINTERVAL/2. L’operazione di filtraggio dovrebbequindi restituire una popolazione di circa N/2 elementi, dove N e il numerodi elementi considerato.

Si noti che l’operazione e di particolare interesse nello scenario di riferi-mento, dove e usuale porre condizioni nelle interrogazioni eseguite su datidi progetto nei workflow di simulazione (ad esempio selezione di design conparticolari caratteristiche).

Questa operazione e e↵ettuata in modo diverso su ogni base di dati.Nonostante l’obiettivo di ogni libreria di object mapping sia implementare lespecifiche JPA (Java Persistence API), non e standard il metodo di selezionecon filtro. Le diversita vengono presentate come segue (vengono spezzate lelinee di codice per comodita di lettura):

MongoDB - libreria Morphia per object mapping - espone un metodocreateQuery (argomento java.lang.Class , in questo caso SimpleBean)utilizzato nel seguente modo (il metodo ritorna una lista):

// The Datastore interface provides type-safe methods

// for accessing and storing your java objects in MongoDB.

// It provides get/find/save/delete

// methods for working with your java objects.

// dsSave is a Datastore object

dsSave.createQuery(clazz).

filter("integer >=", Test.RANDOMINTERVAL/2));

OrientDB - libreria nativa per object mapping - utilizza il seguente co-struttore:

new OSQLSynchQuery<Bean>

("select * from SimpleBean where integer > " +

Test.RANDOMINTERVAL / 2));

Cassandra - libreria Kundera per l’object mapping - espone un metodocreateQuery utilizzato nel seguente modo:

46

// em is an EntityManager

Query q =

em.createQuery("Select sb from SimpleBean sb +

where sb.str = stringa and " +

sb.integer > " + Test.RANDOMINTERVAL / 2);

In Figura 17 vengono visualizzati i risultati ottenuti. MongoDB con-ferma i tempi di esecuzione ottenuti nelle operazioni precedenti (1 secondocirca per leggere con filtro su una popolazione di 100000 valori). Si notiche in questo caso OrientDB e nettamente piu veloce nel tempo di rispo-sta di Cassandra. Questo potrebbe essere dovuto al driver Java nativo diOrientDB per l’object mapping. Cassandra utilizza Kundera, che e una li-breria utilizzabile per eseguire object mapping anche su altre basi di datiNoSQL, quindi meno specializzata.

Figura 17: Lettura di SimpleBean con selezione della popolazione.

47

5.1.4 Mappatura dei campi delle entita

La Figura 18 mostra come i di↵erenti database NoSQL implementano lamappatura di diversi tipi di entita Java. A sinistra riporta i tipi di entitaconsiderata ed i campi di ciascuna entita, mentre a destra riporta le APIper la mappatura degli oggetti e come ciascuna base di dati gestisce i campirelativi a quell’entita.


• in MongoDB e in OrientDB sono state utilizzate le API native dei ri-spettivi software per eseguire la mappatura degli oggetti, in Cassandrasono state utilizzate le API del progetto Kundera;

• e da prendere in considerazione anche la presenza o meno di annotazio-ni (Annotations, relative alle specifiche JPA) per gestire la mappatura:queste sono obbligatorie esclusivamente in Cassandra.

(QWLWj )LHOG &DVVDQGUD 0RQJR'% 2ULHQW'%

6LPSOH%HDQ ,QWHUR 6XSSRUWDWR�H�FRUUHWWDPHQWH�PDSSDWR6WULQJD

&RPSRVLWH%HDQ 6LPSOH%HDQ 6HTXHQ]D�GL�E\WH6XSSRUWDWR�H�FRUUHWWDPHQWH�PDSSDWR

0DS%HDQ 0DS�6WULQJ��6LPSOH%HDQ! 1RQ�VXSSRUWDWR

Figura 18: Facilita di mappatura delle entitita considerate per i tre serverNoSQL.

Come si osserva dalla Figura 18, non si e potuto procedere alla map-patura di implementazioni di Map su Cassandra. Queste non sono infattisupportate dalla libreria di object mapping Kundera. Al momento di spe-rimentare Cassandra si e quindi istanziato un oggetto di tipo ArrayList inluogo di HashMap, che e stato invece utilizzato in MongoDB e OrientDB.

Si riporta di seguito un esempio di come sono state mappate le entita suuna base di dati di riferimento (MongoDB):

48

> db.SimpleBean.find().pretty()

{"_id" : ObjectId("5139c208d7a824424727f2ec"),"className" : "it.nosql.tests.SimpleBean","str" : "Mar 8, 2013 11:48:40 AM","integer" : 18576

}

> db.CompositeBean.find().pretty()

{"_id" : ObjectId("5139c208d7a824424727f2f6"),"className" : "it.nosql.tests.CompositeBean","simpleBean1" : {

"str" : "Mar 8, 2013 11:48:40 AM","integer" : 595737

}}

> db.MapBean.find().pretty()

{"_id" : ObjectId("5139c208d7a824424727f300"),"className" : "it.nosql.tests.MapBean","sbMap" : {

"simpleBeanKey" : {"str" : "Mar 8, 2013 11:48:40 AM","integer" : 511189

}}

}

49

5.2 Analisi riassuntiva dei risultati

Viene di seguito presentata una analisi conclusiva dei risultati dell’esperi-mento.

Relativamente alle misure sperimentali del tempo necessario a concluderele operazioni di creazione, lettura, aggiornamento e cancellazione:

MongoDB e la base di dati che ha impiegato il minor tempo a compiere leoperazioni in oggetto, su tutti i tipi di elementi. E’ risultata partico-larmente e�ciente in lettura e in lettura con selezione. Quest’ultimaoperazione e di grande interesse nell’ambito di riferimento, poiche l’in-terrogazione della base di dati viene avviata solitamente da un utenteche pone un filtro ai risultati che vuole ottenere;

Cassandra e risultata essere una base di dati meno rapida di MongoDB;

OrientDB e la base di dati che ha impiegato il maggior tempo di esecuzio-ne per le operazioni considerate. Mentre per l’operazione di creazionequesto tempo non e sensibilmente di↵erente dai rimanenti server No-SQL, per cio che riguarda la lettura i tempi di discostano enormemente(20 ordini di grandezza di di↵erenza).

Con riferimento invece alla facilita di mappatura di un oggetto verso unacerta base di dati, si conclude che:

Cassandra e la base di dati piu problematica da gestire per eseguire unamappatura soddisfacente. In particolare non supporta la mappaturadi implementazioni di Java Map, motivo per il quale l’oggetto Map-Bean, durante i test su Cassandra, e stato sempre istanziato con uncostruttore che prevedesse la creazione di un’implementazione di List;

OrientDB e MongoDB sono risultati migliori per la mappatura di oggetti,supportando tutti i tipi di dato proposto.

Con riferimento a questi ultimi giudizi si ricordi che sono relativi allalibreria di mappatura utilizzata, non esclusivamente alla base di dati.

Si aggiungono inoltre considerazioni di minore importanza, ma che pos-sono pesare nella scelta di una base di dati per eseguire ulteriori test. Questesono:

• la facilita di installazione di una base di dati, su diversi sistemi ope-rativi: OrientDB si e dimostrato uno dei server di piu immediatainstallazione;

50

• la possibilita di creare un ambiente distribuito su piu nodi, tolleranteai guasti, che possa scalare linearmente: sebbene di piu complessagestione rispetto a MongoDB e OrientDB, Cassandra e il server chepresenta piu caratteristiche in questo contesto;

• la possibilita di alterare lo schema dei dati, in qualsiasi momento,a livello applicativo: OrientDB puo elaborare dati in modalita senzaschema (schema-less), con schema alla pari dei RDBMS (schema-full),in modalita mista (schema-mixed).

51

Conclusioni

Nell’elaborato sono state argomentate le problematiche che i RDBMS tra-dizionali devono a↵rontare nella gestione di dati scarsamente strutturati,prendendo come caso di studio la gestione di dati di progetto utilizzati inworkflow di simulazione.

Nel Capitolo 1 e stato presentato lo scenario, mentre nel Capitolo 2 estato descritto come i dati generati da workflow di simulazione siano estre-mamente eterogenei e non necessariamente relazionati.

Nel Capitolo 3 si e descritto come tale problema non sia circoscritto alloscenario dei workflow di simulazione, ma sia tipico delle situazioni in cuii dati da gestire non siano ne densi ne largamente uniformi, e che inoltrele proprieta dei dati e le loro relazioni non siano definibili a priori. Questeproblematiche, comuni a molti scenari, hanno determinato l’emergere di unanuova classe di database specializzati, il cui punto in comune e l’assenza delmodello relazionale.

Il Capitolo 4 ha introdotto la sperimentazione e↵ettuata sulle tecnologienon relazionali, che hanno fornito gli esiti descritti nel Capitolo 5.

Il lavoro di tesi ha quindi fornito la possibilita di valutare la validita dialcune tecnologie NoSQL nello scenario di riferimento. La sperimentazioneha prodotto diversi risultati, una parte dei quali sono stati presentati nelCapitolo 5.

In base a tali risultati si ritiene che la base di dati MongoDB e quellache, in ulteriori test, dovrebbe venir presa in considerazione come tecnologiadi gestione di dati di progetto in workflow di simulazione.

A chiusura dell’elaborato si vogliono presentare gli sviluppi futuri cuitale lavoro puo andare incontro:

• una valutazione comparativa diretta, in termini di tempo di esecuzioneper le operazioni piu comuni, tra tecnologie NoSQL e RDBMS nellagestione dei dati di progetto;

• una sperimentazione che si concentri verso altri tipi di dati (ad esempiofile e oggetti binari);

• una sperimentazione che valuti come e fino a che punto lo schema deidati puo essere modificato a livello applicativo;

• lo sviluppo di un modulo aggiuntivo per modeFRONTIER o SOMOper fornire al livello applicazione uno strato di persistenza basato sutecnologia NoSQL.

52

Riferimenti bibliografici

[1] Cassandra home page, http://cassandra.apache.org .

[2] Couchdb home page, http://couchdb.apache.org/ .

[3] Mongodb home page, http://www.mongodb.org/ .

[4] Orientdb home page, http://www.orientdb.org/ .

[5] Redis.io home page, http://www.redis.io .

[6] Maxmiliano Franco BRAGA and Fabio Nogueira de LUCENA. Usingnosql database to persist complex data objects. CONGRESSO DEPESQUISA, ENSINO E EXTENSAO - CONPEEX 2011, 2011.

[7] Fay Chang, Je↵rey Dean, Sanjay Ghemawat, Wilson C Hsieh, Debo-rah A Wallach, Mike Burrows, Tushar Chandra, Andrew Fikes, andRobert E Gruber. Bigtable: A distributed storage system for struc-tured data. Proceedings of the 7th USENIX Symposium on OperatingSystems Design and Implementation OSDI’06, 26(2):1–26, 2006.

[8] Evin J. Cramer, Evin J. Cramer, Jr., J. E. Dennis, J. E. Dennis, Paul D.Frank, Paul D. Frank, Robert Michael Lewis, Robert Michael Lewis,Gregory R. Shubin, and Gregory R. Shubin. Problem formulation formultidisciplinary optimization. SIAM Journal on Optimization, 4:754–776, 1993.

[9] ESTECO. Esteco, multiobjective optimization in engine design,http://goo.gl/hyzpi .

[10] Neal Leavitt. Will nosql databases live up to their promise? Computer,43(2):12–14, 2010.

[11] Oracle. Javabeans specs, oracle documentation, http://goo.gl/7ueun .

[12] Kai Orend. Analysis and classification of nosql databases and evaluationof their ability to replace an object-relational persistence layer. Fakultatfur Infoormatik, Technische Universitat Munchen, 2010.

[13] Wikipedia page. Bigtable, http://en.wikipedia.org/wiki/bigtable .,2011.

[14] Onofrio Panzarino. I database nosql, http://goo.gl/2juqr ., 2011.

[15] Dan Pritchett. Base an acid alternative. Queue, 6(June 2008):48–55,2008.

53

[16] Rosario Russo, Enrico Nobile Alberto Clarich Esteco Spa Padriciano99 Trieste Italy 34149, and Via Valerio 10 Trieste Italy 34127 CarloPoloni Universita di Trieste. Optimization of a boomerang shape usingmodefrontier. 12th AIAA Aviation Technology, Integration, and Ope-rations (ATIO) Conference and 14th AIAA/ISSM 17 - 19 September2012, Indianapolis, Indiana, 2012.

[17] Aaron Schram and Kenneth M. Anderson. Mysql to nosql: data mo-deling challenges in supporting scalability. In Proceedings of the 3rdannual conference on Systems, programming, and applications: soft-ware for humanity, SPLASH ’12, pages 191–202, New York, NY, USA,2012. ACM.

[18] Nati Shalom. No to sql? anti-database movement gains steam,http://goo.gl/nkta4 ., 2009.

[19] M Stonebraker, S Madden, D J Abadi, S Harizopoulos, N Hachem, andP Helland. The end of an architectural era:(it’s time for a completerewrite). DBMS, 12(2):1150–1160, 2007.

[20] Christof Strauch, Ultra-Large Scale Sites, and Walter Kriha. Nosqldatabases. Lecture Notes, Stuttgart Media University, 2011.

[21] Carlo Strozzi. Nosql ? a relational database management system,http://goo.gl/gghku ., 2007-2010.

[22] Zhu Wei-ping, Li Ming-xin, and Chen Huan. Using mongodb to im-plement textbook management system instead of mysql. In Communi-cation Software and Networks (ICCSN), 2011 IEEE 3rd InternationalConference on, pages 303–305, May.

[23] Tom White. Hadoop: The definitive guide. O’Reilly Media, 2012.

54

Valutazione sperimentale di tecnologie per la gestione dei dati per workflow scientifici

Technology

Transcript of Valutazione sperimentale di tecnologie per la gestione dei dati per workflow scientifici