DMS su database schemaless, il progetto HDOC

Capitolo 1 : INTRODUZIONE
1 INTRODUZIONE
Il capitolo introduce il concetto di database schemaless ed il contesto di utilizzo di quest'ultimi in relazione 
ai Document Management System (DMS). Si delineano poi gli obiettivi e la struttura della tesi.
1.1Contesto “In pioneer days they used oxen for heavy pulling, 
and when one ox couldn’t budge a log,
they didn’t try to grow a larger oxen. 
We shouldn’t be trying for bigger computers, 
but for more systems of computers.”
[Grace Hopper] Negli ultimi anni ha assunto sempre più importanza una nuova classe di 
applicazioni web, chiamata social network, che concentra l'attenzione sull'individuo, sulle 
sue relazioni sociali e sulle sue attività.
Questo tipo di applicazioni, identificate con il termine “Web 2.0”, hanno 
comportato sostanziali cambiamenti nelle modalità di fruizione del software, rendendo 
centrali i concetti di condivisione di informazioni  e collaborazione tra gli utenti.
 Questa classe di applicazioni, di recente, ha registrato un tasso molto elevato di 
crescita degli utenti e ha visto i portali web passare da migliaia a centinaia di milioni di 
utenti. 
Il numero estremamente elevato di utenti dei social network ed il processo di 
decentramento di generazione dei contenuti hanno portato ad un aumento esponenziale 
della quantità di dati trattati.
Lo stesso discorso vale anche per i motori di ricerca che, come i social network, 
devono gestire dataset di grandissime dimensioni e parallelamente garantire elevate 
prestazioni. Quest'ultima classe di applicazioni inoltre, deve trattare dati (le pagine web) 
molto eterogenei tra loro che risultano non facili da conservare in basi di dati strutturate.
Tutto ciò ha spinto le aziende interessate a ricercare nuovi sistemi di persistenza 
 6
Capitolo 1 : INTRODUZIONE
che garantissero estrema scalabilità, flessibilità nella gestione dello schema e alte 
prestazioni superando la tradizionale architettura basata su database relazionali.
Così dalla ricerca intrapresa da aziende come Facebook, Twitter, Digg, LinkedIn, 
Google, Amazon e Yahoo è nata una nuova classe di database, identificata con il nome 
NoSQL, le cui caratteristiche principali sono : scalabilità orizzontale, schema-free, 
architettura distribuita, e ventually consistence e high performance.
Tuttavia, questi nuovi sistemi di persistenza, ideati nell'ambito di grandi aziende ed 
organizzazioni, non sono solo destinati a risolvere i problemi dei grandi motori di ricerca e 
dei grandi portali di social network. I problemi emersi da questa analisi, identificati in 
informatica nel termine “ Big Data ”,  chiamano in causa anche piccole e medie 
organizzazioni e contesti applicativi differenti.
Entrano a pieno titolo in questa trattazione, infatti, anche i Document Management 
System (DMS), che similmente ai contesti applicativi precedenti, devono trattare grandi 
quantità di contenuti, di tipi e formati diversi. I DMS, nati nel 1980, forniscono tutte quelle 
funzionalità necessarie per l'archiviazione, la manipolazione, la pubblicazione e la ricerca 
di documenti. 
In questi ultimi anni si sta assistendo anche alla nascita di nuovi modelli di 
distribuzione e consumo del software, identificati con l'acronimo Saas (Software as a 
Service), che forniscono accesso al software via web on demand, abbattendo i costi di 
acquisto della licenza.
Questa nuova modalità presenta spesso un modello di distribuzione del sistema di 
tipo one-to-many in cui una singola istanza applicativa “serve” molti utenti e 
organizzazioni differenti (multi-tenant).
La modalità di distribuzione Saas pertanto, lancia nuove sfide nel campo dei DMS e 
accentua ancora di più i problemi dovuti all'aumento dei dati, degli utenti ed ai sempre più 
stringenti requisiti di SLA  (Service Level Agreement).
Per tutte queste ragioni i DMS dovranno innovare la propria architettura per 
affrontare le nuove sfide. Si dovranno sviluppare DMS basati su architetture altamente 
scalabili e cloud-based che possano rispondere facilmente ad una richiesta sempre 
 7
