Wat is opslaan in cache?

Opslaan in cache is het opslaan van sleutel-waardedata in tijdelijk geheugen (zoals een niet-relationele NoSQL-database (NoSQL) database) zodat apps het sneller kunnen ophalen dan uit traditionele opslag. In cloudopslagarchitecturen, waar aanvragen vaak over netwerken heen gaan en gedeelde services raken, kan opslaan in cache helpen om responstijden laag te houden en herhalend werk te verminderen.

De meeste systemen houden een duurzame 'source of truth' aan (een database) voor volledige datasets en bewaren daarnaast een cache voor tijdelijke subsets die vaak worden gelezen. Wanneer er een aanvraag binnenkomt, controleert de app eerst de cache; als de gegevens daar staan, worden ze snel geretourneerd zonder de back-end opnieuw te raadplegen. Ontwikkelaars slaan ook verwerkte gegevens op in de cache en hergebruiken deze om aanvragen sneller te verwerken dan standaardquery's naar relationele databases, SQL-databases of open-source PostgreSQL-databases.

1. Sla op in de cache wat je vaak leest

Goede kandidaten zijn gegevens die herhaaldelijk worden gelezen en gegevens die niet vaak veranderen (bijvoorbeeld product- en prijsinformatie of gedeelde statische resources die duur zijn om op te bouwen).

2. Sla resultaten van herhaald werk op in de cache

Als een bewerking gegevens transformeert of een ingewikkelde berekening uitvoert, kan het opslaan in cache van het resultaat herberekening voor volgende aanvragen voorkomen.

3. Gebruik cachelagen wanneer dat nodig is

Ontwikkelaars gebruiken caches met meerdere niveaus ('cachelagen') om verschillende typen gegevens op te slaan in aparte caches, op basis van de vraag. Door een of meer cachelagen toe te voegen, kun je de doorvoer en latentie in een datalaag verbeteren.

4. Houd de sessiestatus dichtbij voor responsieve apps

In-memory-opslag wordt vaak gebruikt om grote hoeveelheden sessiegegevens tijdelijk op te slaan, zoals gebruikersinvoer, winkelwagenitems of personalisatievoorkeuren. Voor stateful apps slaan teams ook sessiestatus op in de cache, zodat de app stateless kan zijn.

Opslaan in cache kan de prestaties op een paar concrete manieren verbeteren:

• Gegevens lezen uit een in-memory cache is sneller dan gegevens ophalen uit een op schijf gebaseerde opslag.
• Minder query's kunnen de belasting verlagen en de noodzaak beperken om de database-infrastructuur op te schalen, wat ook kosten kan verlagen.
• Cachelagen kunnen doorvoer en latentie verbeteren, en in-memory caches kunnen helpen om latentie tijdens pieken in gebruik te beperken.
• Een cache-exemplaar kan miljoenen aanvragen per seconde verwerken en biedt daarmee een uitvoer die veel databases niet kunnen evenaren.

In veel cloudontwerpen staat een cache naast een primaire gegevensopslag (zoals een database). De primaire opslag houdt de volledige, duurzame dataset op de cloudserver, terwijl de cache een kleinere, tijdelijke subset bewaart die sneller te lezen is.

Een veelgebruikte configuratie is een zelfstandige cachelaag, of een cache die in de app- of databaselaag zit, gekozen op basis van waar je snelle reads nodig hebt.

Sommige systemen gebruiken opslaan in cache met meerdere niveaus ('cachelagen'), zodat verschillende soorten gegevens op basis van de vraag in verschillende caches staan. Door een of meer cachelagen toe te voegen, kun je de doorvoer en latentie voor de datalaag verbeteren en de totale kosten verlagen door de belasting van de back-end te verminderen.

Teams cachen meestal gegevens die in een paar categorieën vallen:

• Gegevens die vaak worden gelezen (vooral als ze niet vaak veranderen), zoals product- of prijsinformatie, en gedeelde statische resources die duur zijn om op te bouwen.
• Herhaalde berekeningen, waarbij een bewerking gegevens transformeert of een ingewikkelde berekening uitvoert - door het resultaat op te slaan in cache, hoef je later dezelfde taak niet opnieuw uit te voeren.
• Sessiegegevens voor stateful apps, waarbij het opslaan van sessiestatus in de cache kan helpen om de app-laag stateless te houden.

