1. UNIVERSITA’ DEGLI STUDI DI TRIESTE
DIPARTIMENTO 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

3. Indice
Introduzione 4
1 Scenario 7
1.1 I workflow di simulazione . . . . . . . . . . . . . . . . . . . . 7
1.2 Caratteristiche dei dati trattati . . . . . . . . . . . . . . . . . 8
1.3 Ottimizzazione multiobiettivo . . . . . . . . . . . . . . . . . . 8
1.4 Casi d’uso . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
1.4.1 Ottimizzazione di traiettoria . . . . . . . . . . . . . . 10
2 Analisi della problematica 13
2.1 Gestione dei dati . . . . . . . . . . . . . . . . . . . . . . . . . 13
2.2 Problematiche nella gestione di dati . . . . . . . . . . . . . . 14
2.3 Ipotesi di soluzione . . . . . . . . . . . . . . . . . . . . . . . . 16
2.4 Related works . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
3 Le tecnologie NoSQL 18
3.1 Definizione . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
3.2 Limitazioni del modello relazionale . . . . . . . . . . . . . . . 18
3.2.1 Da ACID a BASE . . . . . . . . . . . . . . . . . . . . 19
3.2.2 Scalabilit` del modello relazionale . .
a . . . . . . . . . 19
3.2.3 Scalabilit` verticale . . . . . . . . . .
a . . . . . . . . . 20
3.3 Caratteristiche dell’approccio non relazionale . . . . . . . . . 21
3.3.1 Scalabilit` orizzontale . . . . . . . . .
a . . . . . . . . . 21
3.3.2 Mappature tra oggetti e relazioni . . . . . . . . . . . . 22
3.3.3 Prestazioni ma non a dabilit` . . . .
a . . . . . . . . . 22
3.4 Modelli di dati . . . . . . . . . . . . . . . . . . . . . . . . . . 22
3.4.1 Orientati alle colonne . . . . . . . . . . . . . . . . . . 22
3.4.2 Chiave/valore . . . . . . . . . . . . . . . . . . . . . . . 23
3.4.3 Orientati ai documenti . . . . . . . . . . . . . . . . . . 23
3.5 Orientarsi nella scelta . . . . . . . . . . . . . . . . . . . . . . 23
4 Sperimentazione 25
4.1 Obiettivo della sperimentazione . . . . . . . . . . . . . . . . . 25
4.2 Strumento di sperimentazione . . . . . . . . . . . . . . . . . . 26
4.3 Individuare i candidati . . . . . . . . . . . . . . . . . . . . . . 26
4.3.1 OrientDB . . . . . . . . . . . . . . . . . . . . . . . . . 28
4.3.2 MongoDB . . . . . . . . . . . . . . . . . . . . . . . . . 29
4.3.3 Cassandra . . . . . . . . . . . . . . . . . . . . . . . . . 31
4.4 Implementazione . . . . . . . . . . . . . . . . . . . . . . . . . 32
4.4.1 Pianificazione . . . . . . . . . . . . . . . . . . . . . . . 32
4.4.2 Strumenti hardware . . . . . . . . . . . . . . . . . . . 34
4.4.3 Strumenti software . . . . . . . . . . . . . . . . . . . . 34
1

4. 4.4.4 Interconnessione . . . . . . . . . . . . . . . . . . . . . 35
4.5 Struttura dei test . . . . . . . . . . . . . . . . . . . . . . . . . 35
4.6 Significato dei test . . . . . . . . . . . . . . . . . . . . . . . . 38
4.7 Metodologia . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
4.7.1 Rilevazione dei risultati . . . . . . . . . . . . . . . . . 40
5 Analisi dei risultati 41
5.1 Dati sperimentali . . . . . . . . . . . . . . . . . . . . . . . . . 41
5.1.1 Inserimento . . . . . . . . . . . . . . . . . . . . . . . . 42
5.1.2 Lettura . . . . . . . . . . . . . . . . . . . . . . . . . . 44
5.1.3 Lettura con selezione . . . . . . . . . . . . . . . . . . . 46
5.1.4 Mappatura dei campi delle entit` a . . . . . . . . . . . . 48
5.2 Analisi riassuntiva dei risultati . . . . . . . . . . . . . . . . . 50
Conclusioni 52
Bibliografia 53
Elenco delle figure
1 Il workflow di simulazione ` una funzione matematica che
e
riceve in ingresso le variabili decisionali e restituisce in uscita
le variabili di risposta. . . . . . . . . . . . . . . . . . . . . . . 7
2 Il workflow di simulazione ` una funzione matematica che
e
riceve in ingresso le variabili decisionali e restituisce in uscita
le variabili di risposta. . . . . . . . . . . . . . . . . . . . . . . 10
3 Traiettoria ottimizzata del boomerang. . . . . . . . . . . . . . 11
4 Rappresentazione del workflow principale. . . . . . . . . . . . 12
5 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 localit` dei dati (database
a
distribuito su pi` nodi - database non distribuito). . . . . . .
u 24
6 Le caratteristiche principali dei tre candidati server NoSQL.
CRUD ` abbreviazione per Create, Read, Delete, Update,
e
cio` le operazioni di creazione, lettura, cancellazione, aggior-
e
namento. OM ` abbreviazione per Object Mapping, cio`
e e
mappatura di oggetto. . . . . . . . . . . . . . . . . . . . . . . 27
7 Proposta di mappatura tra query SQL nel RDBMS MySQL e
linea di comando JavaScript utilizzata nell’interrogazione in
MongoDB. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
8 Sistema di visualizzazione dei risultati. . . . . . . . . . . . . . 33
2

5. 9 Rappresentazione informale della procedura di sperimentazio-
ne e misurazione implementata. In grigio sono rappresentati
blocchi sviluppati per il lavoro di tesi, in giallo parti software
gi` disponibili, API native del server NoSQL o librerie di terze
a
parti. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
10 Metodologia di rilevazione dei risultati. . . . . . . . . . . . . . 40
11 Inserimento nel database di SimpleBean. . . . . . . . . . . . . 42
12 Inserimento nel database di CompositeBean. . . . . . . . . . 43
13 Inserimento nel database di MapBean. . . . . . . . . . . . . . 43
14 Lettura di SimpleBean. . . . . . . . . . . . . . . . . . . . . . 44
15 Lettura di CompositeBean. . . . . . . . . . . . . . . . . . . . 45
16 Lettura di MapBean. . . . . . . . . . . . . . . . . . . . . . . . 45
17 Lettura di SimpleBean con selezione della popolazione. . . . . 47
18 Facilit` di mappatura delle entitit` considerate per i tre server
a a
NoSQL. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48
3

6. Introduzione
L’argomento di questo lavoro di tesi ` la gestione dei dati generati in work-
e
flow scientifici. In particolare si a↵rontano le problematiche connesse alla
scelta dello strato di persistenza dove vengono memorizzati dati prodotti da
progetti di simulazione.
Lo scenario preso in considerazione ` stato proposto da Esteco S.p.A.,
e
societ` insediata presso AREA Science Park, Padriciano, Trieste, dove `
a e
stata svolta la tesi. I sistemi software che Esteco o↵re sul mercato consen-
tono l’ottimizzazione multiobiettivo tramite workflow di simulazione, cio` e
l’esecuzione di un processo automatico che minimizzi o massimizzi una serie
di funzioni obiettivo sulle quali sono stati posti dei vincoli. Tale approccio
trova 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 di
simulazione. 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 tramite
RDBMS (Relational Data Base Management System) risulta non soddisfa-
cente per quanto concerne:
• la mappatura di oggetti software da strato applicativo a strato di
persistenza;
• la memorizzazione di tipi di dati eterogenei (file binari, CAD, video,
ecc.);
• la memorizzazione di dati scarsamente strutturati o non strutturati;
• l’impossibilit` di definire a priori uno schema fisso, poich´ non ` nota
a e e
a priori la struttura dei dati.
Ipotesi della tesi ` che, in riferimento all’ambito sopra descritto, il mo-
e
dello relazionale non sia il migliore possibile.
Obiettivo del lavoro ` quindi verificare le alternative ai RDBMS utilizzati
e
per gestire la persistenza dei dati provenienti dalle simulazioni. In partico-
lare sono stati sottoposti a indagine i database definiti NoSQL (Not Only
Structured Query Language), che si basano generalmente su un modello di
dati non relazionale.
4

7. Oggetto dell’indagine ` stata la gestione della persistenza e l’interroga-
e
zione di entit` software su tali database non relazionali. I termini utilizzati
a
per verificare la qualit` di un database non relazionale sono stati:
a
• il tempo di esecuzione necessario a completare le operazioni di inseri-
mento, lettura, aggiornamento, cancellazione;
• la possibilit` di eseguire mappature definite dall’utente sugli entit`
a a
software, cio` definire come viene trasferita l’informazione dal livello
e
applicativo allo strato di persistenza;
• la possibilit` di modificare lo schema di un database a livello applica-
a
tivo.
L’esperimento consta delle seguenti fasi:
• analisi dello scenario di riferimento, della problematica, dello stato
dell’arte;
• studio di soluzioni alternative per la risoluzione della problematica;
• sperimentazione su architettura client-server di tre candidati server
NoSQL;
• verifica e analisi dei risultati.
Il linguaggio di programmazione utilizzato ` Java, che ` il linguaggio
e e
usato all’interno di Esteco per lo sviluppo delle applicazioni prodotte.
Il risultato atteso ` un contributo alla conoscenza di Esteco relativamente
e
all’argomento delle basi di dati non relazionali. Nel concreto, lo strumento
software progettato non costituir` un elemento da aggiungere alla produzio-
a
ne attuale dell’azienda, ma o↵rir` la possibilit` di verificare alternative alla
a a
gestione di dati di progetto tramite RDBMS.
Il Capitolo 1 dell’elaborato ` incentrato sulla descrizione dello scenario.
e
Viene qui a↵rontato il concetto di workflow di simulazione.
Il Capitolo 2 ` una analisi delle problematiche di memorizzazione dei
e
dati di workflow di simulazione.
Il Capitolo 3 ` un’analisi delle caratteristiche principali delle tecnologie
e
NoSQL.
Il Capitolo 4 ` dedicato alle motivazioni che supportano la scelta dei
e
candidati server NoSQL selezionati per la sperimentazione.
5

8. Nel Capitolo 5 viene discusso l’esperimento condotto e i risultati da esso
prodotti, grazie all’ausilio di grafici e tabelle.
Chiudono l’elaborato considerazioni generali sul successo dell’esperimen-
to e sugli sviluppi futuri.
6

9. 1 Scenario
1.1 I workflow di simulazione
Il problema che l’elaborato di tesi a↵ronta ` relativo alla gestione di dati
e
nell’ambito di simulazioni nel campo della progettazione assistita al calco-
latore (CAE, Computer Aided Engineering).
Tali applicazioni sono, in informatica, software che agevolano la risoluzione
di problemi tecnologici tramite il calcolo numerico. Molti problemi dell’in-
gegneria sono descrivibili da equazioni che possono essere risolte con l’ausilio
di programmi CAE. Si citano ad esempio le simulazioni analogiche e digitali
di circuiti elettronici e il calcolo statico o dinamico di strutture in ingegneria
civile o meccanica.
Descrizione del problema
In particolare verr` discussa e a↵rontata la gestione dei dati di progetto
a
associati a workflow di simulazione definiti mediante software CAE, dove
Il problema è relativo alla gestione di dati di progetto nell’ambito delle applicazioni CAE
per progetto si intende un’entit` composta come segue:
a
(Computer Aided-­Engineering).
• un modello matematico del sistema da simulare (workflow di simula-
Un progetto è composto da:
zione, o f);
• variabili decisionali in ingresso (decision variables, o x)
● 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).
● variabili di risposta (response variables, o y)
Viene inoltre definito design la tupla che contiene i valori delle variabili decisionali e delle
Figura 1: Il workflow di simulazione ` una funzione matematica che riceve in
e
corrispondenti risposte. E’ possibile riferirsi al workflow di simulazione come ad una funzione
ingresso le variabili decisionali e restituisce in uscita le variabili di risposta.
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 Vieneèinoltre definito design la tupla che contiene i valori delle variabiliai workflow di
tesi lo studio della gestione della persistenza dei dati associati
decisionali e delle corrispondenti risposte.
simulazione, all’interno di un sistema per la gestione del ciclo di vita di tali workflow.
Come si evince dalla Figura 1 ` possibile riferirsi al workflow di simula-
e
I componenti dei vettori di input e output possono essere di tipi eterogenei:
zione come ad una funzione f(x)=y con x e y vettori rispettivamente di input
output. Il workflow di simulazione ` quindi una funzione di trasferimento
e
● 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.) 7
● 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.