Capitolo 1 : INTRODUZIONE
crescente di risorse.
Per fare ciò nel contesto dei DMS di grandi dimensioni risulta conveniente 
utilizzare sistemi di persistenza NoSQL al posto dei database relazionali. Questi database, 
infatti, presentano un data model congeniale all'ambito documentale, che è intrinsecamente 
semi-strutturato. I database NoSQL inoltre offrono nativamente un set di funzionalità che 
risulterebbe complicato e dispendioso sviluppare usando un database relazionale.
E' alla luce di queste considerazioni che si colloca il presente lavoro di tesi. 
L'obiettivo perseguito è quello di progettare ed implementare un prototipo di DMS in Java 
utilizzando un sistema di persistenza schemaless NoSQL.
1.2Obiettivi L'obiettivo del presente lavoro di tesi è quello di realizzare un prototipo di 
Document Management System (DMS) in Java su un database schemaless NoSQL, in 
modo da sfruttare i fattori di innovatività sia funzionale che architetturale offerti da questi 
sistemi di storage. 
Il perseguimento di questo obiettivo richiede di:
• Definire il contesto e le esigenze dei DMS e dei database schemaless 
NoSQL;
• Definire lo stato dell’arte dei database schemaless NoSQL e descrivere i 
casi di successo del loro utilizzo in grandi contesti applicativi; 
• Analizzare e confrontare i diversi progetti schemaless per rilevare i punti 
di forza, le criticità ed i limiti esistenti ed individuare le best practices 
per la progettazione;
• Individuare i requisiti e progettare con il supporto della metodologia 
UML, tenendo in considerazione le specifiche emerse dallo studio sullo 
stato dell’arte e dell'analisi comparativa, un DMS in Java distribuito e 
scalabile su un database schemaless NoSQL;
• Progettare, secondo la metodologia WAE, una web application che 
 8
Capitolo 1 : INTRODUZIONE
fornisca l'accesso remoto alle funzionalità offerte dal DMS realizzato;
• Implementare il prototipo del DMS progettato utilizzando tecnologie 
che offrono scalabilità e performance elevate;
• Implementare il prototipo della web application a supporto del DMS.
1.3Struttura della tesi Una prima fase di ricerca di fonti e documenti è stata necessaria per comprendere il 
concetto di Document Management System (DMS) e di database schemaless NoSQL. In 
questa fase si è analizzato il contesto di utilizzo dei suddetti database e come questi 
possono essere utilizzati nel campo documentale. I risultati di questa fase sono riportati nel 
Capitolo 1.
Successivamente si è analizzato, tramite la consultazione di articoli, libri e ricerche 
sul Web lo stato dell’arte dei più importanti database schemaless NoSQL esistenti sul 
mercato e i casi di successo del loro utilizzo in grandi contesti aziendali. I risultati di 
questa analisi sono presenti nel Capitolo 2.
Conclusa questa fase è stata effettuata un'analisi comparativa delle soluzioni 
schemaless precedentemente trattate. L'obiettivo è stato quello di produrre una 
classificazione delle stesse che mostrasse di ognuna le caratteristiche e i punti di forza ma 
anche i limiti e le criticità rispetto il contesto documentale. L'analisi comparativa ha poi 
prodotto le linee guida che hanno orientato la fase di progettazione (Capitolo 3).
Durante la progettazione, effettuata tenendo in debita considerazione le indicazioni 
emerse dallo studio sullo stato dell’arte, si sono individuati i requisiti ed è stato progettato 
il sistema utilizzando la metodologia UML e WAE (Capitolo 4).
Dopo la fase di progettazione si è passati all'implementazione della soluzione DMS 
in Java utilizzando il database schemaless distribuito Apache HBase di Hadoop ed il search 
engine Apache Solr. Oltre al gestore documentale è stato realizzato anche un prototipo di 
web application in tecnologia Spring MVC che permette l'accesso remoto al repository. I 
dettagli implementativi sono contenuti nel Capitolo 5.
 9
Capitolo 1 : INTRODUZIONE
Il capitolo 6 contiene una valutazione dei risultati ottenuti in relazione agli obiettivi 
prefissati e le conclusioni sul lavoro svolto. 
 10
