Website architectuur: via of database of xml-parsing

[Milmoor]

Zelf ben ik geen web-expert, maar onze externe leverancier hiervan heeft een boodschap waar ik graag een second opinion bij wil. Zij krijgen een bak ruwe data aangeleverd in XML-vorm die gecached moet worden. Zij adviseren hiervoor een database van erg veel centjes. De hoeveelheid data is echter niet groot, en ik heb het gevoel dat het overkill is. Ik meen dat het tegenwoordig mogelijk is om een XML bestand te benaderen vanaf je website alsof het een database is. Bij grote hoeveelheden benaderingen en/of data is dat natuurlijk niet efficient, maar dat is hier mijns inziens niet het geval. Het gaat om zo'n 400 regels met redelijk beperkte datavelden, op twee blokken van tot 512 tekens aan tekstinformatie na. Het gaat puur om lezen hiervan met wat filters. Iets in de trand van:

SELECT *
FROM XML-bestand
WHERE veld6=plaatsnaam AND veld3<500 AND veld3>300
GROUP BY veld6

Wel is het zo dat elke bezoeker zijn eigen filters zal instellen. Ik denk dat er tot max. 500 tegelijktijdige bezoekers zullen zijn, die zullen niet continu opvragen, maar wel regelmatig de filtering aanpassen. Op de pagina's zelf zullen ook meerdere voorgedefinieerde opvragingen gedaan worden.

De webbouwer heeft het platform voor het webontwerp totaal in eigen hand, ze zijn hier niet weer afhankelijk van derden. Ook kunnen zij zelf bepalen waar het XML bij hun lokaal opgeslagen wordt.

Zie ik iets over het hoofd?

[ Voor 7% gewijzigd door Milmoor op 12-11-2008 16:40 ]

[pedorus]

Ik gok dat het het makkelijkst is om het hele XML bestand naar de client halen, en daar de filtering met XPath/XSLT in Javascript te doen. De responsetijd zal zeer snel zijn, het blijft offline werken, en een database is ook overbodig. Ik ga er even vanuit dat iedereen Javascript toch al aan heeft, zo niet is XQuery op de server ook een optie. (500 bezoekers is hoeveel pageviews/sec?)

[Milmoor]

Uhm, de client, bedoel je daar de kant van de webbouwer, of van de bezoeker van de website mee? Het laatste is geen optie. De informatie moet geen eigen leven gaan leiden, en hij wordt regelmatig ververst (meerdere keren per dag).

[orf]

500 gelijktijdige bezoekers is behoorlijk wat (understatement) om op een XML los te laten. Dat wil je niet. Een database hoeft hiervoor niet heel ingewikkeld en/of duur te zijn. Op de database queries los laten is een stuk makkelijker dan op XML.

Met een inleesscript kan de data redelijk makkelijk en snel in een database gezet worden. Je kunt hiervoor makkelijk mysql gebruiken; dan zit je niet aan licentiekosten oid vast.

[pedorus]

Milmoor schreef op woensdag 12 november 2008 @ 18:13:
Uhm, de client, bedoel je daar de kant van de webbouwer, of van de bezoeker van de website mee? Het laatste is geen optie. De informatie moet geen eigen leven gaan leiden, en hij wordt regelmatig ververst (meerdere keren per dag).

Ik bedoelde de browser idd. Het verversen is juist geen probleem, aangezien dat prima met AJAX kan. Als je niet alle info in het XML-bestand wilt geven, dan kun je eventueel een gefilterde versie maken op de server.

orf schreef op woensdag 12 november 2008 @ 19:21:
500 gelijktijdige bezoekers is behoorlijk wat (understatement) om op een XML los te laten. Dat wil je niet.

Als het op de client gebeurd, kost het niet echt rekencapaciteit van de server. Maar zelfs dan gaat het hier om minder dan 50 kb aan XML. 1gb aan XML parsen kostte mij op een vrij oude laptop (512 MB geheugen, processor weet ik niet) welgeteld 30 seconden aan processortijd. Voor 500 requests gaat het dan dus om minder dan 0.0015 seconden om de XML even te parsen, zelfs als je dit steeds opnieuw zou doen. Wat bij de meeste XQuery-implementaties natuurlijk niet gebeurd.

