[java] Cache in Hibernate/JPA is waardeloos?

[Verwijderd]

Hoi,

Gisteren hadden we op het werk een interessante discussie, waarbij de stelling was dat de entity cache alsmede de 2nd level cache van b.v. Hibernate (via JPA) tegenwoordig compleet nutteloos is.

Het uitgangspunt hierbij was dat de database zelf veel meer is geoptimaliseerd voor caching en dat met name in combinatie met SSD disks voor de database de caching zoals aangeboden door Hibernate helemaal waardeloos is. Hibernate caching werd hierbij gezien als een overbodige tussenlaag die extra complexiteit in het systeem introduceert, en zulke tussenlagen moeten zoveel mogelijk vermeden worden.

1 developer stelde zelfs dat de cache semantisch incorrect is. Namelijk als hij data in de DB veranderd, en dan naar een webpagina toegaat die deze data ophaalt via de entity manager, dat deze dan altijd de oude data terug geeft (vanwege de caching). Hij is dus flink in de weer geweest om alle Hibernate caching overal weg te halen.

Mij lijkt dit laatste meer een verkeerd gebruik van Hibernate, maar ik vraag me af wat de meningen zijn van iedereen hier over dit onderwerp.

[rrrandy]

Verwijderd schreef op dinsdag 02 december 2008 @ 11:50:
Hoi,

Gisteren hadden we op het werk een interessante discussie, waarbij de stelling was dat de entity cache alsmede de 2nd level cache van b.v. Hibernate (via JPA) tegenwoordig compleet nutteloos is.

Het uitgangspunt hierbij was dat de database zelf veel meer is geoptimaliseerd voor caching en dat met name in combinatie met SSD disks voor de database de caching zoals aangeboden door Hibernate helemaal waardeloos is. Hibernate caching werd hierbij gezien als een overbodige tussenlaag die extra complexiteit in het systeem introduceert, en zulke tussenlagen moeten zoveel mogelijk vermeden worden.

1 developer stelde zelfs dat de cache semantisch incorrect is. Namelijk als hij data in de DB veranderd, en dan naar een webpagina toegaat die deze data ophaalt via de entity manager, dat deze dan altijd de oude data terug geeft (vanwege de caching). Hij is dus flink in de weer geweest om alle Hibernate caching overal weg te halen.

Mij lijkt dit laatste meer een verkeerd gebruik van Hibernate, maar ik vraag me af wat de meningen zijn van iedereen hier over dit onderwerp.

Dat laatste is niet verkeerd gebruik van Hibernate, maar uberhaupt geen gebruik van Hibernate. Wanneer je data wijzigt vanuit Hibernate dan gaat het via de cache en heb je dat probleem dus niet.

Wat betreft het overbodig zijn van de cache, daar kun je over twisten. Door data te cachen kun je het aantal queries naar de database in veel gevallen drastisch verminderen. Maar je hebt ook gelijk als je zegt dat je met een dergelijke cache data aan het dupliceren bent en bepaalde verantwoordelijkheden legt waar ze eigenlijk niet horen.

Waar ik met Hibernate meer problemen mee heb is dat veel ontwikkelaars het niet goed gebruiken. Het is erg makkelijk om je niet meer met je database hoeft bezig te houden, maar het is nog veel makkelijker om o zo inefficiente mappings in elkaar te zetten...

[Salandur]

Databases zijn zeker geoptimaliseerd om caching uit te voeren. Maar ook in een database is caching niet optimaal.

2nd level caching zoals Hibernate gebruikt heeft zeker een voordeel, want je hoeft niet voor elk object naar de database. Zeker als je dabase op andere hardware draait biedt dat voordelen.

2nd level caching moet je mijn inziens vooral inzetten voor data die niet zo vaak wijzigt of zelden geraakt wordt. Wat vaak of niet zo vaak is hangt natuurlijk af van de context.
Wij hebben een database met meldingen en code tabellen. De code tabellen worden met in een 2nd level cache geplaatst, maar de meldingen niet. Er kan namelijk op de meldingen gezocht worden, maar de kans dat er een hit optreedt in de cache is dusdanig klein dat het geen zin heeft om ze te cachen.
Een 2nd level cache moet je dus goed gebruiken wil je er voordeel van hebben.

