Cachen combi-resultaat meerdere tabellen

[Rekcor]

Ik heb een webapplicatie waarin de gebruiker werkt met tabellen met gegevens, soms verkregen uit meerdere databasetabellen (veel SQL joins, ik noem dit vanaf nu 'combi-resultaat'). De gegevens in deze tabellen veranderen relatief snel, maar toch wil ik proberen e.e.a. te cachen. De gebruiker heeft ook toegang tot de individuele tabellen en die worden gecached.

Nu is het probleem: in het combi-resultaat zal er altijd wel een waarde zijn die in de tussentijd veranderd is (want de individuele tabellen veranderen nogal veel). Het vervelende is dat het dan (bijv. van de 1000 rijen van het combi-resultaat) in de meeste gevallen maar om enkele rijen gaat die veranderd zijn.

Mijn vraag: is het toegestaan om het combi-resultaat te cachen en - als zich een wijziging voordoet in een individuele tabel - wijzigingen te veranderen in het gecachte resultaat? Het nadeel is dan dat je je gegevens op twee plekken hebt staan, het voordeel is een aanzienlijke tijdwinst.

(P.S. Ik doe alles in PHP5/MySql)

[curry684]

De hamvraag is of het je boeit als je gegevens soms even stale zijn. Zo ja heb je een fundamenteler probleem en moet je iets met een eventsubscriber model opzetten

[Rekcor]

curry684 schreef op vrijdag 20 februari 2009 @ 08:46:
De hamvraag is of het je boeit als je gegevens soms even stale zijn. Zo ja heb je een fundamenteler probleem en moet je iets met een eventsubscriber model opzetten

Eh... en nu in gewoon Nederlands :-)?

[curry684]

Cachen betekent dat je iets dat veel tijd/moeite heeft gekost om te prepareren ergens opslaat voor later gebruik om bij vervolglookups minder tijd/moeite kwijt te zijn. Het inherente risico daarvan is dat de 'brondata' wordt bijgewerkt en er dus een discrepantie ontstaat tussen de cache en de source. Gecachete die outdated is wordt 'stale' (oudbakken ) genoemd.

Dus, hoe erg is het als je data soms stale is

[Rekcor]

curry684 schreef op vrijdag 20 februari 2009 @ 16:10:
Cachen betekent dat je iets dat veel tijd/moeite heeft gekost om te prepareren ergens opslaat voor later gebruik om bij vervolglookups minder tijd/moeite kwijt te zijn. Het inherente risico daarvan is dat de 'brondata' wordt bijgewerkt en er dus een discrepantie ontstaat tussen de cache en de source. Gecachete die outdated is wordt 'stale' (oudbakken ) genoemd.

Dus, hoe erg is het als je data soms stale is

Stel dat het heel erg is en dat het heel veel tijd/moeite kost om te prepareren, is het dan 'toegestaan'/netjes om wijzigingen in het bronbestand direct door te voeren in de cache (ipv opnieuw prepareren)?

[curry684]

Dat kan een geldige cache expiration policy zijn

Cachen kun je op heel veel manieren uitvoeren - de simpelste is met een statische TTL (Time To Live), oftewel zodra iets gefetcht is beschouw je het X seconden/minuten/uren als geldig. Daarmee ga je gegarandeerd regelmatig de mist in, maar bijv. voor trackers zoals op de frontpage van Tweakers.net is het een simpele en zeer efficiente methode - je haalt die dingen op met een TTL van 30 seconden of zo en zit dus nooit meer dan 30 seconden fout, en tussendoor bespaar je jezelf wel vele duizenden DB-calls.

Als die fouten er niet mogen zijn heb je meerdere mogelijkheden - ga je de cache aanpassen (zelden wenselijk) of flushen/invalidaten on change (meestal het beste). In beide gevallen moet je een betrouwbaar mechanisme hebben om de change notification te propageren - wat daarin het beste is is zeer afhankelijk van je applicatiearchitectuur, platform etc. en de overhead van datgene wat je aan het cachen bent.

In simpele situaties zonder miljoenen viewers is de simpelste oplossing meestal om het hele cache leeg te gooien "on any change". Iets meer load dan een specifiekere oplossing, maar meestal boeit dat geen ruk omdat bijv. websites 99.9% van de tijd data selecten vs insert/update/delete.

[Kalentum]

Hoe lang doet die query erover? Misschien kun je die query optimaliseren zodat 'ie sneller gaat werken en je geen cache nodig hebt (of met een TTL van een minder dan een minuut). Ook complexe queries met veel joins kunnen gewoon snel zijn.

[Rekcor]

Bedankt voor de reacties!

Het zou goed kunnen dat de SQL beter kan - deze wordt automatisch gegenereerd - maar het grootste probleem zit hem in de hoeveelheid rijen die terugkomen.

Ik ga denk ik
- eerst de SQL optimaliseren
- dan kijken of ik de webapplicatie niet zo kan maken dat er minder rijen per keer terugkomen
- dan pas, als het dan nog langzaam is, met caching rommelen.