Maar aan de andere kant zie ik ook niet echt in waarom de XML in database stoppen zoveel zou moeten kosten, en is de bouwer daar blijkbaar al mee bekend. En bij bijna ieder hostingaccount krijg je er gewoon een databaseaccount bij. Gewoon daarvoor gaan dus

[orf]

pedorus schreef op woensdag 12 november 2008 @ 21:10:
[...]
Als het op de client gebeurd, kost het niet echt rekencapaciteit van de server. Maar zelfs dan gaat het hier om minder dan 50 kb aan XML.
[...]

Ik doelde dan ook niet op client side parsing, maar op serverside parsing zoals ook in de start post staat. Clientside parsen en queries op los laten wil je echt niet.

Gebruik hiervoor een database, die zijn hiervoor gemaakt

[YopY]

Als het om niet zoveel gegevens gaat, zou je ook de gegevens op de server kunnen parsen en op de server in het geheugen op kunnen slaan met een tool als Memcache, zo kun je de hele database overslaan maar toch flexibel blijven. Ik heb zelf geen ervaring daarmee, maar dat is een optie waar ik zeker naar zou kijken.

[Soultaker]

Ik heb zelf slechte ervaringen met direct queryen van XML data. Het is naar mijn mening te traag en te complex ten opzichte van een relationele database, al is het conceptueel wel aantrekkelijk. Ik zal een aantal punten nader toelichten.

1. Tools om XML te verwerken zijn nog steeds niet standaard beschikbaar; denk aan simpele dingen als een XPath, XSLT of XQuery processor. Er zijn bijvoorbeeld PHP modules voor, maar die zijn niet overal geïnstalleerd. Dat betekent dat je dus vaak handmatig de nodige tools moet installeren en up to date houden, wat sowieso al een hoop extra werk oplevert, als het al mogelijk is (een dedicated server is al bijna een vereiste). Niet handig als je je site nog eens wil kunnen verhuizen.

2. De simpelste tools zijn stand-alone XSLT en XQuery processors die op ongeïndexeerde XML files werken. Dat werkt wel, maar in mijn ervaring is het in de praktijk gewoon veel te traag om fijn te werken als je de resultaten realtime nodig hebt, zeker als je externe tools op de command line moet aanroepen. Een paar honderd milliseconden klinkt wel aardig, maar als je dat voor elke HTTP request moet doen schiet het niet op.

De toekomst ligt dus wellicht bij XML databases, die documenten geïndexeerd opslaan waardoor queryen een stuk sneller zou moeten gaan. Daar zijn ook weer wat kanttekeningen bij te plaatsen:

3. Vaak gebruiken zulke databases een proprietary interface, wat de leercurve en exotische waarde van je project nog hoger maakt (voor de goede orde: exotisch is slecht, want moeilijk te onderhouden/migreren/etc.) Zelfs databases die XQuery gebruiken om queries uit te voeren (en standaard querytaal, dus in principe niet implementatie-specifiek) hebben een deels proprietary interface omdat XQuery een aantal essentiële dingen niet specificeert (zoals documentbeheer, en hoe je überhaupt referenties naar geïndexeerde documenten krijgt).

4. XML databases zijn momenteel vaak experimenteel of duur. De gratis databases die me nu te binnen schieten zijn Pathfinder en Sedna maar die hebben allebei zo hun eigen rariteiten of problemen en zijn mijns inziens niet echt klaar voor gebruik in een productieomgeving.

5. Zoals al eerder genoemd, wordt een oplossing waarbij met XML documenten gewerkt wordt, al snel een stuk ingewikkelder dan een vergelijkbare set-up met een relationele database. XML documenten updaten in een database is bijvoorbeeld erg lastig; meestal moet je dan een XML document op schijf bijwerken en opnieuw importeren in je database of iets dergelijks, maar daarmee wordt het een hele toer om de database up to date te houden met de documenten die ook op schijf opgeslagen zijn. Verder is het lastig om gegevens die je met b.v. XQuery ophaalt verder te werken (omdat de resultaten meestal XML fragmenten zijn, die op hun beurt weer lastiger te verwerken zijn in webtalen).

