UNIVERSITÀ DEGLI STUDI DI PADOVA - SIAGAS
←
→
Trascrizione del contenuto della pagina
Se il tuo browser non visualizza correttamente la pagina, ti preghiamo di leggere il contenuto della pagina quaggiù
U NIVERSITÀ DEGLI S TUDI DI PADOVA
D IPARTIMENTO DI M ATEMATICA
C ORSO DI L AUREA IN I NFORMATICA
T ESI DI L AUREA
S VILUPPO DI ALGORITMI DI SINCRONIZZAZIONE DI DATABASE SU
MACCHINE DIVERSE UTILIZZANDO STRUTTURE DATI PROBABILISTICHE
A ZIENDA OSPITANTE L AUREANDO
Zucchetti S.p.A. Lorenzo Menza
Sede Op. di Padova 543646-SIN
T UTOR AZIENDALE R ELATORE
Dott. Gregorio Piccoli Prof.ssa Silvia Crafa
A NNO ACCADEMICO 2015-2016 (794◦ )
Sommario
Il presente lavoro di tesi illustra tre soluzioni algoritmiche, frutto di uno stage aziendale univer-
sitario, al problema della database reconciliation, ovvero alle problematiche di sincronizzazione di
un database residente in copie locali su macchine diverse, rappresentate essenzialmente in un
corretto merging delle modifiche apportate su tali copie. Tali soluzioni, sviluppate per un contesto
server/client, prevedono un’analisi diretta sul contenuto della base di dati in termini di metadati e
soprattutto di record utilizzando un approccio concettuale simile a quello dell’algoritmo rsync per la
sincronizzazione di file system, e risultano ottimali per scenari in cui la cardinalità di tali differenze
rappresenta una frazione ridotta del contenuto complessivo del database.
Il primo capitolo illustra lo scenario, il dominio applicativo e gli obiettivi del progetto. Nel secondo
capitolo è formalizzata la pianificazione e sono elencate le tecnologie utilizzate per lo sviluppo. Il
terzo capitolo presenta e discute le strategie algoritmiche sviluppate, la struttura del software e le
modalità di risoluzione delle criticità ad esso associate. Il quarto capitolo presenta e discute i risultati
del prodotto in termini di prestazioni ed affidabilità. Nel quinto capitolo, infine, è effettuata un’analisi
critica di prodotto e stage nel suo complesso.
IIIRingraziamenti
Ringrazio il mio tutor aziendale, Dott. Gregorio Piccoli, per la disponibilità ed il supporto necessa-
rio alla realizzazione del progetto.
Ringrazio il mio relatore, Prof.ssa Silvia Crafa, per la pazienza ed il supporto fornitomi per la
redazione della presente tesi di laurea.
Ringrazio i miei genitori Giuseppe ed Antonina per non aver mai smesso di credere in me ed
avermi supportato e spronato per tutta la durata degli studi.
Ringrazio tutti gli amici, quelli conosciuti all’Università e quelli che conosco da una vita, quelli che
ho perso di vista e quelli che sono ancora al mio fianco; senza ciascuno di essi, nel bene e nel male,
non sarei ciò che sono.
Infine ringrazio Federica, dolce compagna della mia vita, per essermi sempre stata accanto, nei
momenti bui come in quelli felici, per illuminare i miei giorni, e per avermi insegnato, fin dal primo
giorno, che niente è impossibile se c’è l’amore.
VA te, azzurro del mio cielo.
Indice
1 Contesto Aziendale 1
1.1 L’Azienda . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1
1.2 Dominio applicativo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
1.3 Obiettivi . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
2 Pianificazione 5
2.1 Requisiti . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
2.2 Tecnologie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
2.3 Piano di lavoro . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
3 ZSync 11
3.1 Algoritmi sviluppati . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
3.1.1 IZF . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
Analisi probabilistica dell’algoritmo IZF . . . . . . . . . . . . . . . . . . . . . . 14
3.1.2 IBF . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
IBF Encode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
IBF Subtract . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
IBF Decode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
Analisi probabilistica dell’algoritmo IBF . . . . . . . . . . . . . . . . . . . . . . 20
3.1.3 IBZF . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
Analisi probabilistica dell’algoritmo IBZF . . . . . . . . . . . . . . . . . . . . . 22
3.2 Architettura del programma . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
3.2.1 Decomposizione architetturale . . . . . . . . . . . . . . . . . . . . . . . . . . 23
3.2.2 Componente Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
3.2.3 Componente View . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
3.2.4 Componente Presenter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
3.2.5 Package Main . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
3.3 Aspetti implementativi degli algoritmi sviluppati . . . . . . . . . . . . . . . . . . . . . 29
3.4 JDBC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
3.5 Interfaccia . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
3.6 Concorrenza e distribuzione . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
4 Risultati 45
4.1 Prestazioni ed affidabilità . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
4.2 Test sperimentali . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
4.2.1 Correttezza . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
4.2.2 Prestazioni . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
5 Conclusioni 51
5.1 Analisi critica del prodotto . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51
5.2 Valutazione retrospettiva dello stage . . . . . . . . . . . . . . . . . . . . . . . . . . . 53
5.2.1 Consuntivo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53
5.2.2 Analisi personale dello stage . . . . . . . . . . . . . . . . . . . . . . . . . . . 54
IXINDICE Glossario 57 Bibliografia 61 X
Elenco delle figure
1.1 Logo dell’Azienda ospitante, Zucchetti S.p.A. . . . . . . . . . . . . . . . . . . . . . . 2
2.1 Architettura dell’API JDBC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
2.2 Diagramma di Gantt preventivo delle attività di stage . . . . . . . . . . . . . . . . . . 9
3.1 Diagramma delle classi, classe model.share.IZLT . . . . . . . . . . . . . . . . . 13
3.2 Diagramma delle classi, classe model.share.IBLT . . . . . . . . . . . . . . . . . 17
3.3 Procedura IBF Encode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
3.4 Procedura IBF Subtract . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
3.5 Procedura IBF Decode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
3.6 Implementazione del pattern Model-View-Presenter . . . . . . . . . . . . . . . . . . 23
3.7 Diagramma dei package, componente Model . . . . . . . . . . . . . . . . . . . . . . 24
3.8 Diagramma dei package, componente View . . . . . . . . . . . . . . . . . . . . . . . 26
3.9 Diagramma dei package, componente Presenter . . . . . . . . . . . . . . . . . . . . 27
3.10 Diagramma dei package, componente Main . . . . . . . . . . . . . . . . . . . . . . . 28
3.11 Diagramma delle classi, package model.filter . . . . . . . . . . . . . . . . . . . 30
3.12 Diagramma delle classi, package model.jdbc . . . . . . . . . . . . . . . . . . . . 31
3.13 Gerarchia della componente View . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
3.14 Interfaccia grafica di un server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
3.15 Interfaccia grafica di un client . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
3.16 Diagramma delle classi, componente View . . . . . . . . . . . . . . . . . . . . . . . 36
3.17 Diagramma delle classi, c.i. view.abstr.NetworkMachineGUI.RecordBar . 37
3.18 Gerarchia della componente Presenter . . . . . . . . . . . . . . . . . . . . . . . . . 38
3.19 Diagramma delle classi, interfacce remote della componente Presenter . . . . . . . . 39
3.20 Diagramma delle classi, oggetti remoti della componente Presenter . . . . . . . . . . 40
3.21 Diagramma delle classi, classe model.share.TextFile . . . . . . . . . . . . . . 42
3.22 Diagramma delle classi, classe model.share.CustomException . . . . . . . . 43
3.23 Diagramma delle classi, package main.server . . . . . . . . . . . . . . . . . . . . 44
3.24 Diagramma delle classi, package main.client . . . . . . . . . . . . . . . . . . . . 44
5.1 Diagramma di Gantt consuntivo delle attività di stage . . . . . . . . . . . . . . . . . . 55
XIElenco delle tabelle
2.1 Requisiti del software . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
2.2 Calendario delle attività di stage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
3.1 Valori di n(10−15 ; d) al variare di d . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
4.1 Risultati dei test di correttezza degli algoritmi . . . . . . . . . . . . . . . . . . . . . . 48
4.2 Risultati dei test prestazionali sugli algoritmi sviluppati: prestazioni per tabella . . . . 49
4.3 Risultati globali dei test prestazionali . . . . . . . . . . . . . . . . . . . . . . . . . . . 49
5.1 Soddisfacimento dei requisiti software . . . . . . . . . . . . . . . . . . . . . . . . . . 51
5.2 Consuntivo delle attività di stage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53
XIIICapitolo 1
Contesto Aziendale
I NDICE
1.1 L’A ZIENDA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1
1.2 D OMINIO APPLICATIVO . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
1.3 O BIETTIVI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
La formazione universitaria è essenziale per fornire al futuro informatico gli strumenti teorici, le
conoscenze pratiche di base e la forma mentis necessaria per intraprendere un proficuo percorso
professionale nel mondo del lavoro. Tuttavia, il percorso accademico a sé stante non può preparare
adeguatamente l’individuo all’ambiente aziendale ed agli aspetti quotidiani del mondo del lavoro, e
tale lacuna rappresenta probabilmente il più grande scoglio che un neolaureato si trova ad affrontare
alla prima esperienza lavorativa.
Per ovviare a questa problematica, il Corso di Laurea in Informatica prevede la possibilità di svol-
gere uno stage aziendale al termine del percorso di studi: un prezioso strumento che permette
al laureando di essere inserito in un ambiente aziendale, svolgendo un’attività lavorativa equipara-
bile a quella di un dipendente dell’azienda ospitante, e rappresenta un reciproco beneficio per le
parti coinvolte. Infatti l’azienda ospitante ha la possibilità di beneficiare del lavoro svolto dallo stu-
dente, eventualmente valutandone il prosieguo della collaborazione e/o la possibilità di inserimento
nell’organico aziendale, svincolata dagli oneri contrattuali; dal canto suo, il laureando beneficerà
dell’esperienza lavorativa e della crescita professionale, permettendogli importanti valutazioni sulle
proprie capacità, competenze nuove e pregresse e sull’impatto con la realtà lavorativa.
I percorsi di stage rappresentano anche un’opportunità per valutare soluzioni innovative sen-
za sottrarre eccessive risorse all’organico aziendale, anzi valutando il potenziale di una possibile
risorsa.
1.1 L’Azienda
Il contesto appena descritto rispecchia appieno l’opportunità offertami dall’Azienda ospitante il
mio percorso di stage: Zucchetti S.p.A.
Con oltre 2800 addetti, una rete distributiva che supera i 1100 Partner sull’intero territorio nazio-
nale e oltre 100 000 clienti, il gruppo Zucchetti è uno dei più importanti protagonisti italiani del settore
dell’IT.
Il gruppo Zucchetti offre soluzioni software, hardware e servizi ad aziende, commercialisti, consu-
lenti del lavoro e associazioni di categoria che desiderano acquisire importanti vantaggi competitivi
e avvalersi di un unico Partner informatico in grado di soddisfare le più svariate esigenze di carattere
tecnologico [1].
Nel 2014 il gruppo Zucchetti si riconferma per il quarto anno consecutivo la prima software house
italiana per fatturato software e servizi a livello europeo, a riprova del ruolo di primo piano rivestito
dal Gruppo lodigiano nel settore [2].
Pagina 1 di 61CAPITOLO 1. CONTESTO AZIENDALE
Figura 1.1: Logo dell’Azienda ospitante, Zucchetti S.p.A.
L’Azienda, ospitante la mia attività di stage nella sede operativa di Padova, mi ha assegnato il
compito di valutare la fattibilità tecnologica di una metodologia sperimentale di sincronizza-
zione di database su macchine diverse, facente uso di tecniche e strutture dati probabilistiche,
fornendone un prototipo funzionante e la documentazione tecnica necessaria.
1.2 Dominio applicativo
Il dominio applicativo del progetto assegnatomi dall’Azienda è relativo ad uno scenario di comune
nell’ambito dei database distribuiti, ovvero la necessità di integrare le modifiche effettuate da due
macchine di rete differenti, situate verosimilmente in località molto distanti tra loro, su due copie
locali in possesso di queste entità remote.
Tali copie possono essere situate fisicamente sulle macchine in esame, oppure nella loro rete lo-
cale. Il database distribuito sarà verosimilmente di grandi dimensioni, dell’ordine tipico di milioni
di record; tuttavia, l’insieme delle differenze maturate tra le due copie del database avrà cardi-
nalità ridotta rispetto alle dimensioni complessive (nello scenario ipotizzato, poche migliaia di
record). Questo scenario è tipico di una azienda in possesso di un database aziendale distribuito
contenente una notevole mole di dati non soggetti a transazioni critiche in tempo reale (ad esempio
statistiche) che, con frequenza giornaliera, effettui un processo di database reconciliation sulla
base di dati per rendere coerente lo stato dei dati distribuiti, integrando le differenze complessive
maturate nel corso della giornata.
La distanza tra le macchine coinvolte e la notevole mole di dati imporrà di minimizzare l’inter-
scambio di tali dati in rete; inoltre, il tempo di calcolo complessivo non dovrà essere molto elevato. Il
programma sarà di tipo server/client distribuito, ovvero una delle due macchine avvierà l’applicativo
in modalità server , svolgendo in locale la componente di elaborazione algoritmica delle differen-
ze, mentre l’altra macchina avvierà l’applicativo in modalità client, cooperando con il server al fine
dell’analisi del contenuto della propria copia locale.
L’approccio tipico al problema della database reconciliation sopra descritto si basa sull’analisi dei
log delle operazioni svolte sulle copie locali del database, riproducendone le operazioni effettuate.
Tale metodologia, seppur efficiente, dipende dallo specifico DBMS utilizzato per la gestione della
base di dati; richiede inoltre l’aggiornamento di tale log ogniqualvolta vengano effettuate operazioni
sui dati e soffre di problemi di scalabilità quando si debbano riconciliare le modifiche effettuate da
molteplici utenti [3].
Per contro, tentare di svolgere un tale processo di sincronizzazione tramite l’analisi diretta dei
record di un database distribuito di grandi dimensioni è improponibile non appena le copie locali
non siano situate al più in una rete locale, in quanto la mole di dati necessaria per l’analisi delle
differenze ammonterebbe a centinaia di MB od anche a svariati GB; inoltre, per il caso di interesse,
sarebbe del tutto inappropriata, dato che la quantità dei dati differenza da scambiare tra le due
macchine sarebbe tranquillamente gestibile tramite comunicazione di rete utilizzando altri approcci
al problema.
Pagina 2 di 611.3. OBIETTIVI
La metodologia in esame in questo progetto di stage si propone di risolvere il problema della
database reconciliation analizzando direttamente il contenuto della base di dati distribuita in termi-
ni di singoli record, ottimizzando lo scambio dati tra le entità server/client coinvolte. Per perseguire
tale scopo, è stata necessaria la messa a punto di una tecnica di elaborazione che permetta l’ana-
lisi dei dati in possesso del client sulla macchina server , codificandoli ed aggregandoli in apposite
strutture dati che ne permettano un interscambio ottimale in termini di traffico di rete.
In questo senso, il tipo di analisi effettuato utilizza un approccio analogo a quello dell’algoritmo
rsync comunemente usato per sincronizzare singoli file, directory od interi file system tra una sor-
gente ed una destinazione. Tale algoritmo, infatti, opera analisi sui singoli file già presenti a destina-
zione, dividendoli in blocchi e calcolandone apposite signature, le quali vengono inviate al mittente
ed utilizzate in modo efficiente per analizzare i dati dei file in suo possesso; tramite questo proces-
so, il mittente è in grado di inviare solo il reale flusso di blocchi necessario per ricomporre i propri
dati a destinazione, e di istruire la destinazione su come utilizzare i dati già in suo possesso per
sincronizzare il proprio stato con quello della sorgente. Per la trattazione approfondita dell’algoritmo
rsync si veda [4].
È importante puntualizzare come la metodologia in esame nel corso dell’attività di stage sia
applicabile fintanto che la cardinalità delle differenze tra le due copie locali non risulti troppo
elevata. Difatti, al crescere di tale cardinalità conseguirà una crescita proporzionale della quantità
di dati da scambiare tra le due macchine ed un aumento anche critico dei tempi di elaborazione
algoritmica e di consumo delle risorse a disposizione delle macchine di rete.
1.3 Obiettivi
Alla luce dell’analisi svolta, gli obiettivi del prodotto software oggetto dello stage possono
essere così riassunti:
• L’analisi algoritmica volta a rendere possibile il processo di sincronizzazione del database
distribuito dovrà essere effettuata direttamente sui record in modo indipendente dal DBMS
sottostante
• Il prodotto dovrà essere in grado di supportare diversi DBMS, quali Microsoft SQL Server|g| ,
PostgreSQL|g| , MongoDB|g| , etc. ed interfacciarvisi correttamente
• L’interscambio dati tra le entità server e client coinvolte ai fini della sincronizzazione dovrà
essere minimale ed ottimizzato il più possibile
• Il costo computazionale ed il tempo complessivo di esecuzione del programma dovran-
no essere minimizzati per quanto possibile, e le risorse utilizzate dovranno essere ot-
timizzate, il tutto ai fini di interferire il meno possibile con l’operatività della base di dati
distribuita
• I risultati dell’elaborazione del programma dovranno rendere possibile la realizzazione
della sincronizzazione del database distribuito
Dalla descrizione degli obiettivi dello stage appare evidente come sia stato posto il focus sul-
l’efficienza e l’efficacia dell’analisi algoritmica. A questo proposito, l’Azienda non ha ritenuto
necessario implementare procedure che effettuino realmente il processo di sincronizzazione delle
due copie della base di dati, a patto che i risultati ottenuti dall’esecuzione del programma vengano
memorizzati in modo persistente in una forma che renda praticabile tale passo senza bisogno di
effettuare alcuna ulteriore analisi sui dati.
Pagina 3 di 61Capitolo 2
Pianificazione
I NDICE
2.1 R EQUISITI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
2.2 T ECNOLOGIE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
2.3 P IANO DI LAVORO . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
Al fine di perseguire gli obiettivi prefissati per il progetto di stage, si è resa necessaria un’analisi
preliminare dei requisiti del prodotto e delle tecnologie necessarie per lo sviluppo del software,
le cui conclusioni si concretizzano in un piano di lavoro concordato tra stagista e tutor aziendale.
Questo passo è necessario per razionalizzare i processi di sviluppo e massimizzare le probabilità di
successo dello stage.
2.1 Requisiti
Dallo scenario di applicabilità del programma e dagli obiettivi prefissati discussi in sezione 1.3
è derivata la seguente formalizzazione dei requisiti del prodotto software oggetto dello stage,
riportata in Tabella 2.1.
Tabella 2.1: Requisiti del software
Codice Tipologia Descrizione
OBL-01 Obbligatorio Il software deve essere in grado di determinare la compatibilità
tra le copie locali del database in termini di struttura e metadati
OBL-02 Obbligatorio Il software deve essere in grado di effettuare un’analisi algorit-
mica sui record del database distribuito, producendo i risultati
propedeutici all’integrazione delle differenze tra le copie locali
server e client
OBL-03 Obbligatorio Il software deve poter effettuare l’analisi algoritmica in modo
indipendente dal DBMS sottostante
OBL-04 Obbligatorio Il software deve minimizzare ed ottimizzare l’interscambio dati
tra le entità di rete coinvolte nel processo di sincronizzazione
OBL-05 Obbligatorio Il software deve minimizzare il costo computazionale ed il
tempo di esecuzione complessivo del processo di analisi
OBL-06 Obbligatorio Il software deve ottimizzare l’utilizzo delle risorse macchina per
quanto possibile
continua
Pagina 5 di 61CAPITOLO 2. PIANIFICAZIONE
Tabella 2.1 - continua
Codice Tipologia Descrizione
OBL-07 Obbligatorio Il software deve produrre un output che consenta una succes-
siva database reconciliation senza ulteriori analisi sulla base
di dati distribuita
OBL-08 Obbligatorio Il software deve fornire un’interfaccia grafica minimale, sia sul
server che sul client, che permetta all’utente una corretta ed
intuitiva interpretazione dell’andamento del programma e dei
risultati prodotti, nel rispetto delle limitazioni sopra discusse
OBL-09 Obbligatorio Il software deve essere indipendente dal sistema operativo
utilizzato sulle macchine di rete
OBL-10 Obbligatorio Il software deve supportare l’analisi di DBMS Microsoft SQL
Server
OBL-11 Obbligatorio Il software deve supportare l’analisi di DBMS PostgreSQL
OPZ-01 Opzionale Il software deve supportare l’analisi di DBMS MongoDB
OPZ-02 Opzionale Il software deve supportare l’analisi di un database distribuito
di dati salvati su DBMS differenti per il server ed il client
OPZ-03 Opzionale Il software deve implementare una procedura di database
reconciliation effettiva
Dal momento che la natura sperimentale dello stage prevede la possibilità di fallimento in caso
di determinazione di problematiche algoritmiche tali da pregiudicare l’utilizzo del software, sono
previsti i seguenti due scenari al termine dell’attività di stage:
• Lo stagista consegna un prototipo funzionante del prodotto software richiesto e la docu-
mentazione tecnica necessaria
• Lo stagista consegna una relazione tecnica volta a dimostrare l’infattibilità tecnologica
del prodotto software nei termini esplicitati nei requisiti
La valutazione finale espressa dal tutor aziendale non deve essere pregiudicata dal fallimen-
to qualora tale scenario sia stato dimostrato e documentato in modo rigoroso; al contrario, la
relazione tecnica prodotta da un tale esito è considerata valore aggiunto per l’Azienda.
2.2 Tecnologie
Data la natura intrinsecamente concorrente e distribuita del software oltre al requisito cross-
platform, il linguaggio di programmazione scelto per l’attività di codifica è stato Java, in concerto
con l’API JDBC|g| per l’interfacciamento con i diversi DBMS. Tale tecnologia permette infatti di
utilizzare un formato di codifica unificato per l’ambiente Java, senza la necessità di riadattare
il codice scritto per connettersi con la base di dati, operare query sulla base di dati e processarne
i risultati, allo specifico DBMS in utilizzo. L’API JDBC opera in modalità differenti a seconda della
tipologia di DBMS sottostante, utilizzando driver basati interamente su tecnologie Java e JDBC,
Pagina 6 di 612.3. PIANO DI LAVORO
(a) accesso tramite driver Java/ JDBC. (b) accesso tramite driver ODBC e librerie client.
Figura 2.1: Architettura dell’API JDBC
utilizzando driver ODBC oppure librerie client messe a disposizione dal database [5]; la Figura 2.1
illustra queste possibilità.
Nel nostro caso si è rivelato sufficiente scaricare dal sito dello specifico produttore del DBMS
con cui è risultato necessario interfacciarsi un apposito file di driver, da aggiungere al path delle
risorse del progetto, ed impostare correttamente nel software i parametri di connessione al database
di tale tipologia a cui connettersi.
Il prodotto è stato sviluppato su una macchina aziendale, in ambiente Windows, utilizzando Java
6 ed Eclipse|g| come piattaforme di sviluppo. La documentazione decnica del software è stata
redatta tramite l’utilizzo delle funzionalità di generazione automatica del codice sorgente messo a
disposizione dall’applicativo Javadoc, parte integrante del Java Development Kit utilizzato.
2.3 Piano di lavoro
Al fine della pianificazione delle attività di stage, è stato redatto un piano di lavoro insieme al tutor
aziendale. Il programma preventivato, distribuito su 8 settimane a tempo pieno e redatto per una
granularità settimanale, è riportato in Tabella 2.2.
Tabella 2.2: Calendario delle attività di stage
Settimana Date Ore Attività preventivate
1 4-8 Maggio 2015 40 Documentazione ed esplorazione della lettera-
tura
2 11-15 Maggio 2015 40 Primo abbozzo algoritmo, primo livello
continua
Pagina 7 di 61CAPITOLO 2. PIANIFICAZIONE
Tabella 2.2 - continua
Settimana Date Ore Attività preventivate
3 18-22 Maggio 2015 40 Raffinamento algoritmo, step ricorsivo
4 25-29 Maggio 2015 40 Test e documentazione
5 1-5 Giugno 2015 32 Ottimizzazione algoritmo
6 8-12 Giugno 2015 40 Valutazione fattibilità “a caldo”
7 15-19 Giugno 2015 40 Interfaccia utente
8 22-26 Giugno 2015 40 Test e documentazione
Lo stage, come da regolamento, ha coperto 8 settimane a tempo pieno (eccezion fatta per la festi-
vità del 2 Giugno). Il totale delle ore di lavoro risultanti preventivate è stato di 312 ore. Il diagramma
di Gantt relativo alle attività di stage è riportato in Figura 2.2. Scendendo più nel dettaglio, il piano
di lavoro originario prevedeva le seguenti attività:
• Settimana 1: durante la prima settimana verrà fornito tutto il materiale ed il supporto teorico
necessario a comprendere, affrontare e padroneggiare il problema da risolvere e lo stato
attuale dell’algoritmo concepito dall’Azienda. Verrà altresì stesa la documentazione frutto
dell’analisi
• Settimana 2: in questa settimana verrà progettata ed implementata la componente software
che si occuperà del primo livello dell’algoritmo, ovvero l’identificazione di macroblocchi dei
database che presentano differenze, al fine di determinare i dati per i quali sarà necessaria
un’analisi più approfondita allo scopo di estrarre i singoli record non sincronizzati. Saran-
no pertanto create le query per interrogare i database, verranno generati gli hash MD5 dei
dati e la tabella hash al filtro di Bloom sovraccaricato. Successivamente verrà valutato ed
implementato l’uso del filtro di Bloom invertibile allo scopo prefissato
• Settimana 3: questa settimana prevede la progettazione e l’implementazione dello step ricor-
sivo dell’algoritmo, ovvero quella che effettuerà l’analisi dei blocchi che contengono differenze,
determinati dal prototipo frutto della settimana precedente, e verrà valutato l’uso del filtro di
Bloom invertibile anche a questo scopo
• Settimana 4: settimana dedicata ai test ed alla documentazione dello stato corrente del lavoro
e del programma. Parte di questo tempo può essere impiegata come cuscinetto nel caso in
cui le precedenti lavorazioni abbiano richiesto più tempo di quanto preventivato
• Settimana 5: durante questa settimana si provvederà all’ottimizzazione dei parametri dell’al-
goritmo, quali la dimensione dei blocchi di dati più adeguata a garantire il miglior bilancia-
mento possibile tra efficienza computazionale dell’algoritmo ed il carico di rete generato per
lo scambio dei dati necessari
• Settimana 6: in questa settimana verrà valutata la fattibilità “a caldo”, ovvero si andrà a testare
l’efficienza, l’efficacia e i possibili effetti collaterali e disagi sugli utilizzatori dei database, al
fine di garantire il risultato migliore possibile nel massimo rispetto delle esigenze degli utenti,
effettuando le eventuali correzioni che si rivelino necessarie
Pagina 8 di 612.3. PIANO DI LAVORO
Figura 2.2: Diagramma di Gantt preventivo delle attività di stage
• Settimana 7: questa settimana sarà essenzialmente dedicata allo sviluppo dell’interfaccia
utente, minimale ma necessaria ad interagire col sistema e monitorare le operazioni di sincro-
nizzazione
• Settimana 8: settimana dedicata ai test ed alla documentazione finali del sistema
Le attività di stage hanno avuto, a posteriori, alcune variazioni temporali rispetto al piano di la-
voro preventivato e, soprattutto, hanno prodotto non uno, bensì tre algoritmi differenti, in quanto
l’algoritmo inizialmente fornitomi dall’Azienda non ha riscontrato necessità di implementazioni della
metodologia dei filtri di Bloom invertibili, i quali sono invece stati utilizzati per sviluppare un’imple-
mentazione dell’algoritmo di Bloom [3] ed una sua variante ottimizzata. I risultati di tali attività sono
presentati nel Capitolo 3 e Capitolo 4; gli sviluppi in termini di software e consuntivazione sono
presentati nel Capitolo 5.
Pagina 9 di 61Capitolo 3
ZSync
I NDICE
3.1 A LGORITMI SVILUPPATI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
3.1.1 IZF . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
A NALISI PROBABILISTICA DELL’ ALGORITMO IZF . . . . . . . . . . . . . . . . 14
3.1.2 IBF . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
IBF E NCODE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
IBF S UBTRACT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
IBF D ECODE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
A NALISI PROBABILISTICA DELL’ ALGORITMO IBF . . . . . . . . . . . . . . . . 20
3.1.3 IBZF . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
A NALISI PROBABILISTICA DELL’ ALGORITMO IBZF . . . . . . . . . . . . . . . 22
3.2 A RCHITETTURA DEL PROGRAMMA . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
3.2.1 D ECOMPOSIZIONE ARCHITETTURALE . . . . . . . . . . . . . . . . . . . . . 23
3.2.2 C OMPONENTE M ODEL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
3.2.3 C OMPONENTE V IEW . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
3.2.4 C OMPONENTE P RESENTER . . . . . . . . . . . . . . . . . . . . . . . . . . 26
3.2.5 PACKAGE M AIN . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
3.3 A SPETTI IMPLEMENTATIVI DEGLI ALGORITMI SVILUPPATI . . . . . . . . . . . . . . . 29
3.4 JDBC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
3.5 I NTERFACCIA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
3.6 C ONCORRENZA E DISTRIBUZIONE . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
Il presente capitolo illustra il prodotto software sviluppato durante l’attività di stage: un program-
ma client-server distribuito, in grado di analizzare le copie del database in possesso delle entità
coinvolte nel processo di sincronizzazione in termini strutturali, confrontarne i tracciati per verificare
se i dati possono essere integrati, estrarne le differenze in termini di singoli record e memorizzare
il risultato di questa analisi in file di testo locali; le informazioni contenute nei file prodotti dal pro-
gramma contengono le chiavi dei record da sincronizzare, tramite le quali sarà possibile effettuare
le necessarie modifiche ai dati delle copie del database.
Il programma non effettua alcuna sincronizzazione reale, ma si limita all’analisi sopra spe-
cificata, in quanto il proponente ha stimato il passo di sincronizzazione una mera implementazione
di codice Java/JDBC|g| direttamente derivante dal risultato del passo analitico; ciò che è stato va-
lutato di reale interesse ai fini dell’attività di stage è rappresentato dall’efficienza e dall’efficacia del
contenuto algoritmico in termini implementativi e prestazionali.
3.1 Algoritmi sviluppati
Nel corso dello svolgimento dell’esperienza di stage, al fine di analizzare i contenuti del database
e rilevarne le differenze in termini di singole tuple, sono stati sviluppati tre algoritmi. Del primo, IZF ,
Pagina 11 di 61CAPITOLO 3. ZSYNC
mi è stato illustrato l’algoritmo ideato dall’Azienda chiedendomi di svilupparne un’implementazione;
il secondo, IBF , è l’algoritmo Invertible Bloom Filter già presente in letteratura [3], implementato allo
scopo di svilupparne un terzo, IBZF , variante di IBF , che implementa una procedura di recovery
che tenta di sbloccare l’algoritmo Invertible Bloom Filter nel caso raggiunga terminazione senza
successo.
Tutti e tre gli algoritmi sono probabilistici, ovvero il loro successo non è garantito a priori, ma
dipende dai dati stessi e dalla distribuzione probabilistica del loro hash nello spazio di tutte le pos-
sibili codifiche producibili dal digest utilizzato (nei casi in esame, la codifica MD5|g| ). Un’analisi
probabilistica dei singoli algoritmi è disponibile nelle relative sezioni.
3.1.1 IZF
Il primo algoritmo, IZF (Invertible Zucchetti Filter), è un algoritmo probabilistico e ricorsivo
che confronta i dati delle singole tuple di una tabella, codificate tramite hash MD5, tramite l’ausilio
di strutture dati probabilistiche appositamente concepite: le IZLT (Invertible Zucchetti Lookup
Table). Una IZLT è una struttura dati tabellare con le seguenti caratteristiche:
• Una IZLT ha un numero di entry pari a 256 (28 ) o 65536 (216 ), in base al numero di tuple che
deve indicizzare, quantità nota a priori. Il limite per la scelta automatica della dimensione di
una IZLT di 65536 entry è stato fissato a 215 , e garantisce che le singole entry della IZLT non
saranno troppo sature di dati, condizione che potrebbe aumentare la probabilità di situazioni
eccezionali, come sarà più chiaro nel seguito.
• Ogni riga della tabella possiede tre campi:
– id: campo String che contiene il primo byte della codifica MD5 dei dati nel caso di
tabelle da 256 entry , altrimenti i primi 2 byte nel caso di tabelle da 65536 entry al primo
passo dell’algoritmo, incrementando via via che si procede con la ricorsione
– data: campo byte[] che contiene i dati delle tuple indicizzate dalla corrispondente id,
ovvero quelle la cui codifica MD5 inizia con i byte del corrispondente campo id, collassati
nella stessa entry tramite operazioni di XOR byte a byte
– counter: campo int che rappresenta il numero di hash contenuti in una singola entry
nel campo data
• Come conseguenza della struttura di una IZLT , la sua dimensione è fissa e dipende dal nu-
mero di entry, dalla dimensione in byte della codifica hash utilizzata e dal numero di byte
utilizzati dal campo id per indicizzare gli hash.
La struttura dati IZLT risiede nel package model.share (vedi sottosezione 3.2.2) ed è riportata
in Figura 3.1.
Si può notare come sia un sottotipo di Serializable, in quanto è il principale oggetto di in-
terscambio server/client nel corso dell’esecuzione dell’algoritmo. Inoltre, il campo data è concet-
tuale: le informazioni vengono inserite in una matrice di byte, table, e le singole entry ven-
gono estratte dalla matrice, determinata automaticamente in costruzione dal numero di elementi
della tabella e dalla dimensione in byte dell’hash utilizzato (nel nostro caso l’MD5; tuttavia l’im-
plementazione è stata ideata in questo modo per facilitare l’estendibilità del codice). Il campo dati
checksum rappresenta la dimensione dell’indice corrente (1 o 2 byte, determinato dalla dimensione
della tabella).
Sono inoltre presenti i seguenti metodi:
Pagina 12 di 613.1. ALGORITMI SVILUPPATI
Figura 3.1: Diagramma delle classi, classe model.share.IZLT
• Vari metodi get per le informazioni rilevanti della IZLT
• addRecordHash() ed il metodo ausiliario addTableEntry(): metodi utilizzati per inse-
rire i dati in tabella
• getTableDifferences(): metodo di confronto tra due IZLT , crea una tabella differenza
tra le IZLT server/client allo scopo dell’elaborazione algoritmica
Utilizzando le strutture dati sopra citate, l’algoritmo procede attraverso i seguenti passi:
1. Il server codifica i dati della tabella in esame e crea la relativa IZLT ; riceve dal client la
corrispondente IZLT relativa ai dati della tabella in suo possesso
2. Il server crea una IZLT differenza: per ciascuna entry delle due tabelle effettua lo XOR
dei campi data della IZLT server e client, elidendo i dati comuni ad entrambe le IZLT ;
contestualmente effettua la differenza del campo counter delle due tabelle
3. A questo punto si verifica uno ed uno solo dei seguenti casi sulla IZLT differenza:
• I campi data e counter sono stati azzerati entrambi. I dati indicizzati nella entry
corrente sono tutti in comune; pertanto l’analisi sulla entry corrente si arresta
• Il campo data è stato azzerato ma non il campo counter. Si è verificata un’anomalia in
elisione dei dati; il contatore viene reimpostato per proseguire ugualmente nell’ispezione
(passo ricorsivo)
• Il campo counter presenta un valore di -1. Il valore del campo data potrebbe rappre-
sentare l’hash di una tupla presente solo sul client: per accertarlo, si verifica l’effettiva
esistenza del dato nel file hash del client, generato come illustrato in sezione 3.4. Se
il dato esiste, si richiede al client un controllo volto a verificare che il dato non sia stato
cancellato (ciò è possibile dalla seconda esecuzione in poi dell’algoritmo, utilizzando un
Pagina 13 di 61CAPITOLO 3. ZSYNC
apposito file contenente lo storico del contenuto della tabella in analisi per la precedente
esecuzione, codificato nella maniera usuale): qualora questa condizione non si verifichi,
si informa il client della necessità di inviare il dato differenza al server , registrando la riga
corrispondente del file hash (ove è registrata anche la chiave primaria del dato, neces-
saria per la reperibilità) in un apposito file delle differenze nel medesimo path; altrimenti,
il server registra, in modo analogo, la necessità di cancellare il dato dalla propria copia
locale. Se il dato è inesistente, invece, si è verificata un’anomalia in elisione dei dati; il
contatore viene reimpostato per proseguire ugualmente nell’ispezione (passo ricorsivo)
• Il campo counter presenta un valore di +1. Il valore del campo data potrebbe rappre-
sentare l’hash di una tupla presente solo sul server . Si procede analogamente al caso
precedente, a ruoli invertiti, eventualmente proseguendo con il passo ricorsivo
• Il campo counter presenta un valore differente dai precedenti. In questo caso occorre
necessariamente effettuare un passo ricorsivo
4. Qualora per la entry corrente sia necessario un passo ricorsivo, si riparte dal principio, rigene-
rando nuove IZLT indicizzanti i dati ad un livello più approfondito, utilizzando come campo id
la vecchia condizione concatenata ai nuovi byte necessari per approfondire l’analisi sui dati
indicizzati nella entry in analisi, numero variabile in base alla quantità di dati presente nelle
due entry precedentemente analizzate e reperibile dal valore del campo counter al passo
appena conclusosi. Il passo ricorsivo più profondo si verifica nell’analisi di tabelle indicizzate
dall’intera codifica hash, quindi singole codifiche. Pertanto il corrispondente ramo dell’albero
di ricorsione è terminato
5. Quando tutti i passi ricorsivi sono terminati, ovvero quando l’algoritmo ha espolorato tutto
l’albero di ricorsione determinatosi, una sola delle seguenti due condizioni si è verificata:
• Tutte le differenze sono state individuate e trattate con successo
• Si sono verificate anomalie di elisione dei dati nelle foglie, pertanto non è possibile prose-
guire in ricorsione: l’algoritmo genera risultati inconsistenti
I due casi dipendono dalla peculiare distribuzione dei dati in tabella e dalle proprietà delle
funzioni hash, e sono strettamente correlati alla natura probabilistica dell’algoritmo.
Analisi probabilistica dell’algoritmo IZF
La problematica inerente al fallimento dell’analisi svolta sui dati dall’algoritmo IZF risiede essen-
zialmente nel paradosso del compleanno il quale, nella sua forma più famosa ed intuitiva, afferma
che il numero di persone in una stanza necessarie per avere una probabilità superiore al 50% che
almeno due di esse siano nate lo stesso giorno dell’anno è estremamente più basso di quanto ci si
aspetti: bastano infatti 23 persone per soddisfare tale condizione probabilistica. Questo parados-
so può essere applicato ai più svariati ambiti e riveste un ruolo importante in campo informatico,
in particolar modo nella valutazione delle collisioni di funzioni hash, il quale è proprio il caso di
interesse.
Ciò che interessa ai fini teorici dell’algoritmo è determinare un limite superiore al numero dei dati
codificabili entro il quale la probabilità di collisione della funzione hash utilizzata per la codifica dei
dati stia al di sotto di una soglia prefissata. In questo senso, la formula generale illustra che n(p; d),
ovvero il numero di interi casuali ricavati da una distribuzione di probabilità discreta uniforme di
Pagina 14 di 613.1. ALGORITMI SVILUPPATI
intervallo [1; d] necessario per ottenere una probabilità p che almeno due numeri siano uguali, si
può ricavare come
v !
u
u 1
n(p; d) ≈ t2d · ln (3.1)
1−p
L’analisi in questi termini è applicabile alle funzioni hash.
L’Azienda ha fatto esplicita richiesta che tale probabilità sia dell’ordine del rateo di errori incor-
reggibili di un hard disk , ovvero dell’ordine di grandezza di 10-15 , e di valutare la quantità di record
trattabili in questo senso utilizzando la codifica MD5. Pertanto, l’ Equazione 3.1 diventa:
v !
u
−15
u 1
n(10 ; d) ≈ t2d · ln
1 − 10−15
Effettuando semplici passaggi algebrici, si ottiene la seguente formula:
v !
u
−15
u 1015
n(10 ; d) ≈ t2d · ln (3.2)
1015 − 1
ove d rappresenta il numero di bit utilizzati dalla codifica hash. Dall’ Equazione 3.2 si ricava che,
per la codifica MD5, d ≈ 8.25 · 1011 , ovvero che la probabilità di collisione di due hash in questa
codifica rientra nell’ordine di grandezza desiderato di 10-15 fino alla generazione di circa 825 miliardi
di hash differenti, risultato giudicato soddisfacente dall’Azienda.
È opportuno segnalare che il parametro d non appare costante nel corso dell’esecuzione: difatti,
mano a mano che ci si addentra nella ricorsione e/o si utilizzino IZLT di dimensione differente,
il parametro d sembra ridursi di un fattore di almeno 28 , ovvero di uno o più byte in base alla
dimensione della tabella; conseguentemente, il numero di hash necessari per raggiungere la soglia
sembra diminuire. La Tabella 3.1 rappresenta i valori di n(10−15 ; d) al variare di d.
d n(10−15 ; d)
2128 8, 25 · 1011
2120 5, 16 · 1010
2112 3, 22 · 109
2104 2, 01 · 108
296 1, 26 · 107
288 7, 87 · 105
280 49172
272 3074
264 193
256 13
248 2
Tabella 3.1: Valori di n(10−15 ; d) al variare di d
Pagina 15 di 61CAPITOLO 3. ZSYNC
La diminuzione di un ordine di grandezza circa del numero di hash richiesti per avere una collisio-
ne con probabilità richiesta ad ogni byte in più utilizzato per indicizzare potrebbe allarmare; tuttavia
occorre sottolineare che nessun dato viene modificato nel corso dell’esecuzione dell’algoritmo: in
altre parole, la probabilità di collisione non cambia in quanto i dati vengono indicizzati attraverso
il loro hash, per cui un passo ricorsivo equivale ad uno zoom all’interno dei dati aggregati anco-
ra indeterminati: un’eventuale anomalia esisterà già all’inizio dell’algoritmo, e la sua probabilità è
determinata univocamente dal tipo di codifica utilizzata per l’hashing dei dati.
3.1.2 IBF
Il secondo algoritmo, IBF (Invertible Bloom Filter), descritto in [3], è un algoritmo probabilistico
e iterativo che confronta i dati delle singole tuple di una tabella, codificate nel caso di interesse
tramite hash MD5, tramite l’ausilio di omonime strutture dati probabilistiche di supporto. Nel nostro
caso, in conformità con quanto fatto per il primo algoritmo e in altri lavori [6, 7], e dato che tali struttu-
re sono utilizzate anche dalla variante aziendale IBZF , sono state qui denominate IBLT (Invertible
Bloom Lookup Table). Una IBLT , nell’implementazione effettuata, è una struttura dati tabellare
con le seguenti caratteristiche:
• Una IBLT ha dimensione fissa (nell’implementazione effettuata, 216 entry ), rappresentante
l’universo delle chiavi di una funzione hash ausiliaria utilizzata per mappare i dati codificati in
MD5 nelle relative entry
• Ogni entry di una IBLT dispone dei seguenti campi:
– idSum: campo dati byte[] in cui vengono accorpati i dati tramite operazioni di XOR,
come nell’algoritmo precedente
– hashSum: campo dati long contenente un checksum del corrispondente campo idSum
per verificare la “purezza” dei dati in esso contenuto: il campo idSum di un dato puro
(cioè esistente) produrrà un checksum equivalente a quello registrato nel relativo campo
hashSum. In questo modo sarà facile verificare se un determinato idSum rappresenta o
meno un dato singolo o un’aggregazione di dati ottenuta tramite XOR: in quest’ultimo caso,
il checksum generato non corrisponderebbe a quello effettivamente registrato nella entry
– count: campo dati int contenente un contatore del numero di elementi indicizzati nel
corrispondente campo idSum
L’implementazione della IBLT risiede nel package model.share (vedi sottosezione 3.2.2) ; la
sua struttura è rappresentata in Figura 3.2.
Le singole entry della tabella sono incapsulate nella sottoclasse IBLTEntry, che dispone dei
campi dati sopra citati, oltre a metodi per determinare se una entry è pura; sono inoltre disponibili
metodi statici per determinare se una entry corrisponde ad un’altra in un’altra tabella, è vuota o se
la differenza tra due entry di due tabelle rappresenta un dato puro lato server : ciò è utile ai fini
dell’algoritmo derivato IBZF , facente uso delle medesime strutture dati (vedi sottosezione 3.1.3). Il
metodo update() è utilizzato dalle procedure IBF Encode ed IBF Decode per manipolare i dati
(vedi seguito).
Il costruttore della IBLT prevede un parametro contenente la lunghezza in byte dell’hash utilizzato
per codificare i dati, per la stessa ragione illustrata in merito alle IZLT . sono altresì disponibili i
seguenti metodi:
• hash(): metodo utilizzato per creare un hash dei dati codificati passati come parametro
Pagina 16 di 613.1. ALGORITMI SVILUPPATI
Figura 3.2: Diagramma delle classi, classe model.share.IBLT
• hashSum(): metodo utilizzato per creare il checksum di un dato; fa utilizzo interno del
precedente metodo hash()
• hashToDistinctIndices(): metodo utilizzato per determinare le celle della IBLT in cui
inserire in modo ridondante/recuperare il dato corrente. Anch’esso fa uso del metodo hash
per la determinazione degli indici in fase di codifica/decodifica (vedi le procedure nel seguito)
• addRecordHash(), removeRecordHash() e l’ausiliario processTableEntry(): me-
todi utilizzati per inserire/rimuovere un dato dalle corrispondenti celle determinate tramite il
metodo hashToDistinctIndices()
• sameEntry(), emptyEntry(), pureEntry(): metodi statici utilizzati dall’algoritmo de-
rivato IBZF per determinare se una entry corrisponde ad un’altra, è vuota o se la differen-
za tra due entry rappresenta un dato puro lato server , richiamanti gli omonimi metodi della
sottoclasse IBLTEntry (vedi sottosezione 3.1.3)
Pagina 17 di 61CAPITOLO 3. ZSYNC
• pureEntry(), pureRecord(), buildPureList(): metodi che, rispettivamente, con-
trollano la purezza di una entry , estraggono un dato puro, costruiscono la lista delle celle pure
della tabella, utilizzate dall’algoritmo IBF standard
• update(): metodo che aggiorna le entry da cui estrarre un dato puro e la lista delle entry
pure nell’esecuzione dell’algoritmo
• getDifferential(): metodo che costruisce la IBLT differenza tra i dati server/client,
utilizzata dalla procedura IBF Subtract (vedi seguito)
• count(): metodo che ritorna il numero di elementi inseriti nella cella indicata dal parametro
passato
• isEmpty(): metodo che verifica la condizione di arresto dell’algoritmo (IBLT vuota)
Occorre notare come la IBLT e la sua sottoclasse siano entrambi sottotipi di Serializable per
le medesime ragioni illustrate in merito alle IZLT .
L’algoritmo IBF è composto da tre distinte procedure, seguendo lo schema proposto in [3]: IBF
Encode, relativa alla codifica dei dati nelle IBLT ; IBF Subtract, relativa alla creazione della IBLT
differenza tra le tabelle server e client; IBF Decode, relativa alla decodifica dei dati contenuti nelle
IBLT. Vediamo più nel dettaglio queste procedure.
IBF Encode
La procedura di codifica dell’algoritmo IBF utilizza k funzioni hash indipendenti per calcolare un
numero di entries predefinito (nella nostra implementazione, 4) in cui inserire ogni dato in modo
ridondante (gli hash MD5). Pertanto occorre determinare una metodologia di hashing da utilizza-
re per l’inserimento dei dati. Dal momento che possiamo vedere un hash MD5 come un vettore
a lunghezza fissa (128 bit) di parole macchina, si è scelto di far ricorso ad una tecnica di Tabula-
tion Hashing|g| , ove i valori numerici della matrice utilizzata per simulare le funzioni hash casuali è
stata creata utilizzando la metodologia Xorshift [8]. Occorre sottolineare che questa tecnica, mol-
to veloce in termini computazionali, potrebbe causare problemi, dal momento che le funzioni hash
generate tramite Tabulation Hashing non sono 4-indipendenti; tuttavia, si evita una erronea mappa-
tura di uno stesso dato più volte nella medesima entry tramite un apposito controllo nel metodo di
generazione degli indici (problematica che potrebbe comportare severe anomalie di funzionamento
dell’algoritmo). Tramite questa tecnica vengono generati gli indici della IBLT in cui inserire i dati.
In Figura 3.3 è rappresentato il processo, ove S rappresenta l’insieme dei dati da inserire in tabella.
Per ogni entry determinata dall’algoritmo, viene effettuato lo XOR del dato con il precedente
contenuto del campo idSum, calcolato il checksum ed aggiunto al campo hashSum con la mede-
sima tecnica; infine viene incrementato il contatore del campo count. La procedura viene effet-
tuata su ogni hash MD5 contenuto nel file relativo alle tuple della tabella in analisi. Quando tutti
i dati sono stati inseriti, la procedura termina. Questo passo è effettuato sia dal server sia dal
client; ad esecuzione terminata, il client provvederà ad inviare al server la propria IBLT per il passo
successivo.
IBF Subtract
La procedura di differenziale dell’algoritmo IBF , svolta dal server , crea una IBLT differenza date le
IBLT lato server e lato client. Per ogni entry della tabella vengono effettuate le seguenti operazioni:
• Viene effettuato lo XOR dei corrispondenti campi idSum
Pagina 18 di 613.1. ALGORITMI SVILUPPATI
Figura 3.3: Procedura IBF Encode
• Viene effettuato lo XOR dei corrispondenti campi hashSum
• Viene effettuata la differenza dei corrispondenti campi count
In Figura 3.4 è riportata la sequenza di operazioni effettuate dalla procedura per la creazione della
IBLT differenza.
Al termine della procedura, grazie alle proprietà dell’operatore XOR, tutti gli elementi comuni alle
due tabelle saranno stati elisi. A questo punto si può procedere con il passo di decodifica.
IBF Decode
La procedura di decodifica dell’algoritmo IBF , svolta dal server , opera nel seguente modo: in-
nanzitutto viene costruita una lista contenente gli indici di tutte le celle pure. Una cella pura è una
entry in cui il valore del campo count è pari ad 1 o -1 a seconda che il dato sia di origine server
oppure client, e in cui il computo del checksum del campo idSum produce il medesimo valore con-
tenuto nel campo hashSum. Una volta completata la lista, si procede a memorizzare il dato da
estrarre nell’output corrispondente (server o client, effettuando i relativi controlli per memorizzare il
record come nuovo o cancellato dal lato remoto tramite i medesimi file degli storici/nuovi/cancellati
utilizzati per l’algoritmo IZF ), rimuovere questo dato dalle celle in cui risulta mappato utilizzando la
medesima tecnica utilizzata in fase di inserimento, avendo cura di decrementare il contatore anziché
incrementarlo. Contestualmente si scansionano le entries modificate alla ricerca di eventuali nuove
celle pure e si aggiorna la relativa lista. In Figura 3.5 è illustrato il procedimento di decodifica.
Il processo termina quando la lista delle celle pure è vuota, ed a questo punto si verifica una sola
delle seguenti due condizioni di arresto:
• La IBLT differenza è stata svuotata completamente, ovvero l’algoritmo ha recuperato con
successo tutti i dati, ricavando le eventuali differenze
• La IBLT differenza non è stata svuotata completamente, pertanto l’algoritmo non è riuscito a
completare il recupero dei dati codificati, fallendo
Le probabilità di successo/fallimento dell’algoritmo sono influenzate da svariati fattori. Vediamo
più in dettaglio questi aspetti.
Pagina 19 di 61CAPITOLO 3. ZSYNC
Figura 3.4: Procedura IBF Subtract
Analisi probabilistica dell’algoritmo IBF
IBF è un algoritmo probabilistico, e le probabilità di successo o di fallimento sono legate alle
seguenti caratteristiche:
• Dimensione delle IBLT
• Quantità di dati da codificare/decodificare
• Numero di differenze tra i due insiemi di dati server/client
• Tipo di codifica utilizzato per i dati
Per quanto concerne i primi tre punti, è intuitivo comprendere che quanto più i dati da inserire
siano numerosi, differenti tra loro, e/o quanto più limitate siano le dimensioni della IBLT , tanto più
difficile sarà trovare celle pure sia all’inizio della procedura di decodifica sia nel corso delle operazio-
ni di rimozione. In letteratura [3] è illustrato come, data d la cardinalità dell’insieme delle differenze
tra i record provenienti da server e client, siano necessarie approssimativamente 1, 5d celle in una
IBLT per garantire la corretta decodifica dei dati immessi. Pertanto, la dimensione della IBLT an-
drebbe calcolata con una tecnica che consenta di valutare la quantità d prima di iniziare l’esecuzione
dell’algoritmo vero e proprio. [3] propone una tecnica denominata Strata Estimator , sulla quale non
ci soffermeremo in quanto l’Azienda ha dato disposizioni di non procedere in tal senso, in quanto
il vero scopo dell’implementazione dell’algoritmo IBF in questa sede è quello di essere utilizzato
come parte del terzo algoritmo, sua variante.
Pagina 20 di 613.1. ALGORITMI SVILUPPATI
Figura 3.5: Procedura IBF Decode
In merito all’ultimo punto, le considerazioni probabilistiche in merito alla codifica MD5 per l’algo-
ritmo IZF continuano a valere, poiché le alterazioni svolte dal processo di decodifica si limitano a
rimuovere dati noti. Pertanto, eventuali collisioni in fase di codifica dei dati nei relativi file hash sono
determinate univocamente dalle caratteristiche di detta codifica.
3.1.3 IBZF
Il terzo ed ultimo algoritmo, IBZF (Invertible Bloom Zucchetti Filter) è un algoritmo probabi-
listico e ricorsivo, variante dell’algoritmo Invertible Bloom Filter che comprende una procedura,
denominata di peeling, volta a correggere la problematica del fallimento in decodifica dell’algoritmo
IBF standard. L’algoritmo, nella sua prima fase, semplicemente richiama l’algoritmo standard e ne
controlla lo stato di terminazione. Qualora questo passo abbia avuto successo, l’algoritmo termina,
riducendosi ad un normale algoritmo IBF . Altrimenti viene lanciata la procedura di peeling, la quale
opera nel modo seguente:
1. Innanzitutto vengono ricostruite le IBLT server e client
2. Viene scansionato il file hash del server (non quello del client in quanto verrebbe genera-
ta una mole inaccettabile di traffico di rete) e vengono ricavate le celle della IBLT in cui i
corrispondenti dati sono stati mappati in entrambe le IBLT , in quanto la tecnica di hashing
utilizzata genera gli stessi indici in entrambe le IBLT per dati equivalenti. Per ogni coppia di
entry server/client vengono verificate le seguenti condizioni:
• Se tutti i campi dati delle due entry sono identici, tutti i record ivi indicizzati sono equivalenti.
Pertanto si può procedere alla rimozione di questo dato dalle IBLT tramite una codifica
inversa come in IBF Decode, in quanto il relativo record è presente da entrambi i lati server
e client
• Se la condizione precedente non si verifica la la relativa entry della IBLT client è vuota,
possiamo concludere che tutti i record lato server indicizzati nella relativa entry lato server
appartengono solo al server . Pertanto si si verifica la coerenza del dato estratto con i dati nei
Pagina 21 di 61Puoi anche leggere
