07. oktober 2005 - 13:45Der er
12 kommentarer og 1 løsning
Håndtering/søgning i store XML filer
Jeg påtænker at investere i an XML server platform til at håndtere meget store XML-søgninger.
I min søgning efter den løsning som bedst kunne imødekomme mine krav stødte jeg på nogle artikler som stillede spørgsmålstegn ved effektiviteten ved sådan en server platform.
Er der nogen af jer som er enig i at dette ikke er den bedst løsning og hvis ja hvilke alternativer ville i så foreslå til at håndtere meget store XML-søgninger.
For en god ordens skyld skal jeg måske nævne at de XML filer jeg arbejder på meget vel kan komme op på 500 Mb og samtidig vil jeg også have brug for at kunne arbejde på flere af disse store XML'er samtidig.
Jeg har ikke den store erfaring, men sund fornuft siger: - XML kræver altid masser af memory (og et gør database normalt også ...) - jeg tvivler på at XML databaser er så hurtige som normale relations databaser - 500 MB er små data idag - hvis XML strukturen er vigtig for søgning så må der være nogle fordele ved en XML database
Du kunne jo også prøve at hente den gratis Exist (med Tomcat) og lege lidt med den for at danne dig et indtryk.
Det kan godt være du har ret i det med XML databaser kontra relations databaser. Du skulle vel ikke tilfældigvis vide om effektiviteten af disse 2 er blevet testet op imod hinanden og i så fald hvor jeg kan se testresultaterne?
min antagelse er at en XML database performer et sted mellem acceptabelt og godt til det som den er beregnet til nemlig søgning baseret på tags i velstruktureret XML, men at det eller et sted mellem langsomt og acceptabelt
det er en specialiseret funktionalitet
men med 500 MB data tror jeg sagtens at du kan få det til at performe på en moderne computer
Det, jeg har brug for, er essentielt en god stabil database til søgning af data, inklusive fritekstsøgning.
Jeg har dårlig erfaring med Microsoft SQL Server 2000, da deres full-text service er ustabil (full-text search indekser forsvinder). Desuden kan full-text search indekser heller ikke bruges på cache tabeller, da disse indekser opbygges asynkront og relativt langsomt. Dvs. i minutterne efter cache tabellerne er opdateret kan man sagtens udføre "almindelige" søgninger, men IKKE full-text søgninger - indekserne er ikke opbygget endnu, og en søgning vil derfor ikke give noget resultat.
SQL LIKE operatoren er alt for langsom, så den kan ikke bruges.
SQL Server 2000 bruges ellers i dag til alt bortset fra søgninger.
XPath søgninger i Document Object Model (DOM) i Microsoft XML Core Services (MSXML) har en relativ god performance. XML er også fleksibelt da man kan udføre en søgning og få resultatet transformeret direkte til HTML. Problemet er så, at XML DOM objekter fylder meget i hukommelsen (50MB på disken kan sagtens være lig med 500MB i memory). Da dokumenterne må caches for at være hurtige er jeg derfor løbet ind i hukommelsesproblemer, og må se efter andre løsninger.
SAX2 kan håndtere store XML dokumenter, men man mister XPath og transformation. Specielt manglen på XPath udelukker SAX2, da det vil kræve for meget arbejde og løbende vedligeholdelse at udvikle noget tilsvarende.
Tilladte BB-code-tags: [b]fed[/b] [i]kursiv[/i] [u]understreget[/u] Web- og emailadresser omdannes automatisk til links. Der sættes "nofollow" på alle links.