Esperimenti

In questa sezione presentiamo i risultati preliminari degli esperimenti effettuati con un’implementazione prototipale del nostro approccio. Abbiamo condotto gli esperimenti su dati provenienti da contesti reali ed abbiamo testato alcuni programmi logici presenti nel benchmark OpenRuleBench [135].

Abbiamo confrontato il nostro approccio con due ben noti DBMS che con- sentono di gestire ed effettuare interrogazioni su dati distribuiti, ovvero Oracle e SQLServer. Dal momento che siamo interessati a confrontare le prestazioni del nostro approccio con DBMS commerciali, abbiamo valutato i programmi con il nostro sistema ed il corrispondente insieme di query SQL con il DBMS.

SQLServer consente di interrogare i dati distribuiti attraverso linked server, mentre Oracle mette a disposizione database link. Nel nostro approccio DLVDB

`

e stato accoppiato sia con SQLServer che con Oracle.

Gli esperimenti sono stati eseguiti su un sistema operativo Windows 2003 Server installato su rack HP ProLiant DL120 G6 dotato di processore Intel Xeon X3430, 2.4 GHz, con 4 GB di RAM. Abbiamo impostato un limite di tempo di 120 minuti dopo i quali l’esecuzione dell’interrogazione `e stata arrestata. Per ciascun test, abbiamo calcolato la media dei risultati di tre esecuzioni consecu- tive dopo la prima (che non `e stata considerata al fine di escludere eventuali ottimizzazioni dei DBMS, come la memorizzazione nella cache). Nei grafici (vedi

6.1. DATA INTEGRATION 103

P1:

exam record(X1,X2,Z,W,X4,X5,Y) :- dati esami(X1,A1,X2,X5,X4,A2,Y), affidamenti ing informatica(X2,X3,Y), dati professori(X3,Z,W). course(X1,X2) :- esame(A1,X1,X2,A2).

active courses(CD):-course(C,CD), exam record(X0,C,X1,X2,X3,X4). P2:

student(X1,X2,X3,X4,X5,X6,X7) :-

studenteS1(X1,X3,X2,A1,A2,A3,A4,A5,A6,A7,A8,A9,X6,X5,A10,A11, X4,A12,A13,A14,A15,Y,A16), diploma maturitaS1(Y,X7).

exams(X1,X2) :- dati esami(X1,A1,X2,X5,X4,A2,Y).

hasCommon(X1,X3) :- student(X1,X2,X3,X4,X5,X6,X7), exams(X1,C), student(Y1,Y2,Y3,Y4,Y5,Y6,X7), exams(Y1,C).

P3:

teaching(X1,Z,W,X3) :- affidamenti ing informatica(X1,X2,X3), dati professori(X2,Z,W).

exam record(X1,X2,Z,W,X4,X5,Y) :- dati esami(X1,A1,X2,X5,X4,A2,Y), affidamenti ing informatica(X2,X3,Y), dati professori(X3,Z,W). course(X1,X2) :- esame(A1,X1,X2,A2).

student(X1,X2,X3,X4,X5,X6,X7) :-

studenteS1(X1,X3,X2,A1,A2,A3,A4,A5,A6,A7,A8,A9,X6,X5,A10,A11, X4,A12,A13,A14,A15,Y,A16), diploma maturitaS1(Y,X7).

commonProf(M1,CCODE1,M2,CCODE2):- student(M1,A2,A3,A4,A5,A6,A7), exam record(M1,CCODE1,B3,B4,B5,B6,B7), course(CCODE1,E2), exam record(M2,CCODE2,C3,C4,C5,C6,C7), course(CCODE2,F3), student(M2,D2,D3,D4,D5,D6,D7),

teaching(CCODE1,PFN,PLN,G4), teaching(CCODE2,PFN,PLN,H5).

Tabella 6.1: Test su programmi logici.

figura 6.1), riportiamo i tempi di esecuzione diDLVDB associato ad SQLServer (D+S), SQLServer (S),DLVDB associato ad Oracle (D+O), e Oracle (O).

Test su dati provenienti dal mondo reale. Abbiamo utilizzato il framework di integrazione dati sviluppato nell’ambito del progetto Infomix (IST-2001-33570) [56], che integra i dati di un reale contesto universitario. In particolare, so- no stati considerati i dati resi disponibili dall’Universit`a degli Studi di Roma “La Sapienza”. Questi comprendono informazioni su studenti, professori, pro- grammi di studio ed esami in diverse facolt`a dell’universit`a. Nello scenario applicativo sono presenti circa 35 sorgenti, mappate in 12 schemi globali con circa 20 mapping GAV. Nel seguito definiremo Infomix questo insieme di dati. Inoltre, abbiamo considerato due ulteriori insiemi di dati, vale a dire Infomix- x-10 e Infomix-x-50, in cui sono memorizzate, rispettivamente, 10 copie (per un totale di 160 MB di dati) e 50 copie (800Mb) del database originale.

Definiamo Infomix⊂Infomix-x-10⊂Infomix-x-50. Abbiamo poi distri- buito i set di dati Infomix su 5 siti ed abbiamo confrontato i tempi di esecu- zione del nostro prototipo con i due DBMS. I programmi che abbiamo testato sono riportati in tabella 6.1.

L’output del programma P1 `e active courses, e definisce le descrizioni dei corsi per i quali esiste almeno un esame. Il programma P2 ha l’obiettivo di trovare studenti aventi lo stesso diploma ed almeno un esame comune; qui il predicato di output `e hasCommon. Il programma P3 identifica gli studenti che hanno avuto un professore comune, quindi il focus `e su commonProf. Si noti che questi tre programmi sono stati sottoposti ad unfolding rispetto ai predicati di output e le corrispondenti regole sono state riscritte come query SQL per essere eseguite da Oracle e da SQLServer. I risultati dei nostri esperimenti sono presentati in Figura 6.1.

0 200 400 600 800 1000 1200 1400 1600

Infomix Infomix_10 Infomix_50

Average Execution Time (s)

Program P1 D+S S D+O O 0 1000 2000 3000 4000 5000 6000 7000 8000

Infomix Infomix_10 Infomix_50

Average Execution Time (s)

Program P2 Timeout (2h) D+S S D+O O 0 1000 2000 3000 4000 5000 6000 7000 8000

Infomix Infomix_10 Infomix_50

Average Execution Time (s)

Program P3 Timeout (2h) D+S S D+O O 1000 2000 3000 4000 5000 6000 7000 8000

test_10 test_50 test_250

Average Execution Time (s)

Openrulebench - Join1 Timeout (2h) D+S S D+O O

Figura 6.1: Risultati dei test su programmi logici.

senta di ottenere significativi miglioramenti delle prestazioni. Infatti, mentre per dataset di non elevate dimensioni migliora l’esecuzione di pochi secondi (P1) o centinaia di secondi (P2 e P3), consente di ottenere prestazioni significativa- mente superiori nel caso di dataset molto grandi (i DBMS superano il timeout sia con P2 che con P3 gi`a per Infomix-x-10. Inoltre, quando i DBMS non superano il timeout, D+S permette di ottenere un guadagno fino al 99% rispetto a S e D+O fino al 80% rispetto ad O.

Test da OpenRuleBench. In [135] `e stato presentato un benchmark per testare sistemi rule based. Anche se non `e stato progettato per testare i programmi su dati distribuiti, sosteniamo che potrebbe essere interessante adattare alcuni di questi programmi al nostro contesto.

Abbiamo concentrato l’attenzione sul programma chiamato join1 in [135] che `e costituito dalle seguenti regole:

a(X, Y) :- b1(X, Z), b2(Z, Y). b1(X, Y) :- c1(X, Z), c2(Z, Y). b2(X, Y) :- c3(X, Z), c4(Z, Y). c1(X, Y) :- d1(X, Z), d2(Z, Y).

dove a `e il predicato di output.

Le relazioni di base c2,c3,c4,d1 e d2 sono state generate in modo random in [135] in tre insiemi di dati di dimensione crescente aventi, rispettivamente, 10000 (test 10), 50000 (test 50) e 250000 (test 250) tuple per ogni relazione, che abbiamo distribuito in tre siti. I risultati per i tre data set sono mostrati in figura 6.1; in questo caso, la scalabilit`a di D+S `e straordinaria rispetto agli altri sistemi, mentre `e parso abbastanza sorprendente il comportamento di D+O. Abbiamo, pertanto, ulteriormente investigato questo aspetto rilevando che: (i) il tempo necessario per il trasferimento dei dati tra i database links in Oracle `

e doppio rispetto a quello richieste dai linked server in SQLServer; (ii) mentre D+Oha richiesto quasi 2 ore per test 50, O non ha terminato il test in 5 ore; (iii) abbiamo anche provato ad eseguire sia D+O che O su una singola macchina, ma abbiamo interrotto dopo 3 ore. Quindi, abbiamo dovuto concludere che questo test risulta particolarmente problematico per Oracle, indipendentemente dalla nostra ottimizzazione.