La presentazione è in caricamento. Aspetta per favore

La presentazione è in caricamento. Aspetta per favore

Benchmark Riccardo Cinus 2790600 Lorena Shestani 3665720.

Presentazioni simili


Presentazione sul tema: "Benchmark Riccardo Cinus 2790600 Lorena Shestani 3665720."— Transcript della presentazione:

1 Benchmark Riccardo Cinus Lorena Shestani

2 Benchmark Una procedura di test standard utilizzata per valutare le prestazioni di un qualsiasi dispositivo

3 Definizione Benchmarking: banco di prova, test effettuato quando si confrontano due programmi progettati per svolgere la stessa serie di compiti o due elaboratori per valutarne le prestazioni. Il test è anche un controllo della macchina rispetto alle prestazioni dichiarate dal costruttore.

4 Problematiche relative ai benchmark Trovare un modo appropriato di valutazione di un programma o di un apparecchio hardware

5 Le specificazioni di benchmark Sono stati sviluppati vari benchmark con regole specifiche perché nessuna singola metrica può misurare la performance dei sistemi dei computer per tutte le applicazioni. Il Benchmark Handbook ha applicato questi quattro criteri chiave per un benchmark con regole specifiche:

6 Relevance: Il Benchmark deve catturare le caratteristiche del sistema per essere misurato. Portability: Il Benchmark deve essere capace di essere implementato su diversi sistemi.

7 Scalability: Il Benchmark deve essere capace di testare vari database su diversi sistemi di computer. Simplicity: Il Benchmark deve essere significativo; diversamente non sarà credibile.

8 Un benchmark è usato per testare la massima performance di un sistema. Diversi aspetti di un sistema hanno varie importanze a seconda dei diversi domini. Ci sono tanti benchmark ed ogniuno di essi può avere regole specifiche.

9 Alcuni benchmark: Wisconsin benchmark Il Wisconsin benchmark si usa per testare la performance dei sistemi dei query relazionali con semplici operatori relazionali

10 Alcuni benchmark: Il AS3AP Il AS3AP benchmark provvede ad una valutazione più completa dei sistemi di database relazionali incorporando delle caratteristiche come: testare funzioni utili, mucchio misto, query interattive e test multiutenti

11 Altri Benchmark Il Set Query benchmark valuta labilità dei sistemi per procedere query complessi Lo OO7 si usa per i database object- oriented BUCKY per i database object-relational TCP-W benchmark per l e- commerce. Questo è il Benchmark più recente

12 Benchmark e XML Il disegno di un benchmark per valutare XML management systems è un nontrivial task. Lobbiettivo del benchmark è di focalizzare gli aspetti del query-processing di XML.

13 Benchmark e XML Gli strumenti del query-processing XML sono valutati nel modo più semplice possibile; infatti, vengono usati dati locali per la valutazione, e questa viene effettuata su una singola macchina.

14 Benchmark Data Set La struttura del data set di un apposito benchmark deve essere abbastanza complesso per catturare tutte le caratteristiche di una rappresentazione dati di XML.

15 Benchmark Data Set XML prevede a una ordinazione implicita dei suoi elementi. Prevede inoltre anche a referenze, deep nesting, hyperlink. La base di dati del benchmark deve, inoltre catturare anche le caratteristiche del documento (es. lordine implicito degli elementi) e della navigazione (le referenze)

16 Benchmark Data Set Le scalability di un sistema possono essere misurate usando data set di vari misure. Siccome XML si può rappresentare come un albero, questo si può archiviare come segue:

17 Benchmark Data Set La profondità del albero si può controllare variando il numero delle ripetizioni degli elementi ricorsivi. Lampiezza del albero si può aggiustare col variare del cardinalità di alcuni elementi

18 Benchmark Queries In XML, la performance dei linguaggi query dipendono soprattutto dalla funzionalità che loro provedono di fare e dalla potenza delle espressioni.

19 Benchmark Queries Il consorzio W3C XML Query Language Working Group hanno pubblicato una lista di requisiti atti a soddisfare le prestazioni delle query. Questa lista è composta da 21 regole che sono diventate il punto di riferimento nella valutazione delle prestazioni di query. Questi requisiti stabiliscono le capacità di valutazione relative a: dati, documenti, e navigazione.