rrrandy schreef op dinsdag 02 december 2008 @ 12:38:
[...]
Dat laatste is niet verkeerd gebruik van Hibernate, maar uberhaupt geen gebruik van Hibernate. Wanneer je data wijzigt vanuit Hibernate dan gaat het via de cache en heb je dat probleem dus niet.

Dit geldt zolang je niet geclusterd werkt en altijd manipulatie via je software doet. Het kan natuurlijk voorkomen dat je met de hand data wijzigt in de database, deze zal dan niet direct door je software opgepakt worden.
Bij clustering moet je zorgen voor invalidatie van de andere caches, tenzij het niet heel belangrijk is dat de data incorrect weergegeven wordt.

[Kettrick]

rrrandy schreef op dinsdag 02 december 2008 @ 12:38:
[...]
Waar ik met Hibernate meer problemen mee heb is dat veel ontwikkelaars het niet goed gebruiken. Het is erg makkelijk om je niet meer met je database hoeft bezig te houden, maar het is nog veel makkelijker om o zo inefficiente mappings in elkaar te zetten...

Om die reden maak ik vaak zelf eerst het datamodel, waarna ik hibernate de models en mappings laat bouwen, daar heb ik tot op heden nog geen problemen mee gehad.

Wat betreft het caching, het gebruik daarvan op tabellen waar veel mee gebeurt voegt weinig toe en kan voor problemen zorgen. Voor het lokaal houden van bijvoorbeeld lov tabellen en andere tabellen waarvan de inhoud niet vaak veranderd is het wel een leuke feature.

[latka]

Mijn mening: de 2nd level cache mag pas aan nadat de performance problemen opgelost zijn. Te vaak zie ik n+1 queries en andere inefficiente constructies de revue passeren. Ik heb op een gegeven moment een training gegeven waar de vraag aan de cursisten was om van een bepaald stukje Java code de Hibernate queries te meten en terug te brengen van 14 queries naar 4 door de mapping te verbeteren (de db bleef intact). Men heeft deze kennis vervolgens ingezet in de productie situatie van het eigen systeem et voila, de cache.
Zeker in gevallen waar er meerdere applicatie draaien op de server is het erg vervelend als iedere applicatie een multi-megabyte 2nd level cache actief heeft om fouten te maskeren.

[Kettrick]

latka schreef op dinsdag 02 december 2008 @ 12:48:
Mijn mening: de 2nd level cache mag pas aan nadat de performance problemen opgelost zijn. Te vaak zie ik n+1 queries en andere inefficiente constructies de revue passeren. Ik heb op een gegeven moment een training gegeven waar de vraag aan de cursisten was om van een bepaald stukje Java code de Hibernate queries te meten en terug te brengen van 14 queries naar 4 door de mapping te verbeteren (de db bleef intact). Men heeft deze kennis vervolgens ingezet in de productie situatie van het eigen systeem et voila, de cache.
Zeker in gevallen waar er meerdere applicatie draaien op de server is het erg vervelend als iedere applicatie een multi-megabyte 2nd level cache actief heeft om fouten te maskeren.

Eens, een cache mag in het geheel niet gebruikt worden om (performance ) problemen op te lossen .

Het deactiveren van de cache moet op elk moment mogelijk zijn zonder problemen te veroorzaken.

[Salandur]

RoeLz schreef op dinsdag 02 december 2008 @ 12:57:
[...]
Eens, een cache mag in het geheel niet gebruikt worden om (performance ) problemen op te lossen .

Het deactiveren van de cache moet op elk moment mogelijk zijn zonder problemen te veroorzaken.

Maar het helpt wel.
In ons geval zoeken we in 15.000.000 meldingen, maar de code tabellen beslaan een paar 1000 records. Die kan je dan nog wel makkelijk cachen. Zeker als de meldingen structuur gelaagd is biedt dat voordelen, maar we hebben wel meer 'truukjes' toegepast om de performance te verbeteren tot wat hij nu is.

[voodooless]

RoeLz schreef op dinsdag 02 december 2008 @ 12:57:
Eens, een cache mag in het geheel niet gebruikt worden om (performance ) problemen op te lossen .

Het deactiveren van de cache moet op elk moment mogelijk zijn zonder problemen te veroorzaken.