Er zijn verschillende standaardmanieren waarop apps gegevens lezen uit en schrijven naar een cache. Hier zijn de meest gebruikte patronen en wat ze in de praktijk betekenen.

• Cache-aside: gegevens op aanvraag laden uit een gegevensopslag.
• Read-through: lezen uit de cache, waarbij de cache indien nodig gegevens ophaalt uit de gegevensopslag.
• Write-through: schrijven naar de cache, waarna deze opnieuw synchroon wordt gesynchroniseerd met de gegevensopslag.
• Write-back (write-behind): schrijven naar de cache, waarna deze de gegevens in batches terugschrijft naar de gegevensopslag.
• Write-around: schrijven naar de gegevensopslag en lezen uit de cache; de cache wordt bijgewerkt op aanvraag.

Door cachelagen te gebruiken kun je doorvoer en latentie verbeteren, omdat veelvoorkomende aanvragen uit de cache worden bediend in plaats van steeds opnieuw de back-endopslag te raadplegen. Hierdoor hoeft je database-infrastructuur minder snel te worden opgeschaald, omdat er in eerste instantie al minder aanvragen bij de database terechtkomen.

Voor apps met pieken in gebruik kunnen in-memory caches helpen om latentie te beperken door vaak opgevraagde gegevens dicht bij de plek te houden waar ze worden gebruikt.

Gebruik deze als startpunt als je een werkstroom kiest:

• Geef de voorkeur aan cache-aside als je app zelf kan bepalen wat er wordt opgeslagen en wanneer het wordt vernieuwd.
• Geef de voorkeur aan read-through als je wilt dat de cache het ophalen uit de gegevensopslag afhandelt 'indien nodig'.
• Overweeg write-through of write-back als schrijfgedrag belangrijk is en je een gedefinieerde aanpak wilt voor het opnieuw synchroniseren.

Opslaan in cache verbetert de prestaties van apps, omdat lezen uit een in-memory cache sneller is dan lezen uit een gegevensopslag op schijf. Als er meer aanvragen uit de cache worden bediend, versturen systemen minder queries naar back-enddatabases. Daardoor hoeft je database-infrastructuur mogelijk minder snel te worden opgeschaald en dalen de gerelateerde kosten.

Wat je vaak krijgt van opslaan in cache

• Lagere latentie voor veelvoorkomende leesacties, omdat vaak opgevraagde gegevens uit een snellere laag komen.
• Minder belasting en lagere kosten voor de database, omdat opslaan in cache leidt tot minder databasequeries en minder druk om database-instanties te overprovisioneren.
• Voorspelbaardere doorvoer, omdat een cache een zeer hoog aantal aanvragen kan verwerken in vergelijking met veel databases.
• Soepeler omgaan met verkeerspieken, omdat in-memory caches latentie kunnen beperken tijdens periodes met hoge doorvoer.

Opslaan in cache helpt om herhaald werk te beperken. Gegevens die vaak worden gelezen, of die duur zijn om samen te stellen, kunnen één keer worden opgeslagen en opnieuw worden gebruikt. Als een bewerking een ingewikkelde berekening uitvoert of gegevens omzet, vermindert het opslaan in cache van het resultaat het herhaaldelijk berekenen voor latere aanvragen.

Veelvoorkomende goede kandidaten voor caching

• Gegevens die weinig veranderen, bijvoorbeeld product- en prijsinformatie.
• Gedeelde statische resources die duur zijn om samen te stellen.
• Resultaten van bewerkingen die herhaaldelijk worden berekend.

Websites: snellere pagina's en minder rondes

Veel sites cachen pagina-uitvoer, zoals HTML en clientscripts, zodat de server de gecachte uitvoer kan teruggeven in plaats van de paginacode telkens opnieuw uit te voeren. Opslaan in cache ondersteunt ook webmultimediascenario's via webcaches en netwerkcaching, zoals content delivery networks (CDN's).