6. Tenslotte is de complexiteit van XML queries vaak lastig in te schatten, terwijl relationele joins juist redelijk bekend zijn (bij veel ontwikkelaars tenminste). XML databases zijn bovendien alles-of-niets: als je query traag is, kun je zelf niet veel doen om 'm sneller te maken; je hebt weinig of geen invloed op de manier waarop een database je query uitvoert en je kunt ook geen indices toevoegen. Het is waarschijnlijk dus makkelijker om een voorspelbare, schaalbare relationele database op te zetten.

Al met al denk ik dus dat je beter af bent als je je XML document in een relationele database importeert en je website gewoon met een vertrouwde relationele database opzet. Die relationele database kan dan zo'n beetje van alles zijn, en dus ook een gratis database als MySQL, PostgreSQL of zelfs SQLite (vooral als "cache" voor een ander databetand interessant), dus dat hoeft niet "veel centjes" te kosten.

[Juup]

Soultaker schreef op donderdag 13 november 2008 @ 00:44:
4. XML databases zijn momenteel vaak experimenteel of duur. De gratis databases die me nu te binnen schieten zijn Pathfinder en Sedna maar die hebben allebei zo hun eigen rariteiten of problemen en zijn mijns inziens niet echt klaar voor gebruik in een productieomgeving.

Toch is een xml database hier wel heel erg geschikt voor. Als het gratis of goedkoop moet, neem je bijvoorbeeld eXist en anders bv MarkLogic.
Je praat er met XQuery tegenaan en dat is nu universeel genoeg om achteraf je database nog te kunnen verwisselen.

Milmoor schreef op woensdag 12 november 2008 @ 16:39:
SELECT *
FROM XML-bestand
WHERE veld6=plaatsnaam AND veld3<500 AND veld3>300
GROUP BY veld6

Hmm more like:

XQuery:

let $plaatsnaam := "Amsterdam"
return //*[veld6 = $plaatsnaam][veld3 > 300 and veld3 < 500]

[ Voor 18% gewijzigd door Juup op 13-11-2008 01:24 ]

[pedorus]

Soultaker schreef op donderdag 13 november 2008 @ 00:44:
1. Tools om XML te verwerken zijn nog steeds niet standaard beschikbaar; denk aan simpele dingen als een XPath, XSLT of XQuery processor. Er zijn bijvoorbeeld PHP modules voor, maar die zijn niet overal geïnstalleerd.

PHP kan standaard XPath en vaak ook XSL-transformaties. ASP.NET kan standaard ook XPath en XSLT. Daarnaast kan iedere moderne browser dat ook, sinds IE5.

Maar ik geef toe dat dit niet echt 'proven technology' is, en dat je een bouwer die hier onbekend mee is dit beter niet op jouw kosten kan laten uitvinden... Als ik dit zelf zou maken (als hobbyprojectje), dan zou ik het waarschijnlijk een leuke oefening vinden in Client-side parsen (ik heb al een testsite waarop dit gebeurd, werkt in alle moderne browsers).

Een paar honderd milliseconden klinkt wel aardig, maar als je dat voor elke HTTP request moet doen schiet het niet op.

Dat was mijn schatting voor honderden requests, niet voor 1...

[Milmoor]

Gelukkig en helaas is het een project voor mijn werkgever, geen hobby-projectje. Het wisselen van hoster/webbouwer is daardoor geen issue, we ziten daar in de praktijk meerdere jaren aan vast. Ook zijn we beperkt tot wat zij aan faciliteiten bieden.

IF database THEN DedicatedServer(veel.centjes) ENDIF;

Het liefst zou ik de webbouwer met een tussenlaag laten werken. Dan kan de XML-parser zonder problemen vervangen kunnen worden door een echte database als dat nodig mocht blijken. Maar mijn technische kennis is beperkt, mijn onderbuikgevoel zegt dat een volledige dedicated database overkill is, maar ik kan dat niet goed onderbouwen. Vandaar mijn vraag. Over de technische implemenatie hoef ik mij trouwens niet druk te maken, daar hoort de leverancier mee overweg te kunnen. Ik heb alleen het idee dat de architectuur niet goed doordacht is, en dat men een olifant in wil zetten.