Waarom zou je dan een cache hebben Normale problemen oplossen, oke, daar moet je geen cache voor gebruiken! Maar performance problmen oplossen, dat is nu precies waarvoor een cache bedoeld is.

Ten eerste is het ontwerptechnisch niet altijd het meest handig op zo optimaal mogelijke query's te maken. Performance kan dan wel beter worden, maar leesbaarheid, beheersbaarheid en uitbreidbaarheid zeker niet altijd. Dan zijn er ook nog dingen die in SQL niet kan, en in code wel. Als je dan bepaalde dingen kan cachen die van de database komen, kan dat zeker van voordeel zijn. Verder is een locale cache zoals in Hibernate vele malen sneller dan de cache van de database en daarnaast ook een ontlasting voor de database, wat meer ruimte laat voor lange ingewikkelde query's.

En ja, het kost geheugen, so what:? Geheugen is goedkoop en er is geen rede om het niet te vullen met nuttige informatie

Zullen we anders eens vragen om de caches op de tweakers websites uit te zetten? Eens kijken hoe weinig impact op performance het heeft

Het is gewoon een kunst om een cache op de juiste plek en op de juiste manier te gebruiken. Dan is er eigenlijk niets op tegen.

[ Voor 10% gewijzigd door voodooless op 02-12-2008 14:51 ]

[Xiphalon]

Ik ben zelf tegen caches in web-applicaties. Je trekt dan namelijk een heleboel state-informatie naar de applicatieserver toe, waardoor je applicatie meteen niet meer (goed) te out-scalen is. Een extra applicatieserver toevoegen gaat niet makklijk meer omdat dan de caches gesynchronizeerd moeten worden (=duur) of er constant wordt geflushed (=doe dan geen cache).

In een windowsapplicatie kan het nogal eens handig zijn, maar zelfs dan moet je in de gaten houden dat je niet met tig applicatieinstanties met elk een eigen cache krijgt.

Uiteraard mag je van mij best read-only objecten cachen, als ze toch nooit wijzigen...

[ Voor 7% gewijzigd door Xiphalon op 02-12-2008 15:50 . Reden: r/o toevoegen ]

[voodooless]

Er zijn natuurlijk ook cache oplossingen te vinden die wel schaalbaar zijn over meerdere applicatieservers, zoals bijvoorbeeld memcached of JCS. Zo werken de caches transparant op al je servers en neem je een aantal van die problemen weg. Natuurlijk worden dit soort systemen dan wel weer complexer en ook langzamer, en je kunt je dan afvragen hoeveel winst je gaat halen t.o.v de ruwe database. In bepaalde gevallen lijkt me dat die winst nog steeds behoorlijk kan zijn.

[Hydra]

RoeLz schreef op dinsdag 02 december 2008 @ 12:57:
Het deactiveren van de cache moet op elk moment mogelijk zijn zonder problemen te veroorzaken.

Daar ben ik het niet mee eens. Als de toepassing vereist dat de cache aanwezig is kan dat prima in het ontwerp meegenomen worden. Te denken is aan heel veel kleine updates waarbij alleen de netwerklatency al een probleem zou vormen. Het is wat anders als de cache gebruikt wordt om lui te kunnen ontwikkelen.

[EfBe]