Capitolo 2 : CONTESTO E STATO DELL'ARTE
2 CONTESTO E STATO DELL'ARTE
In questo capitolo vengono descritti i Document Management System e le funzionalità da essi fornite, 
successivamente si introduce il concetto di database structured, si analizza il contesto di applicazione, le 
tipologie esistenti, lo stato dell'arte e i casi di successo dell'applicazione di tali database in contesti di 
grandi dimensioni.
“One Size Fits All”: An Idea Whose Time Has Come and Gone [Michael Stonebraker] 2.1Introduzione Negli ultimi 25 anni i database relazionali hanno assunto un'importanza assoluta nel 
contesto delle basi di dati, tanto che il termine database alcune volte viene usato come 
sinonimo per indicare database relazionali quali Oracle, Sql Server, MySQL o 
PostgreSQL.
Questa situazione può essere riassunta dalla seguente frase : ”One size fits all”, che 
sintetizza come in questi anni lo stack LAMP
1
 abbia fornito le basi per la realizzazione di 
un numero estremamente grande di portali web.
In particolare i DBMS relazionali sono stati usati per supportare un gran numero di 
applicazioni data-centric con un gran numero di caratteristiche e requisiti differenti.
Aumento dei dati e scalabilità Parallelamente a questa staticità manifestata da alcuni vendor nell'innovare alcuni 
aspetti architetturali dei sistemi di storage tradizionali, si è registrato in questi anni un 
aumento sempre più grande del numero di dati digitali scambiati nel mondo e quindi sul 
web.
Alcune indagini commissionate ad IDC [ [idc]]  rilevano che nel 2010 saranno 
prodotti e scambiati 988 miliardi di gigabytes di dati, sei volte maggiori rispetto al solo 
2006. La stessa indagine dimostra che l'esplosione di dati prodotta in questi anni porterà 
1 LAMP : Linux, Apache, MySQL, Php 11
Capitolo 2 : CONTESTO E STATO DELL'ARTE
nuove sfide alle aziende nell'ottica della riduzione dei costi IT per la loro gestione e sancirà 
un punto importante nella buona riuscita di alcune di esse sul mercato.
Queste indagini tuttavia che se da una parte puntano la loro attenzione nell'ambito 
delle grandi aziende ed organizzazioni, non ci devono far pensare che questi problemi 
siano soltanto dei grandi motori di ricerca o dei grandi sistemi applicativi nel settore 
scientifico o finanziario. Questo problema, chiamato “ Big Data” [hadoop] chiama in causa 
anche piccole organizzazioni e gli stessi individui.
L'aumento dei dati è dovuto anche ad un numero sempre maggiore di persone che si 
affacciano su Internet ed usano quotidianamente il computer. In questi ultimi anni inoltre si 
è assistito al decentramento del processo di generazione dei contenuti dovuto 
prevalentemente ai social network e all'aumento conseguente della mole di dati scambiata.
Le cause del problema sono semplici : mentre la capacità di archiviazione degli 
hard disk sono aumentate enormemente in questi anni, la velocità di accesso (la velocità 
con cui i dati possono essere letti dal disco) non ha seguito questo trend. Un normale disco 
del 1990 poteva archiviare 1370 MB di dati e aveva una velocità di trasferimento di circa 
4.4 MB/s. In questo modo si potevano leggere tutti i dati contenuti nel dispositivo in circa 
cinque minuti. Dopo venti anni, dischi di 1 terabyte sono la norma, ma il transfer rate è di 
circa 100 MB/s. Con queste specifiche sono necessarie due ore e mezzo per leggere tutti i 
 12 