Het is trouwens puur platte data, de relationele aspecten spelen hier geen rol anders dan de naam van de kolommen. Het is meer een Excel-spreadsheet dan een relationele database.

[ Voor 23% gewijzigd door Milmoor op 13-11-2008 12:16 ]

[Soultaker]

Juup schreef op donderdag 13 november 2008 @ 01:17:

XQuery:

let $plaatsnaam := "Amsterdam"
return //*[veld6 = $plaatsnaam][veld3 > 300 and veld3 < 500]

Daar heb je al een implementatie-specifieke query te pakken, want je gebruikt nu een ongebonden context node in je XPath expressie. Misschien dat die in eXist impliciet gebonden is aan de hele collectie, maar dat zal niet in elke database zo zijn (meestal begin je je expressie met doc("url") maar dat werkt dan weer niet noodzakelijkerwijs voor geïndexeerde documenten, en zeker niet voor een collectie).

Er zijn overigens wel pogingen om dit soort dingen te standaardiseren (voor documentbeheer is er b.v. de XQuery Update Facility recommendation van de W3C) maar dat soort dingen zijn allemaal vrij recent en nog niet echt doorgedrongen tot alle beschikbare producten.

pedorus schreef op donderdag 13 november 2008 @ 11:33:
PHP kan standaard XPath en vaak ook XSL-transformaties. ASP.NET kan standaard ook XPath en XSLT. Daarnaast kan iedere moderne browser dat ook, sinds IE5.

Accoord, dat is wel aardig, maar als je een XML als database wil gebruiken is alleen XPath natuurlijk weinig en zelfs met XSLT is het behelpen. Dan nog blijven een aantal bezwaren (traag, complex, etc.) staan.

Let wel: ik zeg niet dat hiërarchische dataopslag (want daar gaat het feitelijk over) niet zinnig is of niet kan werken; integendeel. Ik heb alleen de indruk dat de techniek nog niet genoeg uitgekristalliseerd is om mensen aan te raden om het nu al te gebruiken als alternatief voor relationele dataopslag, een model dat simpelweg een heel stuk volwassener is.

[Soultaker]

Milmoor schreef op donderdag 13 november 2008 @ 12:12:
Het liefst zou ik de webbouwer met een tussenlaag laten werken. Dan kan de XML-parser zonder problemen vervangen kunnen worden door een echte database als dat nodig mocht blijken. Maar mijn technische kennis is beperkt, mijn onderbuikgevoel zegt dat een volledige dedicated database overkill is, maar ik kan dat niet goed onderbouwen. Vandaar mijn vraag.

Het moge duidelijk zijn dat ik de websitebouwer in principe gelijk geef, in de zin dat het me zinnig lijkt om gegevens in een relationele database te importeren.

Wat betreft een dedicated database: is het echt zo dat dit het enige is waarvoor de database gebruikt zou worden? Je kunt toch in deze tijd nauwelijks meer een website ontwikkelen die niet op de een of andere manier van een database gebruik maakt? Als er al een database is zou het toevoegen van een tabel niet zo'n probleem moeten zijn.

[Milmoor]

Er is bewust een scheiding aangebracht tussen de interne databases en de website. Layout en filtering is helemaal in handen van de webbouwer, onze database spuugt puur platte data uit. Hierdoor zijn we veel minder afhankelijk van de leverancier van onze primaire systemen bij veranderingen op de website Via XML kan de webbouwer opvragingen doen en specifieke acties uitvoeren. De meeste daarvan zijn real-time, en rechtstreeks op de database. Het zou de database veel te zwaar belasten om de basisinformatie bij elke klant opnieuw aan te moeten leveren via XML en binnen een redelijke periode is deze als statisch te beschouwen, vandaar het cachen.

[Milmoor]

Net een gesprek gehad met onze webbouwer. Ik heb erg veel aan de gegeven informatie en vooral het jargon gehad, bedankt. Hiermee kon ik goed uitleggen waar mijn bedenkingen zaten en wat mogelijke oplosrichtingen zouden zijn. We hebben gekozen voor een constructie waar men eerst tegen XML aanpraat alsof het een database is, maar indien nodig makkelijk op kan schalen naar een echte database.

[Soultaker]

Okee, leuk om te horen hoe het afgelopen is.