20 Le regole Permette i processi di query su tutti i tipi di dati e colleziona i possibili documenti XML multipli (R1) Permette i data-oriented, document- oriented, e le query miste (R2) Accetta i dati in streaming (R3)

21 Le regole Supporta le operazioni su vari modelli di dati (R4) Permette condizioni su elementi del testo (R5) Supporta query sequenziali e gerarchiche (R6)

22 Le regole Manipola i valori null (R7) Supporta i quantificatori nelle query (R8) Permette alle query di combinare parti di piu documenti (R9)

23 Le regole Supporta per laggregazione (R10) Capacità di generare risultati con tipo (R11) Supporta la composizione di operazioni (R12)

24 Le regole Permette la navigazione (R13) E capace di usare le informazioni dellambiente come parti delle query (R14) Capace di supportare aggiornamenti XML se il modello dei dati lo permette (R15)

25 Le regole Supporta tipi di coercizione (R16) Preserva la struttura dei documenti (R17) Trasforma e crea le strutture XML (R18)

26 Le regole Supporta la creazione degli ID (R19) Ricorrenza strutturale (R20) Ordinamento degli elementi (R21)

27 XML e SQL Al pari di di SQL per i database relazionali; XML deve essere espressivo come un linguaggio query strutturato

28 Alcuni XMS possono avere dei limiti nelle capacita di query-processing ed è possibile che alcuni benchmark non possono eseguiti in questi sistemi. Questo problema può essere risolto avendo dei benchmark query separati, testando ognuno un diverso tipo di aggregazione.

29 Questa scelta deve essere affrontata inoltre dalla grande possibilità di scelta di funzioni che un utente può usare-avere bisogno-. Questo permette di semplificare lanalisi dei resultati, evidenziandone le caratteristiche.

30 CONFRONTI TRA BENCHMARK Prendiamo in esame 3 benchmark di XML. I Benchmark considerati sono: XOO7, XMach-1, Xmark ; attraverso i quali valuteremo le caratteristiche del query- processing di XML.

31 XOO7 benchmark XOO7 benchmark si basa sullo OO7 benchmark. Lo XOO7 benchmark ne è una versione per XML e contiene nuove funzionalità; tra cui nuove query.

32 XOO7 benchmark Lo XOO7 benchmark testa le stesse caratteristiche del XML, che lo OO7. Anche la struttura dati di base del XOO7 benchmark deriva dallo OO7 benchmark.

33 XOO7 benchmark I parametri e i valori corrispondenti che sono usati per controllare la dimensione dei dati XML dello XOO7 benchmark sono:

34 I parametri del XOO7 Database ParametriPiccoliMediGrandi NumAtomic PerCompo site NumConne ctionPerAto mic 3,6,9 Document Size(bytes)

35 I parametri del XOO7 Database ParametriPiccoliMediGrandi ManualSize (bytes) NumComp ositePerMo dule NumAssem blyPerAsse mbly 333

36 I parametri del XOO7 Database NumAssem blyLevels 557 NumComp ositePerAs sembly 333 NumModul es 111

37 Differenze tra XOO7 e OO7 Ci sono alcune importanti differenze fra i parametri del database in XOO7, confrontate con quelle del OO7 benchmark :

38 Differenze tra XOO7 e OO7 Nello OO7 benchmark ci sono 7 livelli nei grandi database, mentre nei piccoli e nei medi database, a causa di restrizioni degli strumenti di XML, ci sono solo 5 livelli. Nello OO7 benchmark ci sono 10 moduli in un grande database. XOO7 benchmark, invece, supporta solamente un modulo; questo perché lelemento modulo è stato scelto come radice del documento XML

39 Differenze tra XOO7 e OO7 Siccome i dati in XML si possono essere rappresentati in albero, la dimensione dei dati può essere cambiata in 2 direzioni: PROFONDITA e AMPIEZZA.

40 Profondità e Ampiezza La profondità dell albero può variare con il cambiamento del valore del NumAssemblyLevels, mentre lampiezza dellalbero può essere controllato dal valore di un NumAtomicPerComposite o NumCompositePerModule. Lutente può variare questi valori.

41 Le OO7 QUERIES Le queries generate dal OO7 benchmark non coprono tutte le funzionalità delle queries XML. Infatti la maggiore parte delle queries dello OO7 benchmark si focalizzano nella capacità delle query data-centric nei sistemi object-oriented database