Illustrazione 1: Aumento dei dati
Capitolo 2 : CONTESTO E STATO DELL'ARTE
dati contenuti nel disco. 
Risulta evidente che il tempo per la lettura di tutti i dati su un singolo device è 
grande e la via ovvia per risolvere questo problema è la lettura dei dati da più dischi 
contemporaneamente. Questo approccio però, nel caso in cui il numero di device risulta 
grande, porta a dei problemi noti riguardanti la gestione degli errori di lettura, molto più 
probabili in presenza di hardware parallelo. Una via comune per evitare questo ed altri 
problemi è la ridondanza dei dati : copie ridondati di dati vengono distribuite nel sistema in 
modo tale che nel caso avvenga una failure, esiste sempre un altra copia disponibile. 
Questo problema, in generale, sotto l'aspetto della conservazione dei dati in forma 
destrutturata, viene risolto comunemente con i sistemi RAID, nel caso in cui il numero di 
device è limitato oppure con file system distribuiti nel caso di numero elevato di nodi, di 
cui ultimamente sono nate alcune importanti implementazioni, quali : Google File System 
e HDFS di Hadoop.
Nel caso dei database e quindi nella gestione di dati strutturati invece, l'aumento dei 
dati ha portato, in questi ultimissimi anni alla nascita di database, identificati sotto 
l'acronimo nosql, che hanno nella scalabilità e nelle prestazioni il loro obiettivo primario. 
Con questi nuovi database, diversamente dai classici database relazionali, si 
possono creare sistemi composti da centinaia e migliaia di nodi invece che decine. E' 
possibile archiviare grandissimi numeri di dati, composti da miliardi di righe e milioni di 
colonne, che vengono automaticamente partizionati orizzontalmente su centinaia di 
macchine commodity.
Naturalmente, questi risultati nei database nosql, sono stati raggiunti cambiando 
l'architettura ma più in generale cambiando il rapporto tra disponibilità e consistenza. In 
questi sistemi caratterizzati da architetture altamente scalabili e profondamente distribuite 
con politiche di prossimità geografica si punta fortemente sulle prestazione e sulla 
disponibilità dei dati piuttosto che sulla consistenza (Eventual consistency). Si passa 
dall’approccio transazionale ACID (Atomicity, Consistency, Isolation, Durability ) ad un 
approccio BASE (Basic Available, Soft-state, Eventual consistency ).
Altro problema comune, in generale nel campo dell'analisi, dove è grande la 
dimensione dei dati, è la necessita di combinare insieme informazioni che potrebbero 
 13
Capitolo 2 : CONTESTO E STATO DELL'ARTE
essere contenute in device differenti che porta ad un aumento delle comunicazioni tra 
sistemi differenti ed ad un conseguente abbassamento delle performance. A questo ed altri 
problemi si riferisce il modello di programmazione MapReduce che astrae il problema 
della lettura e scrittura di dati su multidevice, trasformando l'intera computazione in un 
insieme di coppie chiave/valore.
Tutti questi sistemi precedentemente descritti, siano essi file system distribuiti, 
database nosql o sistemi MapReduce, trovano nel Cloud Computing il loro contesto 
naturale di utilizzo, dove scalabilità, prestazioni e flessibilità sono fattori essenziali. 
Web 2.0
Accanto alla crescita esponenziale dei dati, negli ultimi anni si assiste anche ad una 
evoluzione di Internet, chiamata Web 2.0, caratterizzata dalla presenza di portali e 
applicazioni web progettati intorno all'utente in cui è fondamentale la condivisione di 
informazioni.
In questi sistemi diventa sempre più importante il concetto di connessione. Infatti 
mentre nel Web 1.0 le pagine web, erano debolmente collegate tra loro mediante 
collegamenti ipertestuali ed il numero di link all'interno della stessa pagina era dell'ordine 
delle decine, nelle applicazioni Web 2.0 il numero di collegamenti tra le diverse entità è 
estremamente elevato. Nelle applicazioni 2.0, infatti, come i social network e i “wiki” 
molti utenti comunicano tra loro e intervengono contemporaneamente alla stesura di 
contenuti o dialoghi. 
Questo trend (fig. 2) porterà sempre più le applicazioni ad operare su dati connessi 
e fortemente collegati tra loro che ben si prestano ad essere modellati secondo un grafo o 
una rete. Sono esempi di queste applicazioni : il web semantico, le ontologie, le 
folksonomie ma anche i social network, i content management system ed i sistemi di 
business intelligence e molti altri. 
Il problema esistente nel trattare informazioni di tipo gerarchico o a grafo nel 
contesto relazionale è dovuto al fatto che ogni relazione e più in generale ogni “salto” su 
un arco tra due nodi viene trasformato in una operazione di join. Il graph traversing, quindi 
diviene in un RDBMS, in caso di grafi complessi o strutture gerarchiche profonde, una 
 14