Cachen van data dat muteert: onzin om dat te doen in een O/R mapper cache (zie:
http://weblogs.asp.net/fb...ch-data-faster_2E00_.aspx

Cachen van data dat niet muteert (readonly data): tuurlijk.

het punt is alleen: men wil vaak muterende data cachen, terwijl dat nauwelijks effect heeft: immers, je moet toch de complete set ophalen tenzij je single, PK based entities op gaat halen, alleen dan kun je met een cache sneller werken (maar dat is ook maar betrekkelijk, zeker in een webfarm)

[flowerp]

EfBe schreef op dinsdag 02 december 2008 @ 18:33:
Cachen van data dat muteert: onzin om dat te doen in een O/R mapper cache (zie:
http://weblogs.asp.net/fb...ch-data-faster_2E00_.aspx

Cachen van data dat niet muteert (readonly data): tuurlijk.

Hier kan ik me alleen maar 100% bij aansluiten. Het is een (voor zover ik weet) vrij bekende best practice. Bill Burke (bekend van Jboss) zegt er b.v. het volgende over:

• Create large cache sizes for frequently accessed (read) entities
• Create smaller caches or have no caches at all for infrequently accessed entities
• Consider not caching frequently updated entities

Met de opmerking erbij dat het hier om common sense rules gaat, maar dat het per situatie kan verschillen wat nu echt het beste is.

Over het algemeen lijkt me echter dat het verwijderen van entity caching uit principiele redenen voor entities die vaak worden gelezen en erg weinig worden geupdate erg dom. Het is een soort van premature optimization maar dan andersom. Tenzij je hebt aangetoond (b.v. met een profiler) dat caching duidelijk geen performance winst levert en meer kost dan het opbrengt, zou ik gewoon standaard de cache van Hibernate altijd gebruiken voor 'infrequently updated entities'.

[voodooless]

EfBe schreef op dinsdag 02 december 2008 @ 18:33:
het punt is alleen: men wil vaak muterende data cachen, terwijl dat nauwelijks effect heeft: immers, je moet toch de complete set ophalen tenzij je single, PK based entities op gaat halen, alleen dan kun je met een cache sneller werken (maar dat is ook maar betrekkelijk, zeker in een webfarm)

Dat ligt eraan. Als je de caches flushed op het moment dat de data wijzigt, en alleen je applicatie die wijzigingen doorvoert, dan kunnen caches wel degelijk effectief zijn. Dat ligt er natuurlijk helemaal aan hoe frequent je de cache flushed. Gebeurt dat niet vaak, kan de cache zeer effectief zijn.

[ Voor 9% gewijzigd door voodooless op 02-12-2008 21:43 ]

[EfBe]

voodooless schreef op dinsdag 02 december 2008 @ 21:41:
[...]
Dat ligt eraan. Als je de caches flushed op het moment dat de data wijzigt, en alleen je applicatie die wijzigingen doorvoert, dan kunnen caches wel degelijk effectief zijn. Dat ligt er natuurlijk helemaal aan hoe frequent je de cache flushed. Gebeurt dat niet vaak, kan de cache zeer effectief zijn.

Dat is niet waar. Ik wil alle klanten uit NL hebben met een order in mei 2007. Die query moet je op de DB runnen, jij kunt niet bepalen of alle matchende klanten in je cache zitten: je kunt dat ALLEEN bepalen wanneer je een in-memory database gebruikt (als je cache), maar dat is de situatie niet: een cache is geen database.

Wanneer de klanten entity data gefetched wordt in entity objects, gaat de engine kijken of die objects er al zijn in de cache: is dat zo, dan wordt de data in de cache bijgewerkt. Is dat niet zo, dan wordt de entity in de cache geplaatst. Dit is _extra_ overhead.

Waar in het plaatje is het 'effectief' om een cache te gebruiken? Het is alleen maar extra overhead.

flowerp schreef op dinsdag 02 december 2008 @ 20:55:
[...]
Hier kan ik me alleen maar 100% bij aansluiten. Het is een (voor zover ik weet) vrij bekende best practice. Bill Burke (bekend van Jboss) zegt er b.v. het volgende over:

• Create large cache sizes for frequently accessed (read) entities
• Create smaller caches or have no caches at all for infrequently accessed entities
• Consider not caching frequently updated entities

Met de opmerking erbij dat het hier om common sense rules gaat, maar dat het per situatie kan verschillen wat nu echt het beste is.

Over het algemeen lijkt me echter dat het verwijderen van entity caching uit principiele redenen voor entities die vaak worden gelezen en erg weinig worden geupdate erg dom. Het is een soort van premature optimization maar dan andersom. Tenzij je hebt aangetoond (b.v. met een profiler) dat caching duidelijk geen performance winst levert en meer kost dan het opbrengt, zou ik gewoon standaard de cache van Hibernate altijd gebruiken voor 'infrequently updated entities'.

Maar dan nog heb je het nadeel dat wanneer een query wordt uitgevoerd die meer dan 1 entity kan matchen, je niet in je cache kunt kijken en dan daarmee de query kunt oplossen, je MOET naar de database.

Wat soms gedaan wordt is een set PK's ophalen die matchen met de query en die lijst tegen de cache aanhouden, de niet aanwezige entities dan ophalen en ook in de cache plaatsen. Op den duur heb je ze allemaal. Nadeel is dat wanneer je bv 10,000 matchende rows hebt, je nogal wat queries moet runnen om ze allemaal in batches op te halen (omdat je per query moet aangeven welke rows met welke id's je wilt)

[ Voor 43% gewijzigd door EfBe op 03-12-2008 09:31 ]

[flowerp]

EfBe schreef op woensdag 03 december 2008 @ 09:25:
Maar dan nog heb je het nadeel dat wanneer een query wordt uitgevoerd die meer dan 1 entity kan matchen, je niet in je cache kunt kijken en dan daarmee de query kunt oplossen, je MOET naar de database.

Natuurlijk, maar ik heb het over 2 eenvoudigere situaties:

1. 1 entity per ID (PK) ophalen.
2. 1 bepaalde 'named query' executen.

Mijn interesse in caching is voornamelijk voor punt 1. In 1 van mijn (web) applicaties heb ik b.v. een 'user' en deze user heeft 'preferences'. Deze preferences heb ik op elke pagina nodig. De standaard oplossing in een web app is om dit object dan in de web session op te slaan, maar tot deze session heb je niet altijd toegang (b.v. als je in een aparte job dingen processed).

Door de preferences entity cacheable te maken bereik ik het zelfde als dat ik het handmatig zou opslaan in die session, alleen op een veel elegantere en universelere manier. Mocht mijn applicatie op meerdere nodes draaien, dan kan ik mijn cache ook op meerdere nodes laten draaien (ik gebruik Jboss Cache en die biedt al clustering support).

Punt 2 cached (in Hibernate) een gehele resultset voor een bekende query. Laten we zeggen "get all customers from before 2007". Als ik exact deze query nu nogmaals draai, kan het direct uit de cache gehaalt worden. Hibernate houdt zelf bij of het result van de query nog geldig is. Simpelweg, als 1 van de tabellen waarop de query gebasseerd is een verandering ondergaat wordt de query invalid. Ik weet niet of Hibernate tegenwoordig iets meer fine grained kan worden dan "een bewerking op een tabel", maar dat is zeker het minumum.

Dat betekent dus dat deze 2de vorm van caching beperkt nut heeft. Je kunt het alleen gebruiken voor exact die query die is gecached met exact die parameters die werden gebruikt. Elke andere query die ook maar iets afwijkt wordt zeker niet op de cache uitgevoerd, maar noodzaakt een roundtrip naar de DB.

Je kunt er in je eigen code voor kiezen trouwens of een invalidated resultset nog gebruikt mag worden of niet. Zo toon ik b.v. in een applicatie de laatste 1000 experimenten die gebruikers uitgevoerd hebben op een index page. Het result van deze query mag een half uur oud zijn (staat ook onder de tabel die ik laat zien).

[EfBe]

@ flowerp: mee eens. Java heeft een voordeel t.o.v. .net in deze dat je cross-server toch object awareness kunt hebben en je cache dus gemakkelijker distributed kan maken zonder er een networked server ervan te hoeven maken (wat caching eigenlijk teniet doet).

het door jouw aangedragen voorbeeld kan overigens nog efficienter gedaan worden: cachen van processed output: je cacht dan niet de query results op een lager niveau maar de output van een webpage of deel van een webpage zodat je bij meerdere requests van dezelfde page dus eigenlijk sneller bent dan dat je eerst helemaal naar de onderste laag moet voor een cached query result.(wellicht minder makkelijk in het bouwen van de applicatie, althans geen idee of het makkelijk te regelen is in java)

[ Voor 50% gewijzigd door EfBe op 03-12-2008 11:38 ]

[flowerp]

EfBe schreef op woensdag 03 december 2008 @ 11:36:
het door jouw aangedragen voorbeeld kan overigens nog efficienter gedaan worden: cachen van processed output:

Een beetje offtopic voor deze thread, maar ja, dat doen we ook op diverse plekken. Voor eenvoudige JSP pagina's biedt de cache OSCache hier tags voor aan. Dan zet je gewoon <x:oscache> </x:oscache> om je content heen (die ook weer tags of zelfs code kan bevatten) en de gehele processed output wordt dan bij de 2de request uit de cache gehaald. Je kunt er ook timing parameters en nog wat andere dingen bij opgeven. Erg eenvoudig, maar toch handig.

p.s.

Over .Net. Oracle Coherence wordt daar wel geschikt voor gemaakt (was eerst alleen puur Java). Zie deze link: http://www.theserverside.com/news/thread.tss?thread_id=51421. Hoewel Coherence wat meer is dan alleen een eenvoudige distributed cache, kan het nagenoeg alles was Jboss Cache ook kan, iniedergeval van horen zeggen (heb er zelf geen ervaring mee)

[ Voor 21% gewijzigd door flowerp op 03-12-2008 13:22 ]

[latka]

Hydra schreef op dinsdag 02 december 2008 @ 16:27:
[...]
Het is wat anders als de cache gebruikt wordt om lui te kunnen ontwikkelen.

Tada, de spijker op de kop. Ik houd van zwart/wit stellingen vandaar mijn opmerking dat je niet moet cachen. In meer dan 80% van de gevallen wordt het gebruikt om te maskeren dat men op een brakke mannier met de database babbelt en er eigenlijk niet zoveel van snapt. Dit is vragen om scaleability problemen als je het alleen met een cache goed kunt krijgen. Er zijn voldoende scenario's waar caching wel zinnig is (read-only entities bijvoorbeeld), maar gewoon maar de cache aanzetten concluderen dat het nu wel snel genoeg is en dan naar productie gaan gebeurt gewoon erg vaak. Vandaar mijn aversie tegen 2nd level caches en mensen die roepen dat het moet (ook in development) te betitelen als noobs

[flowerp]

latka schreef op donderdag 11 december 2008 @ 00:09:
[...]

Tada, de spijker op de kop. Ik houd van zwart/wit stellingen vandaar mijn opmerking dat je niet moet cachen. In meer dan 80% van de gevallen wordt het gebruikt om te maskeren dat men op een brakke mannier met de database babbelt en er eigenlijk niet zoveel van snapt.

Misschien, maar dat maakt niet het concept 'cache' overbodig. Dat noobs het misbruiken, betekent niet dat het in de hande van de profesionele developer maar meteen als 'waardeloos' bestempelt moet worden. Het raakt een beetje aan je server van zo min mogelijk geheugen voorzien 'omdat meer geheugen in je machine stoppen iets is wat vaak gedaan wordt door noobs om memory leaks te verhullen'.

Moet je dan een beetje je 'pro'-mentaliteit gaan bewijzen en je server express met maximaal 256MB gaan uitrusten, terwijl dat geen enkel voordeel biedt en 4GB memory maar enkele tientjes kost? (stond laatst een leuk artikel over op thedailywtf)

[voodooless]

EfBe schreef op woensdag 03 december 2008 @ 09:25:
Dat is niet waar. Ik wil alle klanten uit NL hebben met een order in mei 2007. Die query moet je op de DB runnen, jij kunt niet bepalen of alle matchende klanten in je cache zitten: je kunt dat ALLEEN bepalen wanneer je een in-memory database gebruikt (als je cache), maar dat is de situatie niet: een cache is geen database.

Wanneer de klanten entity data gefetched wordt in entity objects, gaat de engine kijken of die objects er al zijn in de cache: is dat zo, dan wordt de data in de cache bijgewerkt. Is dat niet zo, dan wordt de entity in de cache geplaatst. Dit is _extra_ overhead.

Waar in het plaatje is het 'effectief' om een cache te gebruiken? Het is alleen maar extra overhead.

Zoals ik dus al eerder zei: je moet weten wat je cached en wat de gevolgen zijn. Ik heb nooit gezegd dat je zomaar willekeurig alles moet cachen. Voor veel toepassingen is het niet zo boeiend dat je pas enkele minuten later weet dat de database is bijgewerkt. Het is natuurlijk heel makkelijk om een scenario te verzinnen waar cache niet handig is, dat wil echter niet zetten dat het niet in ALLE situaties onhandig is.

Dus nogmaals: just handle with care!

Ik zou er trouwens ook voor kiezen om caches wat dichter tegen de webapp aan te schrijven. Dan ben je flexibeler en kun je caches ook scopen als dat nodig zou zijn.

[ Voor 26% gewijzigd door voodooless op 11-12-2008 06:49 ]