Typische toepassingen op websites

• Cache de volledige pagina-uitvoer voor terugkerende weergaven.
• Statische assets opslaan in cache via netwerk- of CDN-caching.

Apps en API's: snellere leesbewerkingen voor gedeelde data

Apps slaan vaak tijdelijke subsets van gegevens op in een cache voor snelle ophaalacties, terwijl de primaire database de complete duurzame dataset bewaart. Het opslaan in cache van verwerkte gegevens en deze opnieuw gebruiken, kan aanvragen sneller bedienen dan standaarddatabasequeries.

Veelvoorkomende app-patronen

• Cache referentiegegevens die vaak worden gelezen, zoals prijzen, om herhaalde databasecalls te verminderen.
• Cache berekende resultaten om herhaling van duur werk te voorkomen.

Servers en services: Leesbewerkingen opschalen en pieken afvlakken

Teams voegen vaak een of meer cachelagen toe om doorvoer en latentie te verbeteren, veelvoorkomende queries uit de cache te bedienen en de databasebelasting te verminderen. In-memory caches kunnen helpen bij gebruikspieken en een stijgende behoefte aan doorvoer, doordat ze latentie beperken tijdens die periodes.

Waar dit het meest helpt

• Eindpunten met veel leesacties waarbij dezelfde sleutels vaak worden opgevraagd.
• Systemen die af en toe pieken in verkeer zien.

Bedrijfsystemen: sessiestatus en gedeelde operationele gegevens

Opslaan in cache wordt vaak gebruikt om grote hoeveelheden kortstondige sessiegegevens, zoals gebruikersinvoer of personalisatievoorkeuren, op te slaan in een in-memory opslag. Sommige teams slaan sessiestatus ook op in de cache, zodat stateful apps de toepassingslaag stateless kunnen houden. Voor operationele systemen zijn gegevens die weinig veranderen, zoals product- en prijsinformatie, een veelvoorkomend doel van opslaan in cache.

Voorbeelden die je kunt koppelen aan zakelijke workloads

• Sessiegegevens voor web- en mobiele apps (kortstondig, grote hoeveelheid).
• Vaak gelezen operationele referentiegegevens (prijzen, gedeelde resources).

Een browsercache slaat kopieën van statische resources op het apparaat van een gebruiker op, zodat terugkerende bezoeken die bestanden opnieuw kunnen gebruiken in plaats van ze opnieuw te downloaden.

Algemene gebruiksvoorbeelden

• Statische site-assets, zoals afbeeldingen, CSS-bestanden en JavaScript-bestanden.
• Minder roundtrips naar de origin-server voor resources die al eerder zijn opgehaald.

Server-side opslaan in cache vindt plaats in de processen die bedrijfsservices op afstand uitvoeren, in plaats van op het apparaat van de eindgebruiker. Server-side caches zijn vaak privé, lokaal voor één app-instantie, of gedeeld, gebruikt door meerdere app-instanties.

Algemene gebruiksvoorbeelden

• Privé in-memory cache binnen één proces voor beperkte hoeveelheden statische gegevens.
• Gedeelde cacheservice zodat meerdere app-instanties dezelfde gecachte waarden lezen en verschillende versies tussen instanties voorkomen.
• Gegevens die vaak worden gelezen maar weinig worden gewijzigd, bijvoorbeeld referentiegegevens voor producten en prijzen.

Een CDN slaat inhoud op in de cache op edge-servers dichter bij eindgebruikers, zodat aanvragen niet steeds terug hoeven naar de origin. In tegenstelling tot een browsercache, die voor één gebruiker is, is een CDN-cache gedeeld. De aanvraag van de ene gebruiker kan content vullen die een andere gebruiker later ontvangt.

Algemene gebruiksvoorbeelden

• Gedeelde levering van inhoud die in de cache kan worden opgeslagen vanaf edge-locaties om aanvragen naar de oorsprong te verminderen.
• Statische resources die baat hebben bij servering dicht bij gebruikers, dezelfde soort assets die browsers in de cache opslaan, maar dan gedeeld tussen gebruikers.