10. che opera sui valori delle variabili in ingresso, cio` sullo spazio decisiona-
e
le da esplorare, per ottenere i valori calcolati delle variabili in uscita. Lo
studio del modello matematico e delle sue caratteristiche non ` oggetto di
e
trattazione 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..
Si noti inoltre che:
La struttura dei dati, analogamente a quelle delle relazioni, pu` non es-
o
sere nota a priori.
Le relazioni tra ingresso e uscita non sono note a priori, ogni workflow di
simulazione ` creato dall’utente e ha un insieme di↵erente di variabili
e
decisionali e di risposta.
Nuove versioni di uno stesso workflow di simulazione possono portare
modifiche alle relazioni esistenti, o rimozione di variabili.
Una variabile decisionale pu` essere vincolata ad assumere valori su un
o
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.
1.3 Ottimizzazione multiobiettivo
All’interno dell’azienda dove ` stato svolto il lavoro di tesi, Esteco, vengono
e
sviluppati il software modeFRONTIER e il software SOMO.
modeFRONTIER ` un software per l’ottimizzazione multidisciplinare
e
[8] e multiobiettivo che pu` essere accoppiato a qualsiasi strumento per
o
l’ingegneria assistita al calcolatore (CAE). SOMO (Service Oriented Mul-
tidisciplinary Orchestration) ` una piattaforma web che supporta la ge-
e
stione della complessit` delle simulazioni multidisciplinari, organizzando ed
a
orchestrando dati e workflow di simulazione.
8