42 Le XOO7 QUERIES LO XOO7 benchmark copre più funzionalità delle queries, rispetto allo OO7 benchmark

43 Differenze tra XOO7 e OO7 QUERIES Infatti la maggiore parte delle queries dello OO7 benchmark si focalizzano nella capacità delle data-centric nei sistemi object-oriented database. Invece lo XOO7 benchmark copre più funzionalità.

44 Differenze tra XOO7 e OO7 QUERIES Le queries nello XOO7 sono divise in ben 3 gruppi: Il primo gruppo consiste nelle query tradizionali dei database. Il gruppo 2 consiste nelle navigational queries. Il gruppo 3 consiste nelle query del documento.

45 Le XOO7 QUERIES Le queries generate dal OO7 benchmark non coprono tutte le funzionalità delle queries XML. La maggiore parte delle queries dello OO7 benchmark si focalizzano nella capacità delle query data-centric nei sistemi object- oriented database.

46 Le XOO7 QUERIES Alcuni XMS supportano la maggior parte delle query Tali XMS sono considerati portatili. Gli utenti possono sempre scegliere il subset di query più appropriato per testare le caratteristiche delle loro applicazioni.

47 Xmach-1 benchmark Il Xmach-1 è un benchmark multiuso progettato per le applicazioni B2B. Analizziamo ora, solo i casi speciali del benchmark Xmach-1 adoperato da un singolo utente in una stessa macchina.

48 Xmach-1 DATABASE LXmach-1 benchmark limita i dati XML, per poterli adoperare in una forma semplice e con valori di piccola dimensione. Supporta XMS schema-based e schema-less e permette limplementazione di alcune funzionalità sul livello di applicazione.

49 Xmach-1 DATABASE Tutti i file XML simulano un articolo con elementi come titolo,capitolo,sezione,paragrafo, etc. I dati di testo sono presi dal linguaggio naturale.

50 Xmach-1 DATABASE Lutente può cambiare la misura del file XML modificando il numero degli elementi dellarticolo. Variando il numero dei file XML, controlla la misura del database; tuttavia Xmach-1 assume che le modifiche apportate ai file dei dati sul web siano minime.

51 Le Xmach-1 Queries LXmach-1 valuta le carateristiche di linguaggi standard e linguaggi non standard; quali lInserimento, la cancellazione, le interrogazioni URL e le operazioni di aggregazione.

52 Le Xmach-1 Queries Questo Benchmark consiste in 8 query e 2 operazioni di aggiornamento. Per migliorare il confronto, dividiamo le query in 4 gruppi basandosi sulle caratteristiche che catturano.

53 Le Xmach-1 Queries 1 gruppo consiste in semplici selezioni e in progettazioni delle query, confrontando il valore dellattributo. 2 gruppo chiede ai sistemi di usare lordine degli elementi per estrarre i risultati.

54 Le Xmach-1 Queries 3 gruppo testa le funzioni di aggregazionee usano le informazione dei metadati. 4 gruppo sono operazioni di aggiornamento

55 L Xmark benchmark LXmark benchmark simula uno scenario, anche molto specializzato, che contiene elementi e attributi che possono essere difficilmente capibili dallutente

56 LXmark database Le entità principali del database sono: articoli, persone, categorie, etc. Gli articoli sono gli oggetti che sono in vendita o sono già venduti. Le persone contengono sottoelementi quali nome, indirizzo, . Le categorie hanno un nome e una descrizione.

57 LXmark queries Xmark prevede 20 query che sono state analizzate in una ricerca interna del prototipo Xmark sono divisi in 4 gruppi basandosi nella funzionalità dei query

58 LXmark queries Xmark sono divisi in 4 gruppi basandosi nella funzionalità dei query : Il gruppo 1 contiene le query relazionali piu semplici; abbiamo quindi confronti dei vari tipi di valori di dati. Il gruppo 2 sono query su documenti che preservano lordine degli elementi.

59 LXmark queries Il gruppo 3 contiene le query navigazionali. Le query del gruppo 4 richiedono la cura della aggregazione e lordinamento delle operazioni.

60 CONCLUSIONI Lo XOO7, Xmach-1 e Xmark benchmarcks sono stati progettati per testare la performance di XMS diversi. Tutti questi 3 benchmarks catturano le caratteristiche essenziale dei dati XML e la varietà dei valori.

