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

904 views

Published on

Published in: Technology
0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total views
904
On SlideShare
0
From Embeds
0
Number of Embeds
1
Actions
Shares
0
Downloads
20
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide

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

  1. 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  scientificiRelatore LaureandoProf.  Eric  Medvet Francesco  De  GiorgiCorrelatoreDott.  Paolo  Vercesi
  2. 2. IndiceIntroduzione 41 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 . . . . . . . . . . . . . . 102 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 . . . . . . . . . . . . . . . . . . . . . . . . . . . 163 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 . . . . . . . . . . . . . . . . . . . . . . 234 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
  3. 3. 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 . . . . . . . . . . . . . . . . . 405 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 . . . . . . . . . . . . . . . . . 50Conclusioni 52Bibliografia 53Elenco 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
  4. 4. 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. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3910 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 Facilit` di mappatura delle entitit` considerate per i tre server a a NoSQL. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48 3
  5. 5. IntroduzioneL’argomento di questo lavoro di tesi ` la gestione dei dati generati in work- eflow 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 ` stato proposto da Esteco S.p.A., esociet` insediata presso AREA Science Park, Padriciano, Trieste, dove ` a estata svolta la tesi. I sistemi software che Esteco o↵re sul mercato consen-tono l’ottimizzazione multiobiettivo tramite workflow di simulazione, cio` el’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 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- edello relazionale non sia il migliore possibile. Obiettivo del lavoro ` quindi verificare le alternative ai RDBMS utilizzati eper 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
  6. 6. Oggetto dell’indagine ` stata la gestione della persistenza e l’interroga- ezione di entit` software su tali database non relazionali. I termini utilizzati aper 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 eusato all’interno di Esteco per lo sviluppo delle applicazioni prodotte. Il risultato atteso ` un contributo alla conoscenza di Esteco relativamente eall’argomento delle basi di dati non relazionali. Nel concreto, lo strumentosoftware progettato non costituir` un elemento da aggiungere alla produzio- ane attuale dell’azienda, ma o↵rir` la possibilit` di verificare alternative alla a agestione di dati di progetto tramite RDBMS. Il Capitolo 1 dell’elaborato ` incentrato sulla descrizione dello scenario. eViene qui a↵rontato il concetto di workflow di simulazione. Il Capitolo 2 ` una analisi delle problematiche di memorizzazione dei edati di workflow di simulazione. Il Capitolo 3 ` un’analisi delle caratteristiche principali delle tecnologie eNoSQL. Il Capitolo 4 ` dedicato alle motivazioni che supportano la scelta dei ecandidati server NoSQL selezionati per la sperimentazione. 5
  7. 7. 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
  8. 8. 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, doveIl   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 ecorrispondenti   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  dellesue  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- eI  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.
  9. 9. che opera sui valori delle variabili in ingresso, cio` sullo spazio decisiona- ele da esplorare, per ottenere i valori calcolati delle variabili in uscita. Lostudio del modello matematico e delle sue caratteristiche non ` oggetto di etrattazione nella tesi.1.2 Caratteristiche dei dati trattatiIn 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 multiobiettivoAll’interno dell’azienda dove ` stato svolto il lavoro di tesi, Esteco, vengono esviluppati 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 ol’ingegneria assistita al calcolatore (CAE). SOMO (Service Oriented Mul-tidisciplinary Orchestration) ` una piattaforma web che supporta la ge- estione della complessit` delle simulazioni multidisciplinari, organizzando ed aorchestrando dati e workflow di simulazione. 8
  10. 10. Obiettivo comune di entrambi ` fornire uno strumento per l’ottimizza- ezione 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. Pu` essere oconsiderato 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 conflittualit` degli obiettivi di aprogetto: questo classe di problemi ` generalmente conosciuta come MDCM e(MultiCriteria Decision Making). I problemi MCDM vengono comunementerisolti tramite una procedura di ottimizzazione, che nel caso di due o pi` uobiettivi 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 ` neces- esaria 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 ` necessario per risolvere un problema eMCDM, ` aiutato nella scelta da strumenti di supporto alle decisioni, quali eil 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` oportare all’esplorazione dello spazio del progetto con la generazione di cen-tinaia di migliaia di design. Una situazione analoga si pu` presentare con oproblemi mono-obiettivo in presenza di numerosi vincoli, per i quali spessonon ` possibile trovare neanche un design ammissibile. e 9
  11. 11. Figura 2: Il workflow di simulazione ` una funzione matematica che riceve in eingresso le variabili decisionali e restituisce in uscita le variabili di risposta.1.4 Casi d’usoTra 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 ottimizzazioneingegneristica condotta grazie al software modeFRONTIER.1.4.1 Ottimizzazione di traiettoriaViene 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
  12. 12. 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 seguitosi 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
  13. 13. 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 edalla 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
  14. 14. 2 Analisi della problematicaIn 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, verr` proposta un’ipotesi di soluzione. a I vincoli a cui tale soluzione ` sottoposta emergono direttamente dal- ele 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 dipender` dal tempo di esecu- azione necessario a gestire le operazioni pi` comuni eseguite sulla base di dati, unonch´ dalla facilit` di mappatura di oggetti Java dal livello applicativo alla e abase di dati [11]. Verranno quindi trattate metodologie alternative per gestire la persi-stenza dei dati di workflow di simulazione. La ricerca di alternative sar` asottoposta 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 datiViene 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 pu` essere interpretato ocome 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 ouna struttura complessa, un array multidimensionale, un Uniform ResourceIdentifier, un file, ecc. Il significato di ogni variabile ` completato da metadati, di tipo generico, eche per tipi numerici possono ad esempio rappresentare il dominio di unavariabile che nel caso numerico pu` essere rappresentato dal limite inferiore, osuperiore, etc.. 13
  15. 15. Il workflow di simulazione di per s´ si limita a definire come le variabi- eli 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 gi` introdotte, in base ad una espressione fornita dall’utente. L’e- aspressione utilizzata per calcolare l’obiettivo o il vincolo ` esso stesso un emetadato. 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 designcorretto oppure su un design errato perch´ qualche vincolo non ` stato ri- e espettato. Anche questi metadati possono essere generici.2.2 Problematiche nella gestione di datiLe 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
  16. 16. 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 seguele di colt` incontrate nell’utilizzo di un RDBMS: aScalabilit` 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. aRelazionabilit` 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 eche permettono di convertire dati tra sistemi incompatibili nei linguaggidi programmazione orientati agli oggetti. Ne ` un esempio la mappatu- era 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
  17. 17. persistenza, o↵erto da sistemi di gestione di basi di dati MySQL o Postgre-SQL.2.3 Ipotesi di soluzioneIn 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 funzionalit` di software prodotti presso Esteco. Si avuole invece sviluppare uno strumento di verifica che permetta di valutare,sotto determinati vincoli, la validit` di alcuni modelli di basi di dati non arelazionali.2.4 Related worksViene 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 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. aSchram 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
  18. 18. 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
  19. 19. 3 Le tecnologie NoSQL3.1 DefinizioneDare una definizione di tecnologia NoSQL ` complesso, dal momento che enon esiste in letteratura una definizione univoca [20]. I detrattori dellatecnologia preferiscono riferirsi a movimento 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 ` un singolo prodotto, ma rappre- esenta 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 relazionaleI RDBMS assumono che i dati da trattare siano ben definiti e largamenteuniformi, ma soprattutto che le loro propriet` e relazioni possano essere defi- anite 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 perci` una forzatura l’utilizzo di uno schema rigido oper 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 necessit` degli utenti e il mercato dei database erano profon- adamente diversi dallo scenario moderno. I database relazionali modernitraggono le loro radici da System R: DB2 di IBM ` un diretto discendente edi System R, come anche Microsoft SQL Server e Oracle. System R erastato sviluppato in riferimento alle caratteristiche hardware del 1970. Daallora ` aumentata la frequenza dei processori e la quantit` e la velocit` e a adi accesso alle memorie, fattori che ad oggi non costituiscono pi` dei limiti ualla progettazione di un programma di gestione di base di dati [19]. Sivedr` quindi come le propriet` ACID, alla base del modello relazionale dei a a 18
  20. 20. dati, propriet` di cui si discuter` nella sezione successiva, possono essere a aconsiderate un valore aggiunto non necessario in diversi casi di utilizzo.3.2.1 Da ACID a BASEPer operare in modo corretto sulle informazioni contenuti in una base di datirelazionale, ` necessario che i meccanismi che implementano le transazioni esoddisfino le propriet` ACID. ACID deriva dall’acronimo inglese Atomicity, aConsistency, 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 odati alle propriet` ACID sia una scelta eccessivamente severa. In particola- are quando si trattano dati semi-strutturati e non-strutturati, si deve poteravere flessibilit` di gestione dell’archiviazione e dell’accesso alle informazioni. a Molti database NoSQL sono progettati per perdere il requisito ACID avantaggio della disponibilit` del dato. Un sistema che rispetta tali requisiti asi pu` definire BASE Basically Available, Soft-state, Eventually-consistent, oconcetto che verr` chiarito nella sezione successiva. [15]. a3.2.2 Scalabilit` del modello relazionale aUno dei motivi che spiegano la fama crescente guadagnata da database chenon adottano il modello relazionale ` data dalla scalabilit`. Questo ` un e a erequisito sempre pi` importante per alcune applicazioni web, che devono ugestire in tempo reale le richieste di un numero crescente di utenti. Un sistema definibile scalabile deve avere un incremento di prestazioniche ` direttamente proporzionale all’aumento di risorse dedicate a gestire e 19
  21. 21. l’aumento del carico di lavoro. Se l’aumento delle prestazioni non ` diretta- emente proporzionale, il sistema sta sprecando risorse. Le risorse possono essere aumentate, cio` scalate, attraverso una soluzio- ene orizzontale oppure attraverso una soluzione verticale. Un sistema scales up, cio` scala orizzontalmente, se l’aumento delle ri- esorse si riferisce all’aumento dei nodi nel sistema, cio` se il sistema riesce a eparallelizzare 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 edi 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- aemento che la distribuzione del carico di lavoro pu` essere e↵ettuata su nodi oa basso costo.3.2.3 Scalabilit` verticale aUn database relazionale ` scalabile soprattutto verticalmente, cio` per au- e ementare l’e cienza nella gestione dei dati ` necessario eseguire l’RDBMS su eun sistema pi` potente e costoso [10]. Si aumentano quindi le risorse del usingolo nodo del sistema: per esempio utilizzando CPU a frequenza maggio-re o incrementando la memoria disponibile. 20
  22. 22. Esistono soluzioni commerciali per rendere un database relazionale sca-labile orizzontalmente, cio` prodotti software che permettono di interrogare eun database distribuito su pi` nodi di calcolo, ma in generale le operazioni udi gestione di basi di dati relazionali in ambiente distribuito sono complessee costose. Il modo pi` semplice ed immediato di scalare un database SQL ` ri- u edimensionare il server che ospita il database, per guadagnare prestazioni.Questo tipo di soluzione viene definita scalabilit` verticale, o scalabilit` del- a ala Legge di Moore. Operare un aggiornamento hardware del sistema cheospita 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. e3.3 Caratteristiche dell’approccio non relazionaleAlcune aziende, specialmente quelle che operano sul Web, hanno cominciatoad adottare con successo soluzioni NoSQL, perch´ le loro necessit` di me- e amorizzazione di dati di↵eriscono in modo sostanziale dalle necessit` di forte aintegrit` e coerenza che, ad esempio, deve avere una banca per gestire tran- asazioni. [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 aprestazioni 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 Scalabilit` orizzontale aLa complessit` di elaborazione e memorizzazione in un database aumenta acon il volume di dati da elaborare e memorizzare. Come gi` enunciato, le asoluzioni per rendere stabili le prestazioni di un database al crescere dellaquantit` di dati da trattare possono essere verticali, cio` l’unit` di elabora- a e azione 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 ecomune: tuttavia il costo che ne consegue in termini di infrastruttura, quin-di di acquisto di server di fascia alta, ` spesso insostenibile per le piccole eaziende. 21
  23. 23. La seconda soluzione ` supportata in origine dai database NoSQL. I edatabase 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, cio` di hardware di fascia non elevata e dal prezzo contenuto. I enodi 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 relazioniLa 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. Ci` diventa un aspetto importante per le applicazioni con strutture odi dati a bassa complessit` che di cilmente trarrebbero beneficio da una amemorizzazione in un database relazionale [18].3.3.3 Prestazioni ma non a dabilit` aVi sono scenari di utilizzo dove ` preferibile compromettere l’a dabilit` in e afavore 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 datiI modelli di dati utilizzati nelle tecnologie NoSQL sono molteplici. Segueuna veloce trattazione dei principali.3.4.1 Orientati alle colonneDenominati anche Sorted ordered column-oriented stores, oppure Wide co-lumn store. Per capire il funzionamento dei database orientati alle colonne si pu` ocitare come esempio BigTable [7], la base di dati proprietaria di Google.BigTable di Google ` un database proprietario, compresso e ad alte presta- ezioni costruito sul Google File System e altre tecnologie di Google. Non ` edistribuito e non ` utilizzato al di fuori di Google, sebbene Google ne o↵ra el’accesso come parte del Google App Engine [13]. 22
  24. 24. BigTable ` progettato per scalare orizzontalmente su dimensioni di da- eti 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/valoreUn HashMap o un array associativo ` la struttura dati pi` semplice che pu` e u oospitare 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 acoppie possono inoltre essere distribuite e memorizzate su cluster di nodi.Uno dei pi` conosciuti archivi basato su questo modello di dati ` l’Oracle u eBerkeley DB, sviluppato all’inizio del 1990. Un altro tipo di archivio chiave/valore comunemente utilizzato ` la ca- eche. Una cache ` un meccanismo utilizzato da sistemi operativi, database, ecomponenti di middleware, applicazioni, che permette di tenere in memoriai dati pi` utilizzati da un’applicazione, allo scopo di ridurre gli accessi di uI/O su disco.3.4.3 Orientati ai documentiCon 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 sullabase di un identificatore primario e di loro propriet`. Si osservi a tal propo- asito l’esempio di memorizzazione di un oggetto Java su MongoDB, riportatoalle sezioni conclusive del Capitolo 4.3.5 Orientarsi nella sceltaI 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
  25. 25. 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 localit` adei dati (database distribuito su pi` nodi - database non distribuito). u 24
  26. 26. 4 SperimentazioneIn 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 validit` dell’applicazione della atecnologia presa in considerazione al Capitolo 3.4.1 Obiettivo della sperimentazioneOggetto della sperimentazione sono stati i NoSQL server individuati in basealle caratteristiche espresse nella Sezione 4.3. Obiettivo generale dell’esperimento ` verificare, in riferimento allo scena- erio descritto, se le tecnologie NoSQL possano apportare un valore aggiuntonella 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 evalore aggiunto rispetto alla gestione con modello relazionale per ci` cheoriguarda dati scarsamente strutturati e non relazionati e per ci` che riguar- oda la creazione di uno schema, ovvero di un contenitore dei dati, a livelloapplicativo. Caratteristica peculiare delle basi di dai NoSQL ` infatti l’assenza di uno eschema predefinito dove collocare le informazioni provenienti dallo strato ap-plicativo. Si ritiene questa una caratteristica interessante nello scenario diriferimento, dove il volume, la quantit`, la tipologia del dato prodotto dal- al’applicazione non sono determinabili a priori. Per raggiungere l’obiettivo sopra delineato ` stato implementato uno estrumento software di verifica che verr` descritto in dettaglio nelle sezioni asuccessive di questo capitolo. Lo strumento permetter` di verificare la vali- adit` delle basi di dati NoSQL individuate nella Sezione 4.3. a 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 validit` di alternative alla gestione di dati di workflow di a 25
  27. 27. simulazione tramite RDBMS, in particolare utilizzando tecnologie non rela-zionali. Rimane a disposizione di Esteco, che potr` utilizzarlo per verificare ala qualit` di nuove tecnologie NoSQL qualora ne sorgesse la necessit`. a a4.2 Strumento di sperimentazioneLo 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. aCreare 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 u4.4.4.3 Individuare i candidatiI 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, 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
  28. 28. • 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 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  -­  OrientDBFigura 6: Le caratteristiche principali dei tre candidati server NoSQL.CRUD ` abbreviazione per Create, Read, Delete, Update, cio` le operazioni e edi creazione, lettura, cancellazione, aggiornamento. OM ` abbreviazione per eObject Mapping, cio` mappatura di oggetto. e Per ognuno dei tre candidati si riportano inoltre le peculiarit` nelle asezioni successive. A titolo di completezza si riportano inoltre i server NoSQL esclusi, conuna 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
  29. 29. • 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 OrientDBOrientDB [4] ` una base di dati NoSQL, open source, sviluppata interamen- ete in Java. Sebbene sia un database multimodello, le relazioni sono gestitecome 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 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 citt`. Il primo tipo adi record ritorna una rappresentazione di questo tipo con una operazioneSELECT.orientdb> select from country---+--------+-------------------- #| RID |name---+--------+-------------------- 0| #22:0|Italy 1| #22:1|France 2| #22:2|Spain3 item(s) found. Query executed in 0.012 sec(s). Il secondo invece viene rappresentato nel seguente modo: 28
  30. 30. orientdb> select from city---+---------+------------------+-------------------- #| RID |name |country---+---------+------------------+-------------------- 0| #21:0|Rome |#22:0 1| #21:1|Paris |#22:1 2| #21:2|Madrid |#22:23 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 aappartiene ad una nazione) viene riportata attraverso un ID numerico, checorrisponde al record stesso a cui la relazione porta. Tale propriet` rende possibile interrogazioni dove si pu` navigare tra i a orecord. Ad esempio ` immediata un’interrogazione complessa come la se- eguente, che in una base di dati relazionale avrebbe richiesto un JOIN tra ledue 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:24.3.2 MongoDBMongoDB [3] ` una base di dati non relazionale, orientata ai documenti, rila- esciata 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 ` la Figura 7, dove viene rappresentata una eipotetica mappatura tra il RDBMS MySQL e il NoSQL MongoDB. 29
  31. 31. Figura 7: Proposta di mappatura tra query SQL nel RDBMS MySQL elinea di comando JavaScript utilizzata nell’interrogazione in MongoDB. 30
  32. 32. 4.3.3 CassandraCassandra [1] ` un DBMS non relazionale, distribuito e open source, basato esu 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 ) ` leg- egermente fuorviante rispetto al modello di dati realmente usato, che ` un eibrido basato su chiave e valore, ma rappresentato come orientato alle co-lonne. In Cassandra, le righe contengono colonne. Per accedere alla pi` piccola uunit` di dato, cio` la colonna, bisogna specificare il nome della riga (cio` la a e echiave), 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 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 ouna variet`. Oppure si possono aggiungere colonne arbitrarie, ad esempio al’origine dell’arancio, in ogni momento. Si pu` pensare ai dati rappresentati oda cassandra come ad una tabella, ma sparsa e dove molti valori possonoessere vuoti. Ancora, un modello di dati orientato alle colonne pu` essere usato ad oesempio per liste e serie temporali, dove ogni colonna ` unica. Nell’esempio eseguente 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
  33. 33. 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 ImplementazioneViene di seguito descritto l’ambiente hardware e software nel quale sonostati eseguiti gli esperimenti. La descrizione dell’ambiente ` preceduta da eun breve paragrafo dove si delinea la metodologia di implementazione dautilizzare.4.4.1 PianificazioneCome 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 asul database di riferimento. Infine dovr` essere in grado di memorizzare i arisultati 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 ola 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: oinstallazione delle API Java nel progetto NetBeans;verifica della funzionalit` delle API creando connessioni con i server attivi; acreazione 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 euno stesso database NoSQL, in particolare OrientDB. Tale procedura si ` edimostrata di facile implementazione e ha permesso inoltre di interrogare 32
  34. 34. Figura 8: Sistema di visualizzazione dei risultati. 33
  35. 35. una base di dati di risultati attraverso il protocollo HTTP. Grazie a questapossibilit` ` stato creato il sistema di visualizzazione dei risultati, ra gurato aein Figura 8.4.4.2 Strumenti hardwareL’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 ebase di dati, non del client. L’architettura hardware rispecchia questa scelta:il server ` in esecuzione su una architettura Intel prodotta nel 2006, mentre eil 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 softwareIl 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
  36. 36. 4.4.4 InterconnessioneLa rete di connessione stabilita tra il client e il server ` una connessione back- eto-back (punto-punto) tra i due computer portatili utilizzati per il server eper il client. Poich´ la connessione punto-punto ha creato un collegamento etra 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 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 riterr` tra- ascurabile nei risultati di esperimento il contributo aggiuntivo, in termini ditempo, dato dal tunnel stesso.4.5 Struttura dei testVengono qui presentati le classi Java utilizzati per sperimentare i serverNoSQL. In base alle specifiche JPA ci si riferir` ad esse, nel seguito della atrattazione, anche come entit` di persistenza. aSimpleBean ` 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 oesempio 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 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 cheforniscono indicazioni sul tipo di dato trattato e sulla sua mappatura versola base di dati. Non contengono quindi import, setters, getters, eventuali 35
  37. 37. metodi aggiuntivi.SimpleBeanpackage 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
  38. 38. 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
  39. 39. 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 testLe caratteristiche delle tre entit` software presentate nella sezione preceden- ate 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 complessit` minore adi 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 considerazionepossono essere il risultato di una lettura dalla base di dati, quindi un input 38
  40. 40. o in generale un dato gi` esistente, oppure un dato da salvare sulla base di adati.4.7 MetodologiaLa metodologia di sperimentazione e le fasi che compongono un esperimentovengono ra gurate, in modo informale, in Figura 9.Figura 9: Rappresentazione informale della procedura di sperimentazione emisurazione implementata. In grigio sono rappresentati blocchi sviluppatiper il lavoro di tesi, in giallo parti software gi` disponibili, API native del aserver 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
  41. 41. • 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 risultatiLa 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. Figura 10: Metodologia di rilevazione dei risultati. Le liste sono utilizzate poi per ottenere gli oggetti su cui si eseguir`, per aciascuno, la chiamata della libreria che deve gestire la persistenza dell’ogget-to. Il tempo di rilevazione ` il tempo totale per eseguire questa operazione eper tutti gli elementi della lista. 40
  42. 42. 5 Analisi dei risultatiSi presentano in questo capitolo i risultati ottenuti nel corso della sperimen-tazione. Si ricordi che l’obiettivo dell’esperimento ` verificare la validit` di e auna 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, 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: auna 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 sperimentaliVengono 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 facilit` di mappatura, aespresso utilizzando aggettivi. Nei grafici, le ascisse corrispondono al numero di operazioni, mentre leordinate al tempo di esecuzione per concludere l’operazione di riferimento. 41
  43. 43. 5.1.1 InserimentoVengono 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. aCompositeBean 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 eMapBean 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
  44. 44. Figura 12: Inserimento nel database di CompositeBean. Figura 13: Inserimento nel database di MapBean. 43
  45. 45. 5.1.2 LetturaAnalogamente alla presentazione dei risultati di scrittura, si considerano perla 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
  46. 46. Figura 15: Lettura di CompositeBean. Figura 16: Lettura di MapBean. 45
  47. 47. 5.1.3 Lettura con selezioneSi 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 ` pari ea 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 ` il numero edi elementi considerato. Si noti che l’operazione ` di particolare interesse nello scenario di riferi- emento, dove ` usuale porre condizioni nelle interrogazioni eseguite su dati edi progetto nei workflow di simulazione (ad esempio selezione di design conparticolari caratteristiche). Questa operazione ` e↵ettuata in modo diverso su ogni base di dati. eNonostante l’obiettivo di ogni libreria di object mapping sia implementare lespecifiche JPA (Java Persistence API), non ` standard il metodo di selezione econ filtro. Le diversit` vengono presentate come segue (vengono spezzate le alinee di codice per comodit` di lettura): aMongoDB - 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
  48. 48. // 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 ` nettamente pi` veloce nel tempo di rispo- e usta di Cassandra. Questo potrebbe essere dovuto al driver Java nativo diOrientDB per l’object mapping. Cassandra utilizza Kundera, che ` una li- ebreria utilizzabile per eseguire object mapping anche su altre basi di datiNoSQL, quindi meno specializzata. Figura 17: Lettura di SimpleBean con selezione della popolazione. 47
  49. 49. 5.1.4 Mappatura dei campi delle entit` aLa Figura 18 mostra come i di↵erenti database NoSQL implementano lamappatura di diversi tipi di entit` Java. A sinistra riporta i tipi di entit` a aconsiderata ed i campi di ciascuna entit`, mentre a destra riporta le API aper la mappatura degli oggetti e come ciascuna base di dati gestisce i campirelativi 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 aNoSQL. Come si osserva dalla Figura 18, non si ` potuto procedere alla map- epatura di implementazioni di Map su Cassandra. Queste non sono infattisupportate dalla libreria di object mapping Kundera. Al momento di spe-rimentare Cassandra si ` quindi istanziato un oggetto di tipo ArrayList in eluogo 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 auna base di dati di riferimento (MongoDB): 48

×