11. Obiettivo comune di entrambi ` fornire uno strumento per l’ottimizza-
e
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 le
quali non esiste nessuna soluzione che sia migliore contemporaneamente per
tutti gli obiettivi considerati nella procedura di ottimizzazione. Pu` essere
o
considerato come un compromesso sulle varie funzioni obiettivo. Tali so-
luzioni rappresentano inoltre l’insieme di output atteso da un algoritmo di
ottimizzazione multiobiettivo.
In molti campi dell’ingegneria si presentano problemi con obiettivi mul-
tipli, soggetti a vincoli specifici. I classici metodi di ottimizzazione sono
generalmente non applicabili a causa della conflittualit` degli obiettivi di
a
progetto: questo classe di problemi ` generalmente conosciuta come MDCM
e
(MultiCriteria Decision Making). I problemi MCDM vengono comunemente
risolti tramite una procedura di ottimizzazione, che nel caso di due o pi` u
obiettivi in conflitto simultaneamente e soggetti a determinati vincoli viene
chiamata Ottimizzazione Multiobiettivo.
Gli algoritmi di ottimizzazione trovano i punti proprio sulla frontiera di
Pareto. Si noti inoltre che la selezione di un punto del fronte di Pareto,
opzione comunemente preferita, richiede un livello di conoscenza maggiore
di quello o↵erto dalle funzioni obiettivo. Per operare tale decisione ` neces-
e
saria una figura professionale (Decision Maker), il cui operato si inserisce
nel processo di decisione come rappresentato in Figura 2, che abbia una
comprensione profonda del problema e che possa esprimere preferenze sulle
diverse soluzioni.
Il decision maker, il cui contributo ` necessario per risolvere un problema
e
MCDM, ` aiutato nella scelta da strumenti di supporto alle decisioni, quali
e
il 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 pu` o
portare all’esplorazione dello spazio del progetto con la generazione di cen-
tinaia di migliaia di design. Una situazione analoga si pu` presentare con
o
problemi mono-obiettivo in presenza di numerosi vincoli, per i quali spesso
non ` possibile trovare neanche un design ammissibile.
e
9

12. Figura 2: Il workflow di simulazione ` una funzione matematica che riceve in
e
ingresso 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 azoto
e 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 viene
applicata una forza all’estremit` libera. Problema di ottimizzazione
a
multiobiettivo che coinvolge nove parametri di input, quattro output
e due funzioni obiettivo;
Viene di seguito approfondito un caso d’uso relativo ad un ottimizzazione
ingegneristica 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

13. 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; `
e
considerato come un vincolo durante l’ottimizzazione.
Precisione (accuracy), ovvero la di↵erenza tra la posizione di lancio del
boomerang e la posizione in cui arriva (questa quantit` ` ottimizzata
ae
dal processo interno per ogni soluzione candidata).
Energia (energy): rappresenta l’energia (traslazionale pi` rotazionale) ne-
u
cessaria per lanciare il boomerang, ed ` una quantit` da minimizzare
e a
(per evitare eccessivi sforzi per il lanciatore).
In Figura 4 viene ra gurato il workflow dell’intero processo. Di seguito
si riporta una descrizione concisa degli elementi principali presenti:
Il riquadro verde in alto rappresenta i nodi che definirono il range di
variazione di tutti i parametri. Le linee scure centrali rappresentano
il flusso di processo.
11

14. Il task CAD model costituisce l’interfaccia al programma di CAD che
modifica il modello al variare dei parametri.
Il modo make mesh crea la griglia su cui rappresentare il modello, per
ogni geometria proposta.
La mesh cos` generata viene fornita al nodo successivo, che esegue in batch
ı
un ulteriore progetto modeFRONTIER.
Il nodo create Matlab crea un file RSM (.mex) ed infine viene invocato
un ultimo nodo modeFRONTIER, sempre in modalit` batch (launch
a
parameters tuning), che accetta come input i quattro parametri di
lancio.
Figura 4: Rappresentazione del workflow principale.
La geometria del boomerang ` stata quindi fissata e l’obiettivo ` definito
e e
dalla minimizzazione della distanza tra la posizione di arrivo e quella di
lancio. Per questo scopo viene utilizzato un algoritmo mono-obiettivo, ed il
progetto esegue uno script Matlab per ogni configurazione dei parametri di
lancio.
12

15. 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 caratteristiche
dei dati e sul loro utilizzo, verr` proposta un’ipotesi di soluzione.
a
I vincoli a cui tale soluzione ` sottoposta emergono direttamente dal-
e
le caratteristiche dei dati considerati: verranno quindi prese in considera-
zione soluzioni che garantiscano la migliore e cienza nella gestione della
persistenza dei dati utilizzati e prodotti da workflow di simulazione.
In tale contesto il significato di e cienza dipender` dal tempo di esecu-
a
zione necessario a gestire le operazioni pi` comuni eseguite sulla base di dati,
u
nonch´ dalla facilit` di mappatura di oggetti Java dal livello applicativo alla
e a
base di dati [11].
Verranno quindi trattate metodologie alternative per gestire la persi-
stenza dei dati di workflow di simulazione. La ricerca di alternative sar` a
sottoposta a vincoli che emergono dalle caratteristiche dei dati e dai vin-
coli individuati nelle sezioni successive. Vengono poi proposte ipotesi di
soluzione del problema.
2.1 Gestione dei dati
Viene di seguito descritta la gestione dei dati operata dai software sviluppati
da Esteco, attualmente gestita attraverso RDBMS e da OODBMS (Object
Oriented 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 pu` essere interpretato
o
come una funzione complessa, avente:
• n variabili di input;
• m variabili di output.
Il tipo di dato di una variabile ` generico. Pu` essere numerico, stringa,
e o
una struttura complessa, un array multidimensionale, un Uniform Resource
Identifier, un file, ecc.
Il significato di ogni variabile ` completato da metadati, di tipo generico,
e
che per tipi numerici possono ad esempio rappresentare il dominio di una
variabile che nel caso numerico pu` essere rappresentato dal limite inferiore,
o
superiore, etc..
13

16. Il workflow di simulazione di per s´ si limita a definire come le variabi-
e
li decisionali vengono trasformate in risposte del sistema, ma un problema
di ottimizzazione contiene anche la definizione di vincoli e obiettivi. Que-
sti ultimi sono considerati ulteriori variabili, e sono calcolati a partire dalle
variabili gi` introdotte, in base ad una espressione fornita dall’utente. L’e-
a
spressione utilizzata per calcolare l’obiettivo o il vincolo ` esso stesso un
e
metadato.
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 spazio
decisionale iniziale che dovr` essere esplorato.
a
2. Design-DB, che contiene i design, cio` le tulle comprendenti input e
e
output calcolati dal modello sulla base degli stessi. Contiene inoltre
obiettivi e vincoli associati.
Si noti inoltre che:
• gli input sono replicati nei due database;
• obiettivi e vincoli sono calcolati in fase di valutazione e salvati come
campi 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 design
corretto oppure su un design errato perch´ qualche vincolo non ` stato ri-
e e
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 precedente
e dalla Sezione 1.3.
Riassumendo le indicazioni ottenute nelle sezioni precedenti, si conclu-
de che i dati trattati dai workflow di simulazione possiedono le seguenti
caratteristiche:
14

17. Volume considerevole dei dati in gioco: l’ottimizzazione multiobietti-
vo opera su grandi quantitativi di dati (migliaia, milioni di valori
numerici) per produrne altrettanti.
Scarsa struttura dei dati considerati: i dati prodotti sono semi-strutturati
o non-strutturati, quindi di cili da relazionale tra loro. Per una defini-
zione di non-struttura dei dati si rimanda al Capitolo 3, dove vengono
descritte le tecnologie NoSQL.
Eterogeneit` di tipo di dato: vengono trattati dati di tipo JSON, binari,
a
CAD, JPEG, video, composti, ecc.
Variabilit` nella loro numerosit`, tipizzazione, tempo di vita.
a a
Assunte come tali le caratteristiche dei dati, si determinano come segue
le di colt` incontrate nell’utilizzo di un RDBMS:
a
Scalabilit` del volume di dati considerato: un RDBMS ` un software che
a e
` di cilmente scalabile orizzontalmente, quindi poco adatto a gestire
e
volumi di dati considerevoli. Per un approfondimento del concetto di
scalabilit` si rimanda alla Sezione 3.1 del Capitolo 3.
a
Relazionabilit` dei dati considerati: un RDBMS ` uno strumento utile a
a e
condizione che i dati da gestire siano relazionati tra loro. La condi-
zione viene a mancare in assenza di relazioni tra dati, come ` comune
e
trattando dati scarsamente strutturati o non strutturati.
Tipizzazione del dato: gli RDBMS pi` comuni possono gestire tipi di da-
u
ti eterogenei (valori numerici, stringhe), ma non sono stati progetta-
ti per gestire tipo di dato composto, come ad esempio ` un numero
e
complesso.
Assenza di schema per la gestione dei dati: se non sono nota a priori la
quantit` e il tipo di dato da memorizzare ` complesso definire uno
a e
schema noto a priori. I RDBMS non sono stati progettati per poter
adattare lo schema fisico in funzione dei dati a seconda dei dati forniti
dal livello applicativo.
Si noti inoltre che nelle operazioni di salvataggio dei dati risultano limita-
tive le procedure di ORM (Object Relational Mapping), cio` quelle tecniche
e
che permettono di convertire dati tra sistemi incompatibili nei linguaggi
di programmazione orientati agli oggetti. Ne ` un esempio la mappatu-
e
ra di implementazioni di Java Collection, in particolare l’implementazione
dell’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

18. 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 alternativa
per la gestione dello strato di persistenza.
Si noti che il contributo del lavoro di tesi in questo contesto non vuole
essere la creazione di un modulo software basato su tecnologia NoSQL de-
stinato ad arricchire le funzionalit` di software prodotti presso Esteco. Si
a
vuole invece sviluppare uno strumento di verifica che permetta di valutare,
sotto determinati vincoli, la validit` di alcuni modelli di basi di dati non
a
relazionali.
2.4 Related works
Viene qui analizzato lo stato dell’arte relativo alla problematica delineata
in questo capitolo. Si sono in particolare ricercati studi comparativi simili a
quello svolto nel lavoro di tesi.
Orend [12] descrive la popolarit` guadagnata dalle basi di dati non rela-
a
zionali, prendendone ad esempio alcune e analizzandole. Viene inoltre
condotto uno studio per verificare la loro abilit` nel rimpiazzare uno
a
strato di persistenza basato su oggetti e sul modello relazionale. Il la-
voro ` incentrato nella descrizione delle caratteristiche delle basi di dati
e
non relazionali e come queste possono soddisfare le esigenze di soft-
ware per la gestione della conoscenza e il lavoro collaborativo su web.
Non ` presente uno studio comparativo su pi` basi di dati relazionali
e u
e su come queste possono gestire la mappatura di entit` software Java.
a
Schram e Anderson [17] espongono come l’acquisizione, l’integrazione e
la memorizzazione di grandi quantit` di dati da sorgenti diverse sia di-
a
ventata una necessit` in molti campi dell’ingegneria. Il lavoro descrive
a
l’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 relative
al modello dei dati incontrate durante la transizione. Lo scenario di
riferimento considerato, dato dall’analisi di grandi quantit` di aggior-
a
namenti di stato sul servizio di micro-blogging Twitter, ` diverso da
e
16

19. quello preso in considerazione in questo lavoro di tesi.
Wei-ping, Ming-xin e Huan [22] descrivono le di colt` che incontra un
a
sistema di gestione di dati relazionale nell’a↵rontare la gestione di dati
in applicazioni Web. In particolare espone come le tecnologie NoSQL
possono rimpiazzare una tecnologia relazionale, e sperimentalmente
determina un valore aggiunto rispetto a particolari tipi di interroga-
zione sui dati (JOIN multi tabella). Lo scenario preso in esame ` e
diverso 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 per` `
o e
soprattutto una panoramica dei modelli di dati NoSQL pi` comuni,
u
e non o↵re una valutazione sperimentale comparativa rispetto ad uno
scenario di riferimento.
17

20. 3 Le tecnologie NoSQL
3.1 Definizione
Dare una definizione di tecnologia NoSQL ` complesso, dal momento che
e
non esiste in letteratura una definizione univoca [20]. I detrattori della
tecnologia preferiscono riferirsi a movimento NoSQL per indicare il fenomeno
di crescente attenzione verso un insieme di nuovi prodotti software, che
propongono soluzioni diverse per la gestione di una base di dati attraverso
un approccio comune: un modello logico non relazionale. Il termine NoSQL
venne coniato per la prima volta nel 1998 da Carlo Strozzi, per indicare
genericamente 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’utilizzo
di database non relazionali. NoSQL non ` un singolo prodotto, ma rappre-
e
senta un insieme di concetti e di tecniche diverse per la memorizzazione e
la manipolazione di dati: in questa categoria sono stati sviluppati database
NoSQL 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 studiarne
i vantaggi rispetto al classico modello relazionale.
3.2 Limitazioni del modello relazionale
I RDBMS assumono che i dati da trattare siano ben definiti e largamente
uniformi, ma soprattutto che le loro propriet` e relazioni possano essere defi-
a
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 garanzie
sulle transazioni. Appare perci` una forzatura l’utilizzo di uno schema rigido
o
per 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 caratteristiche
hardware, le necessit` degli utenti e il mercato dei database erano profon-
a
damente diversi dallo scenario moderno. I database relazionali moderni
traggono le loro radici da System R: DB2 di IBM ` un diretto discendente
e
di System R, come anche Microsoft SQL Server e Oracle. System R era
stato sviluppato in riferimento alle caratteristiche hardware del 1970. Da
allora ` aumentata la frequenza dei processori e la quantit` e la velocit`
e a a
di accesso alle memorie, fattori che ad oggi non costituiscono pi` dei limiti
u
alla progettazione di un programma di gestione di base di dati [19]. Si
vedr` quindi come le propriet` ACID, alla base del modello relazionale dei
a a
18

21. dati, propriet` di cui si discuter` nella sezione successiva, possono essere
a a
considerate 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 dati
relazionale, ` necessario che i meccanismi che implementano le transazioni
e
soddisfino le propriet` ACID. ACID deriva dall’acronimo inglese Atomicity,
a
Consistency, Isolation, Durability.
• Atomicit`. La transazione non pu` essere divisa nella sua esecuzione,
a o
che pu` essere totale oppure nulla, ma non parziale.
o
• Coerenza. Il database deve trovarsi in uno stato coerente all’inizio
e alla fine della transazione, cio` non deve violare vincoli di inte-
e
grit`. Quindi non devono verificarsi incoerenze tra i dati archiviati
a
nel database.
• Isolamento. Ogni transazione deve venir eseguita in modo isolato e
indipendente dalle altre transazioni. L’eventuale fallimento di una
transazione non deve interferire con le altre transazioni in esecuzione.
• Durabilit`. Detta anche persistenza, si riferisce al fatto che non pos-
a
sono essere persi i cambiamenti richiesti.
Per alcune applicazioni si pu` a↵ermare che l’aderenza del modello dei
o
dati alle propriet` ACID sia una scelta eccessivamente severa. In particola-
a
re quando si trattano dati semi-strutturati e non-strutturati, si deve poter
avere flessibilit` di gestione dell’archiviazione e dell’accesso alle informazioni.
a
Molti database NoSQL sono progettati per perdere il requisito ACID a
vantaggio della disponibilit` del dato. Un sistema che rispetta tali requisiti
a
si pu` definire BASE Basically Available, Soft-state, Eventually-consistent,
o
concetto che verr` chiarito nella sezione successiva. [15].
a
3.2.2 Scalabilit` del modello relazionale
a
Uno dei motivi che spiegano la fama crescente guadagnata da database che
non adottano il modello relazionale ` data dalla scalabilit`. Questo ` un
e a e
requisito sempre pi` importante per alcune applicazioni web, che devono
u
gestire in tempo reale le richieste di un numero crescente di utenti.
Un sistema definibile scalabile deve avere un incremento di prestazioni
che ` direttamente proporzionale all’aumento di risorse dedicate a gestire
e
19

22. l’aumento del carico di lavoro. Se l’aumento delle prestazioni non ` diretta-
e
mente proporzionale, il sistema sta sprecando risorse.
Le risorse possono essere aumentate, cio` scalate, attraverso una soluzio-
e
ne orizzontale oppure attraverso una soluzione verticale.
Un sistema scales up, cio` scala orizzontalmente, se l’aumento delle ri-
e
sorse si riferisce all’aumento dei nodi nel sistema, cio` se il sistema riesce a
e
parallelizzare il carico di lavoro [14].
Una applicazione scalabile deve rispettare i seguenti criteri:
1. Scalabilit` orizzontale: pi` unit` di calcolo (pi` server) creano pi`
a u a u u
capacit` di calcolo
a
2. Trasparenza all’applicazione: la logica dell’applicazione deve essere
separata dal problema di scalare le risorse
3. Fault-tolerant: non ci deve essere un singolo punto di fallimento. Un
fallimento di un server non deve causare un fallimento dell’applicazio-
ne.
Un esempio di scalabilit` proveniente dal mondo dell’hardware ` un array
a e
di dischi RAID5:
1. ` scalabile orizzontalmente: al crescere del numero di dischi in un array
e
RAID5 si ha pi` spazio e, generalmente, prestazioni migliori;
u
2. ` trasparente all’applicazione: le applicazioni accedono al RAID come
e
fosse un singolo dispositivo, ed ` il controller del RAID array che si
e
occupa di eseguire la divisione dei dati su pi` dischi fisici;
u
3. non esiste un singolo punto di fallimento. Si pu` estrarre un disco
o
dall’array senza compromettere la funzionalit` dell’applicazione che
a
utilizza il RAID.
Il vantaggio maggiore di questo genere di scalabilit` ` il costo, dal mo-
ae
mento che la distribuzione del carico di lavoro pu` essere e↵ettuata su nodi
o
a basso costo.
3.2.3 Scalabilit` verticale
a
Un database relazionale ` scalabile soprattutto verticalmente, cio` per au-
e e
mentare l’e cienza nella gestione dei dati ` necessario eseguire l’RDBMS su
e
un sistema pi` potente e costoso [10]. Si aumentano quindi le risorse del
u
singolo nodo del sistema: per esempio utilizzando CPU a frequenza maggio-
re o incrementando la memoria disponibile.
20

23. Esistono soluzioni commerciali per rendere un database relazionale sca-
labile orizzontalmente, cio` prodotti software che permettono di interrogare
e
un database distribuito su pi` nodi di calcolo, ma in generale le operazioni
u
di gestione di basi di dati relazionali in ambiente distribuito sono complesse
e costose.
Il modo pi` semplice ed immediato di scalare un database SQL ` ri-
u e
dimensionare il server che ospita il database, per guadagnare prestazioni.
Questo tipo di soluzione viene definita scalabilit` verticale, o scalabilit` del-
a a
la Legge di Moore. Operare un aggiornamento hardware del sistema che
ospita il database comporta i seguenti problemi:
1. ` una transazione complicata che usualmente richiede un intervento
e
umano e un’interruzione del servizio;
2. il server sostituito ` spesso inutilizzato.
e
3.3 Caratteristiche dell’approccio non relazionale
Alcune aziende, specialmente quelle che operano sul Web, hanno cominciato
ad adottare con successo soluzioni NoSQL, perch´ le loro necessit` di me-
e a
morizzazione di dati di↵eriscono in modo sostanziale dalle necessit` di forte
a
integrit` e coerenza che, ad esempio, deve avere una banca per gestire tran-
a
sazioni. [20]
Le soluzioni NoSQL sono quindi specializzazioni che, pur non rispettan-
do l’integrit` e la coerenza dei dati o↵erta dal modello relazionale, o↵rono
a
prestazioni di uno o due ordini di magnitudo superiori rispetto all’approc-
cio dei classici RDBMS, i quali puntano invece a essere contenitori ad una
dimensione per tutti gli utilizzi.
Le caratteristiche di un database NoSQL possono essere riassunte nelle
sezioni successive.
3.3.1 Scalabilit` orizzontale
a
La complessit` di elaborazione e memorizzazione in un database aumenta
a
con il volume di dati da elaborare e memorizzare. Come gi` enunciato, le
a
soluzioni per rendere stabili le prestazioni di un database al crescere della
quantit` di dati da trattare possono essere verticali, cio` l’unit` di elabora-
a e a
zione viene ridimensionata coerentemente al problema, oppure orizzontali,
cio` viene duplicata l’unit` di elaborazione.
e a
La prima scelta ` spesso una strada obbligata per i RDBMS di utilizzo
e
comune: tuttavia il costo che ne consegue in termini di infrastruttura, quin-
di di acquisto di server di fascia alta, ` spesso insostenibile per le piccole
e
aziende.
21

24. La seconda soluzione ` supportata in origine dai database NoSQL. I
e
database NoSQL sono progettati per scalare in modo distribuito su nodi
di calcolo distinti, senza dipendere dalle prestazioni hardware del singolo
nodo. Possono essere quindi eseguiti su numerosi componenti di commodity
hardware, cio` di hardware di fascia non elevata e dal prezzo contenuto. I
e
nodi di esecuzione possono essere aggiunti o rimossi senza compiere lo sforzo
necessario a partizionare dati in una soluzione con un RDBMS eseguito su
un cluster di nodi di calcolo.
3.3.2 Mappature tra oggetti e relazioni
La maggior parte dei database NoSQL sono progettati per memorizzare
strutture di dati che sono simili a quelle dei linguaggi di programmazione
orientati agli oggetti. Questo permette di evitare costose mappature tra re-
lazioni e oggetti quando si utilizza un RDBMS.
Ci` diventa un aspetto importante per le applicazioni con strutture
o
di dati a bassa complessit` che di cilmente trarrebbero beneficio da una
a
memorizzazione in un database relazionale [18].
3.3.3 Prestazioni ma non a dabilit`
a
Vi sono scenari di utilizzo dove ` preferibile compromettere l’a dabilit` in
e a
favore delle prestazioni. Per citare un esempio applicabile con tecnologie
NoSQL, le sessioni HTTP che devono essere condivise tra diversi web server
e devono essere accessibili per la durata della sessione, ma che non devono
essere memorizzate in modo persistente.
3.4 Modelli di dati
I modelli di dati utilizzati nelle tecnologie NoSQL sono molteplici. Segue
una 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 pu` o
citare come esempio BigTable [7], la base di dati proprietaria di Google.
BigTable di Google ` un database proprietario, compresso e ad alte presta-
e
zioni costruito sul Google File System e altre tecnologie di Google. Non ` e
distribuito e non ` utilizzato al di fuori di Google, sebbene Google ne o↵ra
e
l’accesso come parte del Google App Engine [13].
22

25. BigTable ` progettato per scalare orizzontalmente su dimensioni di da-
e
ti nell’ordine dei petabyte, su centinaia o migliaia nodi di calcolo, con
l’obiettivo di rendere facile l’aggiunta o la rimozione di un nodo.
Le idee sviluppate per BigTable sono state riprese da molti sviluppatori
che hanno prodotto e rilasciato con licenza open-source database considerati
cloni di BigTable. Tra questi, Cassandra ha ripreso sia le idee di BigTable
che di Dynamo, un prodotto non relazionale sviluppato da Amazon, basato
su modello chiave/valore.
3.4.2 Chiave/valore
Un HashMap o un array associativo ` la struttura dati pi` semplice che pu`
e u o
ospitare un insieme di coppie chiave/valore.
Le coppie chiave/valore sono di diversi tipi: alcune tengono dati in me-
moria e alcune forniscono la capacit` di memorizzare i dati su disco. Tali
a
coppie possono inoltre essere distribuite e memorizzate su cluster di nodi.
Uno dei pi` conosciuti archivi basato su questo modello di dati ` l’Oracle
u e
Berkeley DB, sviluppato all’inizio del 1990.
Un altro tipo di archivio chiave/valore comunemente utilizzato ` la ca-
e
che. Una cache ` un meccanismo utilizzato da sistemi operativi, database,
e
componenti di middleware, applicazioni, che permette di tenere in memoria
i dati pi` utilizzati da un’applicazione, allo scopo di ridurre gli accessi di
u
I/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 entit`, evitando di dividerlo nelle sue coppie costituenti chiave/valore.
a
Questo permette di mettere insieme diversi documenti in un’unica colle-
zione. I document database permettono l’indicizzazione di documenti sulla
base di un identificatore primario e di loro propriet`. Si osservi a tal propo-
a
sito l’esempio di memorizzazione di un oggetto Java su MongoDB, riportato
alle 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

26. Figura 5: Classificazione database non relazionali, secondo caratteristiche di
persistenza diverse. Sono presentati database che memorizzano dati su disco
o in memoria, collocati rispetto alle caratteristiche di ridondanza e localit`
a
dei dati (database distribuito su pi` nodi - database non distribuito).
u
24

27. 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 essa
a↵erente delineata nel Capitolo 2, si verifica la validit` dell’applicazione della
a
tecnologia presa in considerazione al Capitolo 3.
4.1 Obiettivo della sperimentazione
Oggetto della sperimentazione sono stati i NoSQL server individuati in base
alle caratteristiche espresse nella Sezione 4.3.
Obiettivo generale dell’esperimento ` verificare, in riferimento allo scena-
e
rio descritto, se le tecnologie NoSQL possano apportare un valore aggiunto
nella gestione della base di dati.
La determinazione del valore aggiunto sar` verificata:
a
• sulla misura di un osservabile, che sar` il tempo di esecuzione delle
a
operazioni di inserimento, lettura, aggiornamento, cancellazione di un
insieme di dati;
• sulla facilit` di mappatura di oggetti software Java, utilizzati nel livello
a
applicativo, sullo strato di persistenza;
Date le caratteristiche della tecnologia NoSQL, il risultato atteso ` un
e
valore aggiunto rispetto alla gestione con modello relazionale per ci` cheo
riguarda dati scarsamente strutturati e non relazionati e per ci` che riguar-
o
da la creazione di uno schema, ovvero di un contenitore dei dati, a livello
applicativo.
Caratteristica peculiare delle basi di dai NoSQL ` infatti l’assenza di uno
e
schema predefinito dove collocare le informazioni provenienti dallo strato ap-
plicativo. Si ritiene questa una caratteristica interessante nello scenario di
riferimento, dove il volume, la quantit`, la tipologia del dato prodotto dal-
a
l’applicazione non sono determinabili a priori.
Per raggiungere l’obiettivo sopra delineato ` stato implementato uno
e
strumento software di verifica che verr` descritto in dettaglio nelle sezioni
a
successive di questo capitolo. Lo strumento permetter` di verificare la vali-
a
dit` delle basi di dati NoSQL individuate nella Sezione 4.3.
a
Il contributo del lavoro di tesi va quindi identificato sia con l’apporto di
una base di conoscenza in Esteco, relativamente alle basi di dati non rela-
zionali, sia in concreto nello strumento software sviluppato. Esso permette
di verificare la validit` di alternative alla gestione di dati di workflow di
a
25

28. simulazione tramite RDBMS, in particolare utilizzando tecnologie non rela-
zionali. Rimane a disposizione di Esteco, che potr` utilizzarlo per verificare
a
la qualit` di nuove tecnologie NoSQL qualora ne sorgesse la necessit`.
a a
4.2 Strumento di sperimentazione
Lo strumento adoperato per e↵ettuare la sperimentazione e ricavare le infor-
mazioni necessarie a verificare la validit` di una base di dati non relazionale
a
` un software sviluppato in Java.
e
Tale software dovr` essere in grado di compiere le seguenti operazioni.
a
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 pi` accurata dello strumento si rimanda alla Sezione
u
4.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 candidati
idonei, 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, scarsamente
strutturati, non relazionati tra loro;
• deve esistere la possibilit` di interrogare il database con driver Java con
a
API gi` sviluppate e disponibili liberamente, essendo Java il linguaggio
a
di programmazione in uso in Esteco;
• devono esistere API per la mappatura di oggetti software Java verso
il server NoSQL, in modo similare a quanto proposto dallo standard
JPA (Java Persistence API);
• con riferimento al presupposto precedente, ` preferibile avere la pos-
e
sibilit` di eseguire mappature definite dall’utente, cio` definire come
a e
viene trasferita l’informazione dallo strato applicativo allo strato di
persistenza;
26

29. • sar` privilegiata la scelta di tre candidati che possiedono modelli di
a
dati diversi, cio` una situazione ideale potrebbe ad esempio essere
e
costituita da un candidato column-oriented, uno chiave/valore, uno
document-oriented;
• ogni candidato deve poter supportare l’inserimento e l’interrogazione
schema-less, cio` possedere la possibilit` di definire lo schema a partire
e a
da ci` che viene generato dallo strato applicativo;
o
• verranno preferiti candidati che presentano la possibilit` di essere sca-
a
lati orizzontalmente, in previsione di un aumento del volume di dati
memorizzati e quindi la frammentazione degli stessi su pi` unit` di
u a
calcolo;
• il modello dei dati scelto dovrebbe preferibilmente mantenere le pro-
priet` ACID di Atomicit`, Coerenza, Isolamento, Durabilit`;
a a a
• preferibilmente si sceglieranno server NoSQL che possono essere instal-
lati in alta a dabilit` e che presentano caratteristiche di tolleranza ai
a
guasti.
In base alle preferenza sopra evidenziate vengono selezionati i tre candi-
dati NoSQL server, di cui si riportano le caratteristiche essenziali in Figura
6.
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 ` abbreviazione per Create, Read, Delete, Update, cio` le operazioni
e e
di creazione, lettura, cancellazione, aggiornamento. OM ` abbreviazione per
e
Object Mapping, cio` mappatura di oggetto.
e
Per ognuno dei tre candidati si riportano inoltre le peculiarit` nelle
a
sezioni successive.
A titolo di completezza si riportano inoltre i server NoSQL esclusi, con
una breve motivazione a supporto della scelta:
• Redis [5] ` una base di dati chiave/valore, esclusa per lo scarso sup-
e
porto per la mappatura di oggetti Java;
27

30. • Hadoop [23] ` il framework di Apache che include HBase, una base di
e
dati che ` stata esclusa a causa della di colt` di implementazione del
e a
framework Hadoop stesso;
• CouchDB [2] ` una base di dati orientata ai documenti, esclusa per
e
lo scarso supporto verso Java API che supportassero la mappatura di
oggetti.
4.3.1 OrientDB
OrientDB [4] ` una base di dati NoSQL, open source, sviluppata interamen-
e
te in Java. Sebbene sia un database multimodello, le relazioni sono gestite
come nei database basati su grafi, con connessioni dirette tra i record. Sup-
porta modalit` senza schema e con schema.
a
Supporta il linguaggio SQL per la manipolazione dei dati ed espone
nativamente HTTP RESTful e JSON senza l’utilizzo di librerie di terze
parti e altre componenti di estensione.
Caratteristica particolarmente interessante di OrientDB sono i link di-
rettamente navigabili. Per comprenderne il significato si riporta di seguito
un esempio.
Si supponga di avere due insieme di record, che assumeremo tabellari.
Il primo memorizza nomi di nazione, il secondo nomi di citt`. Il primo tipo
a
di record ritorna una rappresentazione di questo tipo con una operazione
SELECT.
orientdb> select from country
---+--------+--------------------
#| RID |name
---+--------+--------------------
0| #22:0|Italy
1| #22:1|France
2| #22:2|Spain
3 item(s) found. Query executed in 0.012 sec(s).
Il secondo invece viene rappresentato nel seguente modo:
28

31. orientdb> select from city
---+---------+------------------+--------------------
#| RID |name |country
---+---------+------------------+--------------------
0| #21:0|Rome |#22:0
1| #21:1|Paris |#22:1
2| #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 citt` e nazioni (ogni citt`
a a
appartiene ad una nazione) viene riportata attraverso un ID numerico, che
corrisponde al record stesso a cui la relazione porta.
Tale propriet` rende possibile interrogazioni dove si pu` navigare tra i
a o
record. Ad esempio ` immediata un’interrogazione complessa come la se-
e
guente, che in una base di dati relazionale avrebbe richiesto un JOIN tra le
due tabelle.
orientdb> select from city where country.name=’Italy’ or
country.name=’Spain’
---+---------+-----------------+--------------------
#| RID |name |country
---+---------+-----------------+--------------------
0| #21:0|Rome |#22:0
1| #21:1|Madrid |#22:2
4.3.2 MongoDB
MongoDB [3] ` una base di dati non relazionale, orientata ai documenti, rila-
e
sciata con licenza simile alla GNU General Public License nel febbraio 2009.
Viene sviluppato in C++ e utilizza JavaScript come linguaggio di gestione
dei 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 ` la Figura 7, dove viene rappresentata una
e
ipotetica mappatura tra il RDBMS MySQL e il NoSQL MongoDB.
29

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

33. 4.3.3 Cassandra
Cassandra [1] ` un DBMS non relazionale, distribuito e open source, basato
e
su una struttura di memorizzazione chiave valore.
Sviluppato in Java presso Facebook, con licenza open-source. Nel 2008
Cassandra venne donato alla Apache Foundation. I metodi di accesso com-
prendono un’interfaccia a linea di comando, Thrift e Java API. Esistono
client 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 ) ` leg-
e
germente fuorviante rispetto al modello di dati realmente usato, che ` un
e
ibrido basato su chiave e valore, ma rappresentato come orientato alle co-
lonne.
In Cassandra, le righe contengono colonne. Per accedere alla pi` piccola
u
unit` di dato, cio` la colonna, bisogna specificare il nome della riga (cio` la
a e e
chiave), 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, e
ciascuna colonna ha un nome e un valore.
mela -> colore peso prezzo variet`
a
"rosso" 100 10 "Golden"
arancia -> colore peso prezzo variet`
a
"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 pu` ad esempio non avere
o
una variet`. Oppure si possono aggiungere colonne arbitrarie, ad esempio
a
l’origine dell’arancio, in ogni momento. Si pu` pensare ai dati rappresentati
o
da cassandra come ad una tabella, ma sparsa e dove molti valori possono
essere vuoti.
Ancora, un modello di dati orientato alle colonne pu` essere usato ad
o
esempio per liste e serie temporali, dove ogni colonna ` unica. Nell’esempio
e
seguente abbiamo solo una riga, ma possiamo avere migliaia o milioni di
colonne.
temperatura -> 2013-03-15 2013-03-16 2013-03-17 ...
3.5 4.5 6.8 ...
31

34. Questo approccio di↵erisce sostanzialmente dal modello relazionale, dove
intuitivamente si sarebbero elencati i valori di una serie temporale per righe
e non per colonne.
4.4 Implementazione
Viene di seguito descritto l’ambiente hardware e software nel quale sono
stati eseguiti gli esperimenti. La descrizione dell’ambiente ` preceduta da
e
un breve paragrafo dove si delinea la metodologia di implementazione da
utilizzare.
4.4.1 Pianificazione
Come descritto brevemente nella Sezione 4.2, lo strumento software svilup-
pato dovr` essere in grado di creare delle entit` di test e sottoporle a verifica
a a
sul database di riferimento. Infine dovr` essere in grado di memorizzare i
a
risultati per una loro elaborazione.
Tenendo conto di tutti gli elementi necessari a sviluppare un tale stru-
mento, si ` deciso di procedere secondo i seguenti passi per ci` che riguarda
e o
la parte server:
installazione delle basi di dati candidate;
verifica della funzionalit` della base di dati operando via linea di comando.
a
Per ci` che riguarda la parte client invece:
o
installazione delle API Java nel progetto NetBeans;
verifica della funzionalit` delle API creando connessioni con i server attivi;
a
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 verifica
dell’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 ` utilizzato
e
uno stesso database NoSQL, in particolare OrientDB. Tale procedura si ` e
dimostrata di facile implementazione e ha permesso inoltre di interrogare
32

35. Figura 8: Sistema di visualizzazione dei risultati.
33

36. una base di dati di risultati attraverso il protocollo HTTP. Grazie a questa
possibilit` ` stato creato il sistema di visualizzazione dei risultati, ra gurato
ae
in 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 ` analizzare le prestazioni della
e
base di dati, non del client. L’architettura hardware rispecchia questa scelta:
il server ` in esecuzione su una architettura Intel prodotta nel 2006, mentre
e
il client su una macchina del 2012. La frequenza del processore, il bus di
interconnessione, 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 un
progetto Java ai fini della sperimentazione;
• strumento per build automatici Maven;
• API Java per l’interrogazione dei database server, come descritto in
Figura 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

37. 4.4.4 Interconnessione
La rete di connessione stabilita tra il client e il server ` una connessione back-
e
to-back (punto-punto) tra i due computer portatili utilizzati per il server e
per il client. Poich´ la connessione punto-punto ha creato un collegamento
e
tra i nodi fisici ma non tra il nodo client (fisico) e quello server (virtuale,
si ricordi che la parte server ` in esecuzione su macchina virtuale), si `
e e
creato un tunnel SSH (Secure Shell) per permettere il trasporto dei dati di
connessione verso l’interfaccia di rete della macchina virtuale.
Ai fini dell’obiettivo della tesi e dello scenario considerato si riterr` tra-
a
scurabile nei risultati di esperimento il contributo aggiuntivo, in termini di
tempo, dato dal tunnel stesso.
4.5 Struttura dei test
Vengono qui presentati le classi Java utilizzati per sperimentare i server
NoSQL. In base alle specifiche JPA ci si riferir` ad esse, nel seguito della
a
trattazione, anche come entit` di persistenza.
a
SimpleBean ` una classe che istanzia un oggetto Java molto semplice,
e
contiene un dato di tipo intero e un dato di tipo stringa;
CompositeBean ` una classe per istanziare un oggetto Java pi` complesso,
e u
che contiene un riferimento a oggetti SimpleBean, cio` un riferimento
e
ad un tipo di dato creato dall’utente;
MapBean ` una classe che istanzia un oggetto Java che contiene due imple-
e
mentazioni dell’interfaccia Collection, in particolare una lista di Sim-
pleBean e una mappa che associa una chiave (tipo di dato stringa) ad
un valore (tipo di dato SimpleBean).
Tali oggetti dovranno venir memorizzati dai server NoSQL e la loro strut-
tura informativa conservata, cio` mappata sulla base di dati. Ci` significa ad
e o
esempio che i tipi di dato intero e stringa dell’oggetto SimpleBean dovranno
essere ricreati come tipo di dato intero e stringa sullo strato di persistenza
o↵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 ` e
assicurata la mappatura degli oggetti CompositeBean e MapBean. In questo
caso si verificher` quindi la loro serializzazione e deserializzazione.
a
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 che
forniscono indicazioni sul tipo di dato trattato e sulla sua mappatura verso
la base di dati. Non contengono quindi import, setters, getters, eventuali
35

38. 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 (if
omitted name of the class is used as the ColumnFamily)
public class SimpleBean implements Bean, Serializable {
@Id
private 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

39. CompositeBean
@Entity // signals the EntityManager to make the bean available for
persistence management
@Table(name = "CBCF", schema = "KunderaExamples@cassandra_pu") //
defines what ColumnFamily to use when loading and saving (if
omitted name of the class is used as the ColumnFamily)
public class CompositeBean implements Bean, Serializable {
// MONGO -- ID ANNOTATION FROM MORPHIA LIBRARY
@Id
private ObjectId id;
// CASSANDRA -- ID ANNOTATIONS FROM JPA
@javax.persistence.Id
private UUID cassandraId; // cassandra
@Column(name = "simplebean1")
private SimpleBean simpleBean1;
@Column(name = "simplebean2")
private SimpleBean simpleBean2;
@Column(name = "simplebean3")
private SimpleBean simpleBean3;
public CompositeBean() {
this.setSimpleBean1(new SimpleBean());
this.setSimpleBean2(new SimpleBean());
this.setSimpleBean3(new SimpleBean());
}
public SimpleBean getSimpleBean1() {
return simpleBean1;
}
// setters, getters
}
37

40. MapBean
@Entity
@Table(name = "MBCF", schema = "KunderaExamples@cassandra_pu") //
defines what ColumnFamily to use when loading and saving (if
omitted name of the class is used as the ColumnFamily)
public class MapBean implements Bean, Serializable {
// MONGO -- ID ANNOTATION FROM MORPHIA LIBRARY
@Id
private ObjectId id;
// CASSANDRA -- ID ANNOTATIONS FROM JPA
@javax.persistence.Id
private 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 entit` software presentate nella sezione preceden-
a
te sono state progettate per cercare di simulare l’interazione che avviene tra
lo strato applicativo e lo strato di persistenza, in riferimento allo scenario e
alle problematiche delineate al Capitolo 1 e 2.
Sebbene gli oggetti software scelti siano semplici e di complessit` minore
a
di 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 validit` di una soluzione di gestione basata su server NoSQL.
a
In particolare i POJO (Plain, Old, Java Objects) presi in considerazione
possono essere il risultato di una lettura dalla base di dati, quindi un input
38

41. o in generale un dato gi` esistente, oppure un dato da salvare sulla base di
a
dati.
4.7 Metodologia
La metodologia di sperimentazione e le fasi che compongono un esperimento
vengono ra gurate, in modo informale, in Figura 9.
Figura 9: Rappresentazione informale della procedura di sperimentazione e
misurazione implementata. In grigio sono rappresentati blocchi sviluppati
per il lavoro di tesi, in giallo parti software gi` disponibili, API native del
a
server NoSQL o librerie di terze parti.
• inizio dell’esecuzione, con argomenti specificati dall’utente (numero di
elementi da testare, tipo di operazione, scelta del server);
39

42. • creazione dell’insieme di test in base a quanto specificato dall’utente.
La struttura utilizzata ` una
e
Map<Class<? extends Bean>, List<Bean>>
dove Bean ` una superclasse per SimpleBean, CompositeBean, Map-
e
Bean. La mappa contiene quindi liste di istanze SimpleBean, Compo-
siteBean, MapBean;
• registrazione delle classi sull’Entity Manager del driver per l’Object
Mapping della base di dati di riferimento;
• memorizzazione dell’entit` Java nella base di dati, o altra operazione;
a
• rilevazione del tempo di esecuzione dell’operazione in base a coordinate
di 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 Figura
10. Come visualizzato in figura, viene creato un insieme di dati che contiene
una lista di istanze SimpleBean, una lista di istanze CompositeBean, una
lista di istanze MapBean.
Figura 10: Metodologia di rilevazione dei risultati.
Le liste sono utilizzate poi per ottenere gli oggetti su cui si eseguir`, per
a
ciascuno, la chiamata della libreria che deve gestire la persistenza dell’ogget-
to. Il tempo di rilevazione ` il tempo totale per eseguire questa operazione
e
per tutti gli elementi della lista.
40

43. 5 Analisi dei risultati
Si presentano in questo capitolo i risultati ottenuti nel corso della sperimen-
tazione. Si ricordi che l’obiettivo dell’esperimento ` verificare la validit` di
e a
una 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 relazionali
nella gestione di dati trattati da workflow di simulazione. Per e cienza si
intende un concetto basato su due tipi di informazioni, che sono state rica-
vate nel corso di ogni ripetizione dell’esperimento:
• un informazione misurabile, cio` il tempo di esecuzione delle operazioni
e
di inserimento, lettura, cancellazione, aggiornamento di dati sulla base
di dati sperimentata;
• un informazione non misurabile, cio` la facilit` di eseguire una mappa-
e a
tura tra campi dell’oggetto software preso in considerazione (con tipo
di dato eterogeneo) e campi della base di dati.
In base al valore di queste due informazioni prese in esame verr` ricavato:
a
una conclusione generale, presentata a chiusura dell’elaborato, sulla vali-
dit` dell’utilizzo della tecnologia NoSQL rispetto alla base di dati uti-
a
lizzata nel contesto di riferimento (PostgreSQL, MySQL, OODBMS,
Oracle, MSSQL Server);
una classifica di preferenza delle basi di dati prese in considerazione. Tale
classifica non vuole esprimere giudizi di merito in assoluto, ovvero
applicabili in ogni contesto, ma deve essere sempre rapportata allo
scenario di riferimento.
5.1 Dati sperimentali
Vengono di seguito presentate le misure di dati sperimentali, con l’ausilio di
grafici.
Si noti che, mentre per quanto riguarda le operazioni CRUD viene for-
nita la rilevazione del tempo di esecuzione dell’operazione, nel caso della
mappatura di oggetto viene fornito un giudizio sulla facilit` di mappatura,
a
espresso utilizzando aggettivi.
Nei grafici, le ascisse corrispondono al numero di operazioni, mentre le
ordinate al tempo di esecuzione per concludere l’operazione di riferimento.
41

44. 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 basi
di dati sia simile, si rileva come MongoDB o↵ra tempo di esecuzione
minore per questo tipo di operazione, per tipo di entit` SimpleBean.
a
CompositeBean in Figura 12. La scrittura di CompositeBean nel server
OrientDB impiega un tempo nettamente maggiore rispetto a Mon-
goDB, il migliore, e a Cassandra, vicina a MongoDB. La scrittura di
entit` composite ` quindi penalizzante per OrientDB.
a e
MapBean in Figura 13. Analogamente a quanto riportato per l’inseri-
mento di CompositeBean, la scrittura di oggetti compositi MapBean
` un’operazione onerosa in termini di tempo per OrientDB.
e
Figura 11: Inserimento nel database di SimpleBean.
42

45. Figura 12: Inserimento nel database di CompositeBean.
Figura 13: Inserimento nel database di MapBean.
43

46. 5.1.2 Lettura
Analogamente alla presentazione dei risultati di scrittura, si considerano per
la lettura popolazioni di:
SimpleBean in Figura 14. Il tempo di lettura per OrientDB ` nettamente
e
superiore rispetto a Cassandra e MongoDB. Per 100000 elementi il
tempo di OrientDB ` maggiore fino a 20 ordini di grandezza rispetto
e
a MongoDB, il migliore anche in questo test.
CompositeBean in Figura 15. La lettura di CompositeBean, analoga-
mente alla scrittura, ` penalizzante per OrientDB. Per questo databa-
e
se si osservano risultati discontinui per letture di popolazioni superiori
a 60000 elementi.
MapBean in Figura 16. La lettura di MapBean ` onerosa per OrientDB.
e
Il comportamento di Cassandra e MongoDB ` invece quasi identico
e
fino a 100000 elementi (circa 7 secondi per leggere 100000 elementi).
Figura 14: Lettura di SimpleBean.
44

47. Figura 15: Lettura di CompositeBean.
Figura 16: Lettura di MapBean.
45

48. 5.1.3 Lettura con selezione
Si presentano qui i risultati di letture con selezione. Per selezione si intende
una operazione di filtraggio, eseguita sul campo Integer presente in istan-
ze della classe SimpleBean. Tale numero intero assume un valore casuale
sull’intervallo 0 - RANDOMINTERVAL, dove RANDOMINTERVAL ` pari e
a 1000000. Il filtro seleziona in particolare SimpleBean con valori di Inte-
ger minori di RANDOMINTERVAL/2. L’operazione di filtraggio dovrebbe
quindi restituire una popolazione di circa N/2 elementi, dove N ` il numero
e
di elementi considerato.
Si noti che l’operazione ` di particolare interesse nello scenario di riferi-
e
mento, dove ` usuale porre condizioni nelle interrogazioni eseguite su dati
e
di progetto nei workflow di simulazione (ad esempio selezione di design con
particolari caratteristiche).
Questa operazione ` e↵ettuata in modo diverso su ogni base di dati.
e
Nonostante l’obiettivo di ogni libreria di object mapping sia implementare le
specifiche JPA (Java Persistence API), non ` standard il metodo di selezione
e
con filtro. Le diversit` vengono presentate come segue (vengono spezzate le
a
linee di codice per comodit` di lettura):
a
MongoDB - libreria Morphia per object mapping - espone un metodo
createQuery (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 metodo
createQuery utilizzato nel seguente modo:
46

49. // 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 secondo
circa per leggere con filtro su una popolazione di 100000 valori). Si noti
che in questo caso OrientDB ` nettamente pi` veloce nel tempo di rispo-
e u
sta di Cassandra. Questo potrebbe essere dovuto al driver Java nativo di
OrientDB per l’object mapping. Cassandra utilizza Kundera, che ` una li-
e
breria utilizzabile per eseguire object mapping anche su altre basi di dati
NoSQL, quindi meno specializzata.
Figura 17: Lettura di SimpleBean con selezione della popolazione.
47

50. 5.1.4 Mappatura dei campi delle entit`
a
La Figura 18 mostra come i di↵erenti database NoSQL implementano la
mappatura di diversi tipi di entit` Java. A sinistra riporta i tipi di entit`
a a
considerata ed i campi di ciascuna entit`, mentre a destra riporta le API
a
per la mappatura degli oggetti e come ciascuna base di dati gestisce i campi
relativi a quell’entit`.
a
Si noti inoltre che:
• in MongoDB e in OrientDB sono state utilizzate le API native dei ri-
spettivi software per eseguire la mappatura degli oggetti, in Cassandra
sono state utilizzate le API del progetto Kundera;
• ` da prendere in considerazione anche la presenza o meno di annotazio-
e
ni (Annotations, relative alle specifiche JPA) per gestire la mappatura:
queste sono obbligatorie esclusivamente in Cassandra.
Figura 18: Facilit` di mappatura delle entitit` considerate per i tre server
a a
NoSQL.
Come si osserva dalla Figura 18, non si ` potuto procedere alla map-
e
patura di implementazioni di Map su Cassandra. Queste non sono infatti
supportate dalla libreria di object mapping Kundera. Al momento di spe-
rimentare Cassandra si ` quindi istanziato un oggetto di tipo ArrayList in
e
luogo di HashMap, che ` stato invece utilizzato in MongoDB e OrientDB.
e
Si riporta di seguito un esempio di come sono state mappate le entit` su
a
una base di dati di riferimento (MongoDB):
48

51. > 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