61 CONCLUSIONI Xmark e XOO7 coprono più funzionalità. Xmach-1 copre meno funzionalità. Osserviamo che XOO7 e Xmach-1 danno query semplici che danno 1 o 2 funzioni; invece la maggior parte delle query fatte con Xmark sono complesse e coprono più caratteristiche.

62 CONCLUSIONI E possibile che alcune query Xmark non possono essere eseguite o applicabili perché il sistema che si sta testando supporta solo un subset delle caratteristiche.

63 CONCLUSIONI XOO7 permette agli utenti di cambiare la dimensione del file in profondità e in ampiezza. Xmark cambia la dimensione del database di un certo fattore Xmach-1 assume che i file XML sono piccoli, cambiando il numero dei file XML cambia la dimensione del database. Tale dimensione e più piccola.

64 CONCLUSIONI Come abbiamo già visto la qualità di un XMS benchmark può essere analizzata rispettando i 4 criteri: SIMPLICITY RELEVANCE PORTABILITY SCALABILITY

65 Microbenchmark Un aspetto che i benchmark XML correnti non possono focalizzare è la performance della valutazione delle operazioni elementari come: la selezione, join, aggregazione. Cè un micro-benchmark che può evidenziare la performance di questi operazioni elementari, e può essere in aiuto del sviluppatore del database.

66 Microbenchmark Una pubblicazione stimolante del disegnare qualche benchmark, è la scelta del data set che si usa. Il data set del benchmark deve essere abbastanza complesso da incorporare le caratteristiche dei dati. Nello stesso tempo la data set del benchmark deve essere anche semplice in modo che le queries possano guidare lutente del benchmark.

67 Related Work (Simili lavori) Sono state fatte tante proposte per generare XML data sintetiche. Aboulnaga et al. propose un generatore di dati che accetta 20 parametri per permettere allutente di controllare le proprietà del data generato. Barbosa et al. propose un generatore di dati per XML, che genera multipla sintonie di data sets.

68 Lavori simili In contrasto a questi, il generatore di dati nel Michigan benchmark produce un XML data sets progettato per testare diverse caratteristiche del XML data. Poi ci sono i tre benchmark proposti per valutare la performance del XML data managemnet systems: Xmach-1, Xmark e XOO7.

69 Benchmark Data set Una discussione sulle caratteristiche dei dati Le caratteristiche primarie dei Dati sono: la selezione degli attributi e la selezione degli join.

70 Benchmark Data set Depth and Fanout Depth e Fanout sono 2 parametri strutturali importanti per lalbero dei dati. La profondità dellalbero dei dati ha un impatto significativo nella performance quando si compiono relazioni tra padre e figli.

71 Benchmark Data set Un modo per testare la profondità e il fanout è il generare un numero distinto di data sets con valori diversi per ogni valore di questi parametri. Bisogna notare che un numero grande di data set influenza il lavoro del benchmark creando delle difficoltà nel suo funzionamento e nel capirlo.

72 Benchmark Data set Il fanuot è il numero dei figli per ogni nodo, che può variare secondo il livello. Per esempio, in un albero con 16 livelli, ogni livello ha un fanout di 2, eccetto i livelli 5,6,7 e 8. I livelli 5,6,7 hanno un fanout di 13 invece, il livello 8 ha un fanout di 1/13 (nel livello 8 ogni 13 nodi si ha un solo figlio).

73 Benchmark Data set Data Set Granularity Per tenere il benchmark semplice, si sceglie un grande albero del documento come data set default. Il documento granularity può modificare il data set del benchmark per separare ogni nodo di un livello come radice di un documento distinto. Inoltre, può confrontare la performance delle queries del data set modificato con quelle del data set originale.

74 Benchmark Data set Scaling Un buon benchmark ha bisogno di essere scalato in ordine, per misurare la performance dei databases in piattaforme diverse. Con XML ci sono tanti opzioni per scalare, come: aumentando il numero dei nodi, la profondità e fanout.

75 Benchmark Data set Nel progetto del benchmark data set, il fanout degli ultimi livelli dellalbero si mantiene costante. Questo progetto implica che la percentuale dei nodi nei livelli più bassi è quasi costante per tutti i data sets.

