Snelle query op veel XMLs

[KopjeThee]

Ik heb het volgende probleem:
Ik krijg dagelijks ongeveer 1 miljoen xml's binnen (verdeeld over ongeveer 50 soorten). Op de totale inhoud wil ik graag diverse queries uitvoeren (in batch, dus niet via een GUI). Deze moeten vrij snel uit te voeren zijn. Nu heb ik verder weinig ervaring op dit gebied, dus ik kan wel wat advies gebruiken.

Mijn eerste gedachte was: Ik map de inhoud van de XMLs naar een relationele structuur. Bij binnenkomst van een serie XMLs parse ik ze en voeg ze toe aan de juiste relationele tabellen. Daarna kan ik "normale" SQL queries uitvoeren. Maar een kleine steekproef leert me dat ik per XML soort gemiddeld zo'n 10 relationele tabellen zou nodig hebben. Ik krijg veel tabellen, en het parseren duurt lang. De hoeveelheid tabellen kan ik nog mee leven, maar het lange parseren niet. Wat is de snelst beschikbare optie hiervoor? Ik zie veel XML parsers op Internet, maar wat is jullie ervaring?

Een andere optie is misschien om gebruik te maken van een "Native XML database", zoals Wikipedia: BaseX. Maar hier weet ik eigenlijk helemaal niets van af. Wat is hier snel? Heeft het veel voordelen?

Ook SQL Server biedt een mogelijkheid om XML te parseren. En ook hier heb ik geen ervaring mee.

Het lijkt mij dat je vroeg of laat toch moet parseren, dus dat je die tijd altijd kwijt bent. Aangezien ik een xml bestand gemiddeld meer dan eens wil uitvragen, lijkt het toch verstandig om bij binnenkomst al te parseren. Maar ik ben hier niet helemaal zeker van.

[52x16]

Mogelijk is een native XML database zoals BaseX, eXist-db, MonetDB of sedna het handigst voor wat je wilt. Betekent wel dat je je een beetje moet verdiepen in XQuery om er nuttige queries op uit te kunnen voeren. Ik heb zelf enige ervaring met eXist-db. Voordelen van een native xml database is de flexibiliteit die je hebt. Je hoeft niet na te denken over een vertaling van je XML naar een relationeel database model. Nadeel is wel dat je flink wat tijd moet investeren in het goed onder de knie krijgen van XQuery om gemakkelijk de inhoud te kunnen querien, en reken ook op een behoorlijke inleertijd voor het tunen van de database zelf. Er valt veel te indexeren aan een XML database, en vooral als je wilt dat je queries snel met een resultaat komen ben je daar ook veel tijd aan kwijt.

Of dat echt een nadeel is, het alternatief is ook tijdrovend. Je noemt zelf al de XML mogelijkheden van SQL Server, maar bijna elke relationele database levert hybride XML database mogelijkheden. Ook daarvoor geldt dat je daarvoor ook behoorlijk wat tijd moet investeren om er efficient mee om te kunnen gaan, en dat ook daar veel aan valt te tunen.

Een goede site om meer te weten te komen over XML databases, en die je kan helpen bij het maken van een keuze voor jouw probleem is http://www.rpbourret.com/, en specifiek op zijn pagina over XML en databases. Naast die pagina staat er op die site heel veel informatie over de verschillende mogelijke manieren om XML bestanden op te slaan in databases voor dataverwerking.

Succes!

[KopjeThee]

Bedankt voor de reactie! Ik heb duidelijk te maken met "Data-Centric documents". De structuur is heel stabiel. Dat zou wijzen op het gebruik van een RDBMS (niet-XML enabled database) of XED (XML enabled database). Een NXD (native XML database) is niet nodig lijkt het. Dan zou mijn vraag nog zijn:
Voor optie 1: Wat is de snelste manier om met behulp van een mapping XMLs in de database te krijgen?
Voor optie 2: Welke database is het snelst. Standaard zou SQL server mijn voorkeur hebben, aangezien ik daar wat kennis van heb en het elders al gebruik.

[ Voor 7% gewijzigd door KopjeThee op 06-04-2013 11:08 ]

[52x16]

Dat de XML structuur stabiel is, is nog geen argument om niet een NXD te gebruiken. Bij een NXD hoef je in ieder geval geen mapping te maken met een relationeel datamodel. Het importeren van de XML documenten kan zo simpel zijn als het kopiëren van de XML documenten naar een WebDAV schijf.

Op je vraag "welke database is het snelst" bestaat natuurlijk geen direct antwoord. Als je zelf ervaring hebt met SQL Server, is dat op zich al een argument om daar eerst eens mee te stoeien, en een proof-of-concept te maken.

[KopjeThee]

52x16 schreef op zaterdag 06 april 2013 @ 11:09:
Dat de XML structuur stabiel is, is nog geen argument om niet een NXD te gebruiken. Bij een NXD hoef je in ieder geval geen mapping te maken met een relationeel datamodel. Het importeren van de XML documenten kan zo simpel zijn als het kopiëren van de XML documenten naar een WebDAV schijf.

Dat is natuurlijk wel aantrekkelijk. De vraag is dan hoe efficiënt zo'n database werkt. Maar dat zal ook niet eenvoudig te beantwoorden zijn...

Op je vraag "welke database is het snelst" bestaat natuurlijk geen direct antwoord. Als je zelf ervaring hebt met SQL Server, is dat op zich al een argument om daar eerst eens mee te stoeien, en een proof-of-concept te maken.

Ja, dat is zo. Ik denk dat ik die kant op ga.

[52x16]

Voor de efficientie van de XML database maakt het niet uit hoe de XML documenten worden geïmporteerd. Op het moment dat je een XML bestand importeerd, wordt de XML structuur geparsed en opgeslagen in de database. Wat relevanter is, is welke indexen je verder nog aanlegt. Aangezien je XML structuur vast is, en je waarschijnlijk ook wel weet op welke gegevens je gaat querien, kun je die fors versnellen door het aanleggen van wat indices.

Op eerder genoemde site staan ook wat leuke use cases over het gebruik van native xml databases. Hierin staan ook enkele simpele voorbeelden van het gebruik van XQuery voor het opvragen van gegevens.

Als je gaat stoeien met SQL server zou je ter vergelijking ook BaseX, sedna of eXist-db kunnen downloaden en daarmee wat experimenteren om te onderzoeken wat het beste werkt.

[Juup]

Bij die hoveelheden bestanden (hoeveel MB/dag hebben we het over?) zal eXist het waarschijnlijk niet meer bij kunnen houden.

Als je echt snel wilt en low-level durft te gaan (is meer onderhoud) dan zou je voor een simpele SAX parser voor elk van je 50 soorten kunnen gaan.

Je moet dan de data die je hebben wilt er uit plukken en in je code zelf nog gaan aggregeren etc.

[ Voor 15% gewijzigd door Juup op 06-04-2013 14:19 ]

[KopjeThee]

Juup schreef op zaterdag 06 april 2013 @ 14:18:
Bij die hoveelheden bestanden (hoeveel MB/dag hebben we het over?) zal eXist het waarschijnlijk niet meer bij kunnen houden.

Ongeveer 2GB/dag

Als je echt snel wilt en low-level durft te gaan (is meer onderhoud) dan zou je voor een simpele SAX parser voor elk van je 50 soorten kunnen gaan.

Alles is een optie, als het maar snel is. Op het laagste nivo zal er enige historie van deze XMLs worden bijgehouden. Daarna zo vlug mogelijk aggregeren en in een relationele database zetten.

[ Voor 13% gewijzigd door KopjeThee op 06-04-2013 17:01 ]