Benchmark Riccardo Cinus 2790600 Lorena Shestani 3665720

Benchmark

Riccardo Cinus 2790600 Lorena Shestani 3665720

Benchmark

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

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.

Problematiche relative ai benchmark

Trovare un modo appropriato di

valutazione di un programma o di un

apparecchio hardware

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:

Relevance: Il Benchmark deve catturare le caratteristiche del sistema per essere misurato.

Portability: Il Benchmark deve essere capace di essere implementato su diversi sistemi.

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.

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.

Alcuni benchmark: Wisconsin benchmark

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

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

Altri Benchmark

Il Set Query benchmark valuta l’abilità 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

Benchmark e XML

Il disegno di un benchmark per valutare XML management systems è un nontrivial task.

L’obbiettivo del benchmark è di focalizzare gli aspetti del query-processing di XML.

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.

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.

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. l’ordine implicito degli elementi) e della navigazione (le referenze)

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:

Benchmark Data Set

La profondità del albero si può controllare variando il numero delle ripetizioni degli elementi ricorsivi.

L’ampiezza del albero si può aggiustare col variare del cardinalità di alcuni elementi

Benchmark Queries

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

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.

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)

Le regole

Supporta le operazioni su vari modelli di dati (R4)

Permette condizioni su elementi del testo (R5)

Supporta query sequenziali e gerarchiche (R6)

Le regole

Manipola i valori null (R7)

Supporta i quantificatori nelle query (R8)

Permette alle query di combinare parti di piu documenti (R9)

Le regole

Supporta per l’aggregazione (R10)

Capacità di generare risultati con tipo (R11)

Supporta la composizione di operazioni (R12)

Le regole

Permette la navigazione (R13)

E’ capace di usare le informazioni dell’ambiente come parti delle query (R14)

Capace di supportare aggiornamenti XML se il modello dei dati lo permette (R15)

Le regole

Supporta tipi di coercizione (R16)

Preserva la struttura dei documenti (R17)

Trasforma e crea le strutture XML (R18)

Le regole

Supporta la creazione degli ID (R19)

Ricorrenza strutturale (R20)

Ordinamento degli elementi (R21)

XML e SQL

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

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.

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

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.

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.

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.

XOO7 benchmark

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

I parametri del XOO7 Database

Parametri Piccoli Medi Grandi

NumAtomicPerComposite

20 200 2000

NumConnectionPerAtomic

3,6,9 3,6,9 3,6,9

Document Size(bytes)

500 1000 1000


Parametri Piccoli Medi Grandi

ManualSize(bytes)

2000 4000 4000

NumCompositePerModule

50 50 500

NumAssemblyPerAssembly

3 3 3


NumAssemblyLevels

5 5 7

NumCompositePerAssembly

3 3 3

NumModules

1 1 1

Differenze tra XOO7 e OO7

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


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é l’elemento modulo è stato scelto come radice del documento XML


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

Profondità e Ampiezza

La profondità dell’ albero può variare con il cambiamento del valore del NumAssemblyLevels, mentre l’ampiezza dell’albero può essere controllato dal valore di un NumAtomicPerComposite o NumCompositePerModule . L’utente può variare questi valori.

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

Le XOO7 QUERIES

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

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à.

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.

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.

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.

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.

Xmach-1 DATABASE

L’Xmach-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 l’implementazione di alcune funzionalità sul livello di applicazione.

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.

Xmach-1 DATABASE

L’utente può cambiare la misura del file XML modificando il numero degli elementi dell’articolo.

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 .

Le Xmach-1 Queries

L’Xmach-1 valuta le carateristiche di linguaggi standard e linguaggi non standard; quali l’Inserimento, la cancellazione, le interrogazioni URL e le operazioni di aggregazione.

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”.

Le Xmach-1 Queries

1 gruppo consiste in semplici selezioni e in progettazioni delle query, confrontando il valore dell’attributo.

2 gruppo chiede ai sistemi di usare l’ordine degli elementi per estrarre i risultati.

Le Xmach-1 Queries

3 gruppo testa le funzioni di aggregazionee usano le informazione dei metadati.

4 gruppo sono operazioni di aggiornamento

L’ Xmark benchmark

L’Xmark benchmark simula uno scenario , anche molto specializzato, che contiene elementi e attributi che possono essere difficilmente capibili dall’utente

L’Xmark 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, e-mail.

Le categorie hanno un nome e una descrizione.

L’Xmark 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

L’Xmark 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 l’ordine degli elementi.

L’Xmark queries

Il gruppo 3 contiene le query navigazionali.

Le query del gruppo 4 richiedono la cura della aggregazione e l’ordinamento delle operazioni.

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.

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.

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.

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 .

CONCLUSIONI

Come abbiamo già visto la qualità di un XMS benchmark può essere analizzata rispettando i 4 criteri:

SIMPLICITY RELEVANCE PORTABILITY SCALABILITY

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.

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 l’utente del benchmark.

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 all’utente di controllare le proprietà del data generato.

Barbosa et al. propose un generatore di dati per XML, che genera multipla sintonie di data sets.

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.

Benchmark Data set

Una discussione sulle caratteristiche dei dati

Le caratteristiche primarie dei Dati sono:

la selezione degli attributi e la selezione degli join.

Benchmark Data set

Depth and Fanout

Depth e Fanout sono 2 parametri strutturali importanti per l’albero dei dati. La profondità dell’albero dei dati ha un impatto significativo nella performance quando si compiono relazioni tra padre e figli.

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.

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).

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.

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.

Benchmark Data set

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

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 dell’elemento.

aUnique2: un intero generato casualmente.

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.

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.

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.

Benchmark Data set

Selezione (Selection)

La selezione XML è l operazione più complessa e più importante per la gestione della struttura dell’albero.

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 l’elemento, oppure l’elemento e i suoi figli, oppure il sottoalbero con radice l’elemento.

Benchmark Data set

Selezione semplice (Simple selection)

Le XML queries coinvolgono solo un elemento e un singolo predicato può mostrare diversi risultati considerabili.

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.

Benchmark Data set

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

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.

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.

Benchmark Data set

Aggregazione (Aggregation)

Le queries aggregate sono molto importanti per le applicazioni di deposizione del Data ‘data-warehousing’.

Benchmark Data set

Aggiornamenti (Updates)

Gli aggiornamenti sono: inserimento (insert), cancellazione (delete) etc.

Confronto tra vari database

Memorizzazione dei documenti XML

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.

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’.

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.

I modelli dei dati per i documenti XML

L’implementazione 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 l’albero e per permettere la navigazione da un nodo dell’albero ai suoi figli e il contrario.


Inoltre, implementa anche i metodi predefiniti come firstChild, lastChild e così via.


Questi metodi fanno si che costruire ed attraversare l’albero. 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 l’informazione del document-specific e non le classe


L’implementazione 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).


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.

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.


Relational databases

L’inserimento 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:


A Simple Nontyped DOM Implementation

Usando il DOM, queste strutture sono state trasformate in alberi, grazie alle classe che implementano le interfacce del DOM.


L’albero viene formato da due associazioni:

l’associazione dei childNodes e del

ParentNode. L’associazione dei childNodes è

multivalore la quale crea relazioni fra nodi (one-to-many).


Inoltre, ogni elemento riceve un numero di identificazione che si usa come una key.


The Typed DOM Implementation

L’implementazione di tipo DOM definisce una classe per ogni elemento e inserisce le istanze di una classe in una tabella con lo stesso nome.


La localizzazione dei elementi, che si realizza dalla composizione, neccessita di un numero di identificazione, chiamato key.


Object-Oriented database

Le base di dati di tipo Object-Oriented inseriscono gli alberi DOM senza aver bisogno dell’indirizzamento degli oggetti e le loro relazioni con altri concetti di dati.


Le varianti dell’implementazione del DOM sono riflesse su degli schemi che verranno valutati confrontandoli con altri.

Gli sistemi di base di dati object-oriented, permettono anche l’adattamento dinamico dello schema.


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.


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.


Directory servers

‘Directory servers’ può essere un altro database molto interessante.

Vengono memorizzati dati strutturati.

Gli accessi in lettura sono molto veloci,mentre l’accesso per la scrittura dei dati è lento.


Un'altra caratteristica importante è che i dati vengono organizzati in un albero.


‘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.


‘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”.


Lo schema delle directory servers è definito usando le classi con delle relazioni tra di loro.


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.

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.


Salvo il sistema native XML database che include un proprio linguaggio di query per accedere al database, dobbiamo implementare l’accesso 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.


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:


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.


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.


Benchmark su un Directory server

Per memorizzare un documento XML in una directory server, si attraversa l’albero DOM, si creano le entrate (entries) e si inseriscono tutte nell’albero delle informazioni del directory.


L’estrazione di un documento XML si fa selezionando le entrate (entries) nell’albero delle informazioni della directory.

Il metodo di selezione del LDAP permette di restituire tutto l’albero che però non è ordinato.

Inoltre, LDAP contiene dei metodi per cercare le entrate (entries) basandosi nei loro nomi distinguibili.


Benchmark su un Native XML database

Le basi di dati XML, assicurano dei metodi per inserire un documento XML sul database ed estrarre l’intero documento dal database.


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

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.


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.


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


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.


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.


I risultati peggiori gli ha dato O-O database, causati dalla ricostruzione e la ricerca dell’albero 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 l’aumento della dimensione del documento.

Documents

Benchmark Riccardo Cinus 2790600 Lorena Shestani 3665720