76 Benchmark Data set Lo schema del Benchmark data La costruzione del benchmark data è centralizzato nel tipo del elemento BaseType. Ogni elemento BaseType ha alcuni attributi come: aUnique1: attributo che serve come identificatore dellelemento. aUnique2: un intero generato casualmente.

77 Benchmark Data set aLevel: un intero set per inserire il livello del nodo. aFour: un intero set di aUnique2 mod 4. aSixteen: un intero set di aUnique1 + aUnique2 mod16. aSixtyfFour: un intero set per aUnique2 mod 64.

78 Benchmark Data set aString: una stringa approssimata in una lunghezza di 32 bytes. Il contenuto del ogni elemento BaseType è una lunga stringa approssimata in una lunghezza di 512 byte.

79 Benchmark Data set Benchmark Queries Di più ci interessa valutare il costo dei parti individuali delle funzionalità delle queries che valutare la performance composta. Inoltre, è conveniente riferirsi alle query come selection query, join query, etc. usando la decomposizione delle queries.

80 Benchmark Data set Selezione (Selection) La selezione XML è l operazione più complessa e più importante per la gestione della struttura dellalbero.

81 Benchmark Data set Struttura di ritorno(Returned Structure) In una relazione, una volta selezionata una tupla, viene restituita proprio quella tupla. Invece, in XML, una volta selezionato un elemento, può tornare lelemento, oppure lelemento e i suoi figli, oppure il sottoalbero con radice lelemento.

82 Benchmark Data set Selezione semplice (Simple selection) Le XML queries coinvolgono solo un elemento e un singolo predicato può mostrare diversi risultati considerabili.

83 Benchmark Data set Selezione strutturale (Structural selection) La selezione in XML è spesso basata su patterns. Le queries devono essere costruite in modo tale che considerano anche patterns multinodi. Queste patterns spesso hanno una condizione di selezione.

84 Benchmark Data set La selezione condizionale (conditional selectivity) in XML è complicata perché diversi attributi possono non essere nello stesso elemento.

85 Benchmark Data set Un Value-Based Join funziona confrontando i valori di due diversi nodi. La struttura di ritorno è un albero con le coppie collegate (join-pair). Ogni albero ha uno join-nodo come radice e due figli, uno corrispondendo ad ogni elemento partecipante nello join.

86 Benchmark Data set Join con indicazione (Pointer-Based Join) I Pointer-Based Joins sono semi-join queries. Gli elementi che ritornano sono solo i nodi selezionati, non quelli puntati.

87 Benchmark Data set Aggregazione (Aggregation) Le queries aggregate sono molto importanti per le applicazioni di deposizione del Data data-warehousing.

88 Benchmark Data set Aggiornamenti (Updates) Gli aggiornamenti sono: inserimento (insert), cancellazione (delete) etc.

89 Confronto tra vari database Memorizzazione dei documenti XML

90 Introduzione Il numero dei documenti XML crescerà rapidamente in futuro, data la crescente importanza di questo linguaggio. Un problema da notare è come aggiungere i documenti XML mentre si stano salvando le loro strutture; permettendo, inoltre, accessi efficienti per le parti dei documenti strutturati.

91 Introduzione Ci sono vari sistemi di base di dati standard; relational, object-oriented, object-relational, come directory servers e ultimamente le così dette native XML database.

92 Introduzione Per fare i confronti fra i sistemi di base di dati, è stato usato il DOM (Document Object Model). DOM indirizza i documenti XML costruendo degli alberi. Gli elementi di un documento diventano nodi interni del albero DOM, invece gli attributi, commenti, testi, enti e notazioni formano le foglie dell albero.

93 I modelli dei dati per i documenti XML Limplementazione senza tipo del DOM In una nontyped DOM implementation, per ogni interfaccia del DOM è definita una classe. Le classi, tra altri attributi contengono anche parentNomeInterfaccia, childNomeInterfaccia per implementare lalbero e per permettere la navigazione da un nodo dellalbero ai suoi figli e il contrario.

94 I modelli dei dati per i documenti XML Inoltre, implementa anche i metodi predefiniti come firstChild, lastChild e così via.

95 I modelli dei dati per i documenti XML Questi metodi fanno si che costruire ed attraversare lalbero. Infine, usando il DOM tutto il documento XML è contenuto in un gruppo di istanze appartenenti alle classe che implementano le interfacce. Sono proprio le istanze quelle che contengono linformazione del document- specific e non le classe