Opslaan in cache is niet alleen een cloud-computing-patroon, hardware- en geheugenniveaus gebruiken het ook.

CPU-cache is een klein, snel geheugengebied dicht bij, of op, de processor dat kopieën opslaat van vaak gebruikte gegevens en instructies om de wachttijd op het hoofdgeheugen te verkorten.

Geheugen (in-memory) cache is het eenvoudigste type softwarecache: een in-memory opslag in de adresruimte van één proces, waar dat proces direct toegang toe heeft.

Algemene gebruiksvoorbeelden

• CPU-cache: herhaalde toegang tot dezelfde instructies/data zonder vaak naar het hoofdgeheugen te gaan.
• In-memory cache: snelle leesacties van beperkte hoeveelheden relatief statische gegevens binnen één actieve service.

Een gedistribueerde cache strekt zich uit over meerdere servers, zodat de cache kan groeien en de transactionele capaciteit verder reikt dan één machine. Veel gedeelde cacheservices gebruiken een cluster van servers en verdelen in de cache opgeslagen gegevens over het cluster; de cache opschalen kan zo eenvoudig zijn als meer servers toevoegen. Sommige gedistribueerde ontwerpen gebruiken ook gelaagde caches, zodat een miss in één laag ophaalt bij een upstream provider en het resultaat daarna lokaal opslaat voor de volgende aanvraag.

Algemene gebruiksvoorbeelden

• Een gedeelde cachelaag voor meerdere app-exemplaren en machines.
• Workloads die meer cachecapaciteit en doorvoer nodig hebben dan één host kan leveren.
• Gelaagde cacheopstellingen waarbij misses ophalen bij upstream en daarna een lokale kopie bewaren voor volgende aanvragen.

Opslaan in cache houdt vaak geraadpleegde gegevens dichter bij waar je ze gebruikt, wat de responstijden kan verbeteren en een systeem kan helpen meer gelijktijdige aanvragen af te handelen. Het kan ook de belasting op de oorspronkelijke gegevensopslag verminderen, bijvoorbeeld wanneer een database maar een beperkt aantal verbindingen heeft.

In gedistribueerde toepassingen gebeurt opslaan in cache vaak op meer dan één plek, aan clientzijde (zoals in een browser) en aan serverzijde (in een applicatie of gedeelde cacheservice).

Begin klein en richt je op de gegevens die je het duidelijkste voordeel opleveren:

• Gegevens die veel worden gelezen, langzaam op te halen zijn en weinig veranderen (bijvoorbeeld referentiegegevens) opslaan in de cache.
• Bepaal wanneer data de cache in gaat:
  • Op aanvraag na de eerste aanvraag, zodat je alleen opslaat wat echt gebruikt wordt.
  • Vul bij het starten alvast enkele items vooraf in (seed) als je weet dat ze vroeg worden opgevraagd - houd daarbij de startbelasting op de oorspronkelijke opslag in de gaten.
• Kies een patroon dat je kunt beheren. Het cache-aside-patroon is gebruikelijk, en de richtlijnen ervan laten zien hoe vervaldatum, verwijdering en consistentie de resultaten beïnvloeden.

Een cache bevat meestal kopieën van gegevens uit een primaire opslag, dus versheid verdient aandacht:

• Gebruik vervalbeleid om te beperken hoe lang gegevens in de cache kunnen blijven voordat ze worden vernieuwd.
• Let op het verwijderingsgedrag wanneer caches vol raken (veel systemen verwijderen standaard de minst recent gebruikte items).
• Beschouw de cache niet als de enige plek voor kritieke gegevens. Houd de bron van waarheid in permanente opslag, zodat het systeem kan doorgaan als de cache niet beschikbaar is.
• Plan een fallback-route naar de oorspronkelijke gegevensopslag als de cache niet bereikbaar is en vul de cache opnieuw terwijl er leesacties plaatsvinden.

Opslaan in cache is een belangrijk bouwblok voor moderne systemen, omdat het in veel architecturen past, van losse services tot gedistribueerde apps en edge-delivery. Voor een beheerde, in-memory cache cloudprovider kun je Azure verkennen.