Scrittura di XML su database, tempi e modi

L'applicazione creata e mantenuta dal mio gruppo di lavoro fa un uso molto pesante di dati XML salvati sul database, fino ad ora abbiamo sempre usato SQL2000 ma dalla prossima release manterremo solo la compatibilità con SQL 2005 e quindi finalmente diventa possibile usare qualcuna delle sue nuove feature.

Ho quindi scritto un piccolo client di test per testare il salvataggio e la lettura di 10000 record XML (con lunghezza variabile da 52 a 136588 byte ed una media di 3373) sui diversi tipi di campi che si possono usare su SQL 2005. Questi i risultati:

Campo di tipo NText: scrittura in 4.9 secondi, lettura 2.0
Campo di tipo NVarChar(MAX): scrittura in 3.6 secondi, lettura 2.1
Campo di tipo Xml: scrittura in 14.1 secondi, lettura 2.3

A questo punto ho provato a settare l'opzione "text in row" per la mia tabella in cui ci sono gli NText, rendendola quindi equivalente ad un NVarChar(MAX) come utilizzo fisico del disco

Campo di tipo NText con text in row abilitato: scrittura in 3.6 secondi, lettura 2.0

Quindi il carico necessario, lato SQL Server, per fare il parse di un XML sembra essere molto elevato e la gestione "fisica" dei dati su SQL server sembra impattare parecchio. Ho provato anche a fare un'ulteriore test in cui, invece di memorizzare XML memorizzavo uno stream compresso mediante la libreria di compressione, per cercare di minimizzare lo spazio ed il costo di scrittura (includendo anche i tempi di compressione/decompressione per avere dati comparabili):

Campo di tipo Image in cui scrivo XML compresso con GZip: scrittura 5.2 secondi, lettura 1.9
Campo di tipo Image in cui scrivo XML compresso con Deflate: scrittura 4.9 secondi, lettura 1.4

E' da notare che il campo XML non aveva schema associati dato che gli XML di partenza erano molto vari.

posted @ giovedì 9 agosto 2007 12:22

Print

Comments on this entry:

# re: Scrittura di XML su database, tempi e modi

Left by Davide Mauri at 09/08/2007 13:37
Gravatar
Ciao Massimo
il fatto che XML sia meno performante di un campo testuale è abbastanza intuitivo. Ogni volta che cerchi di inserire XML all'interno di SQL in un oggetto di tipo "xml", SQL Server ne deve controllare la correttezza sintattica in modo da assicurarsi che sia Well-Formed.
Fatto ciò l'xml viene memorizzato in un formato interno binario e quindi c'è anche questo overhead da tenere in considerazione.

Tutto ciò che perdi in inserimento lo guadagni però in temirni di facilità di manipolazione di XML, sulla quale puoi effettuare tutte le ricerce e modifiche che desideri.

Ovviamente se devi memorizzare XML e basta, senza farci nessun tipo di ricerca od operazione e ti serve solo una velocità estrema durante il caricamento dei dati il secondo metodo che hai già provato (campo Image + XML compresso) è la cosa migliore.

Devi però essere ASSOLUTAMENTE sicuro che nell'XML che memorizzi non ti serva effettuare nessuna operazione di ricerca.

# re: Scrittura di XML su database, tempi e modi

Left by Phillo at 09/08/2007 13:55
Gravatar
Il discorso di "cosa" fare con l'XML è la seconda parte del discorso, su cui sto ancora lavorando.
Personalmente sto lentamente arrivando alla conclusione che l'unica vera motivazione per avere dei campi XML è se sono tipizzati da Schema per poterci poi fare (in maniera veloce) delle query, il solo uso del campo XML si scontra con la velocità. Ma come dicevo sto ancora facendo qualche esperimento.

# re: Scrittura di XML su database, tempi e modi

Left by Alesssandro Scardova at 09/08/2007 14:03
Gravatar
Aggiungo oltre a quello che ha già correttamente detto Davide, il fatto che ADO.NET, quando impostiamo un SQLparameter di tipo SqlDbType.Xml instanzia internamente un XmlReader, che esegue ANCHE sul 'client' un controllo di well forming, che quindi viene fatto due volte, cosa che non avviente con gli altri tipi di dati.
Comments have been closed on this topic.