96 I modelli dei dati per i documenti XML Limplementazione con tipo del DOM Come una estensione del nontyped implementation, ogni classe che implementa una interfaccia può avere delle sottoclassi definite per ogni tipo di elemento di un documento XML. Queste classi sono in relazione con gli altri elementi, attributi rappresentati con composizioni(associazione).

97 I modelli dei dati per i documenti XML La differenza fra questi due approcci è che nel primo approccio la struttura del documento è riprodotto solo negli stati delle istanze. Invece, nel secondo approccio, la struttura del documento è mostrato dalla composizione gerarchico delle classe.

98 Base di dati per inserire i Documenti XML Anche se i documenti XML sono di testo e questi possono essere inseriti su files, sono chiamati dati semi-strutturati poichè hanno bisogno di essere accessi attraverso la struttura.

99 Base di dati per inserire i Documenti XML Relational databases Linserimento dei documenti XML con relational databases vuol dire descrivere le strutture tree-type, con relazioni in modo gerarchico. Questo è reso possibile attraverso due alternative di modelli di dati per documenti XML:

100 Base di dati per inserire i Documenti XML A Simple Nontyped DOM Implementation Usando il DOM, queste strutture sono state trasformate in alberi, grazie alle classe che implementano le interfacce del DOM.

101 Base di dati per inserire i Documenti XML Lalbero viene formato da due associazioni: lassociazione dei childNodes e del ParentNode. Lassociazione dei childNodes è multivalore la quale crea relazioni fra nodi (one-to-many).

102 Base di dati per inserire i Documenti XML Inoltre, ogni elemento riceve un numero di identificazione che si usa come una key.

103 Base di dati per inserire i Documenti XML The Typed DOM Implementation Limplementazione di tipo DOM definisce una classe per ogni elemento e inserisce le istanze di una classe in una tabella con lo stesso nome.

104 Base di dati per inserire i Documenti XML La localizzazione dei elementi, che si realizza dalla composizione, neccessita di un numero di identificazione, chiamato key.

105 Base di dati per inserire i Documenti XML Object-Oriented database Le base di dati di tipo Object-Oriented inseriscono gli alberi DOM senza aver bisogno dellindirizzamento degli oggetti e le loro relazioni con altri concetti di dati.

106 Base di dati per inserire i Documenti XML Le varianti dellimplementazione del DOM sono riflesse su degli schemi che verranno valutati confrontandoli con altri. Gli sistemi di base di dati object-oriented, permettono anche ladattamento dinamico dello schema.

107 Base di dati per inserire i Documenti XML Siccome questo rappresenta la struttura del documento, una piccola modificazione può portare ad una invalidazione dei documenti, che seguono il DTD originale,modificati. Queste modificazioni hanno degli effetti svantaggianti.

108 Base di dati per inserire i Documenti XML I sistemi di base di dati object-oriented, hanno un metodo per indicizzare i node set ed avere così un modo più veloce per accedere ai nodi figli di un elemento.

109 Base di dati per inserire i Documenti XML Directory servers Directory servers può essere un altro database molto interessante. Vengono memorizzati dati strutturati. Gli accessi in lettura sono molto veloci,mentre laccesso per la scrittura dei dati è lento.

110 Base di dati per inserire i Documenti XML Un'altra caratteristica importante è che i dati vengono organizzati in un albero.

111 Base di dati per inserire i Documenti XML Directory servers sono estesi come indirizzi delle base di dati che sono accessibili usando il LDAP (Lightweight Directory Access Protocol), un semplice variante del X.500 ISO standard. LDAP directory contiene informazioni su oggetti come dipartimenti, persone in una società, risorse etc.

112 Base di dati per inserire i Documenti XML Directory servers sono stati sviluppati per offrire un libro centrale di indirizzi. Tale libro contiene una serie di nomi degli attributi che possono essere inclusi in un oggetto di una classe, per esempio: o per organizzazione, cn per cognome.

113 Base di dati per inserire i Documenti XML Lo schema delle directory servers è definito usando le classi con delle relazioni tra di loro.

114 Base di dati per inserire i Documenti XML Native XML databases Le native XML databases sono specializzate per inserire e per processare i documenti XML. Il sistema del basi di dati che si usa deve conoscere il DTD. Usando DTD, il sistema crea lo schema del base di dati.

115 Le specificazioni di Benchmark In questa parte vedremo come le directory servers si usano come XML data management systems e vedremo anche un confronto fra i sistemi di database relational, object-oriented, e native XML.

116 Le specificazioni di Benchmark Salvo il sistema native XML database che include un proprio linguaggio di query per accedere al database, dobbiamo implementare laccesso su ogni altro database. La standardizzazione del linguaggio query XML è completa, però mancano alcune implementazioni nella versione finale. Ci affidiamo allora ai requisiti generali che la memoria dei documenti XML incontrerà in avanti.

117 Le specificazioni di Benchmark I documenti XML devono essere inseriti in un base di dati e devono avere la possibilità di essere modificati in parti. I linguaggi dei query XML devono, inoltre, contenere questi requisiti:

118 Le specificazioni di Benchmark Un documento o parti del documento devono avere la possibilità di essere raggiunti usando la struttura, il contenuto o i valori degli attributi. Un documento XML o parti di un documento XML devono avere la possibilità di essere estratti.

119 Le specificazioni di Benchmark Un documento devono avere la possibilità di essere ridotto in parti ottimizzando i sottoelementi. Alcuni parti devono avere la possibilità di essere ristrutturate per creare un nuovo documento. Gli elementi devono avere la possibilità di essere combinati tra di loro per creare un documento.

120 Le specificazioni di Benchmark Benchmark su un Directory server Per memorizzare un documento XML in una directory server, si attraversa lalbero DOM, si creano le entrate (entries) e si inseriscono tutte nellalbero delle informazioni del directory.

121 Le specificazioni di Benchmark Lestrazione di un documento XML si fa selezionando le entrate (entries) nellalbero delle informazioni della directory. Il metodo di selezione del LDAP permette di restituire tutto lalbero che però non è ordinato. Inoltre, LDAP contiene dei metodi per cercare le entrate (entries) basandosi nei loro nomi distinguibili.

122 Le specificazioni di Benchmark Benchmark su un Native XML database Le basi di dati XML, assicurano dei metodi per inserire un documento XML sul database ed estrarre lintero documento dal database.

123 Le specificazioni di Benchmark Questo implementa anche un query XML e un linguaggio di updating che permette di esprimere gli stati delle specifiche dei benchmark.

124 Le specificazioni del Benchmark Risultati di un test I benchmark sono stati provati su un server Intel Pentium III con 450MHz, 256MB RAM e due UW-SCSI hard disks. La prova è stata fatta tra relational DBMS, object-orientede BDMS, directory server e native XML DBMS.

125 Le specificazioni del Benchmark I documenti usati per la prova sono stati generati automaticamente basandosi in una DTD che definisce la struttura delle descrizioni del progetto. Il DTD contiene 26 elementi con un max di 8 e 4 attributi. I documenti XML basati su questo DTD contengono informazioni su membri di un progetto, come nome, indirizzo, etc.

126 Le specificazioni del Benchmark Per confrontare i tipi diversi dei database, sono stati fatti i seguenti test: Memorizzare, inserire documenti XML Estrarre interi documenti XML Cancellare interi documenti XML Estrarre parti dei documenti identificati dalla posizione degli elementi sul documento. Reinserire parti dei documenti

127 Le specificazioni del Benchmark La valutazione della performance Dopo aver fatto girare cinque volte i benchmark sono venuti fuori questi risultati: La base di dati O-O è il migliore per inserire i documenti XML, invece il peggiore è relational database con tipo.

128 Le specificazioni del Benchmark Per estrarre interi documenti, native database ha dato i risultati migliori. Invece, i risultati peggiori gli ha dato il relational database con tipo. Invece, per estrarre parti di documenti, tutte i database hanno mostrato risultati simili, che dipendono dalla dimensione del documento. Però, il più veloce è il relational database.

129 Le specificazioni del Benchmark I risultati peggiori gli ha dato O-O database, causati dalla ricostruzione e la ricerca dellalbero DOM. Per il caso del reinserimento il più veloce è relational database senza tipo e il peggiore è O-O database lo stesso motivo di quello in precedenza. Ce da notare che in questo caso il database native XML subisce una grande caduta di prestazione con laumento della dimensione del documento.


Scaricare ppt "Benchmark Riccardo Cinus 2790600 Lorena Shestani 3665720."

Presentazioni simili


Annunci Google