Wat is opslaan in cache?
Ontwikkelaars en IT-professionals gebruiken caching om sleutelwaardegegevens sneller en met minder inspanning in het tijdelijke geheugen op te slaan en te openen dan gegevens die zijn opgeslagen in conventionele gegevensopslag. Caches zijn handig in meerdere scenario's met meerdere technologieën, zoals computercaching met RAM (Random Access Memory), netwerkcaching in een netwerk voor contentlevering, een webcache voor multimediagegevens op het web of een cloudcache om cloud-apps toleranter te maken. Ontwikkelaars ontwerpen vaak toepassingen om verwerkte gegevens in de cache op te slaan en gebruiken deze vervolgens om aanvragen sneller te verwerken dan in standaarddatabasequery's.
U kunt caching gebruiken om de databasekosten te verlagen, een hogere doorvoer en lagere latentie te leveren dan de meeste databases kunnen bieden en de prestaties van cloud- en webtoepassingen te verbeteren.
Hoe werkt opslaan in cache voor databases?
Ontwikkelaars kunnen een primaire database aanvullen met een databasecache, die ze in de database of applicatie kunnen plaatsen, of als standalone laag kunnen opzetten. Hoewel ze doorgaans vertrouwen op een conventionele database om grote, duurzame, complete datasets op te slaan, gebruiken ze een cache om tijdelijke subsets van data op te slaan zodat ze snel kunnen worden opgehaald.
U kunt caching gebruiken met alle typen gegevensarchieven, waaronder NoSQL-databases en relationele databases zoals SQL Server, MySQL of MamiDB. Caching werkt ook goed met veel specifieke gegevensplatforms, zoals Azure Database for PostgreSQL, Azure SQL Database of Azure SQL Managed Instance. We raden u aan te onderzoeken welk type gegevensarchief het beste aan uw vereisten voldoet voordat u begint met het configureren van een gegevensarchitectuur. U wilt bijvoorbeeld begrijpen wat PostgreSQL is voordat u deze gebruikt om relationele en ongestructureerde gegevensarchieven te combineren.
Wat zijn de voordelen van cachelagen en wat is Redis?
Ontwikkelaars gebruiken caches met meerdere niveaus die cachelagen worden genoemd om verschillende typen gegevens op te slaan in afzonderlijke caches op basis van de vraag. Door een of meerdere cachelagen toe te voegen, kunt u de doorvoer- en latentieprestaties van een gegevenslaag aanzienlijk verbeteren.
Redis is een populaire open source in-memory gegevensstructuur die wordt gebruikt om hoogwaardige cachelagen en andere gegevensarchieven te bouwen. Een recent onderzoek toonde aan dat het toevoegen van Azure Cache for Redis aan een voorbeeldtoepassing de gegevensdoorvoer met meer dan 800 procent verhoogde en de latentieprestaties met meer dan 1000 procent verbeterde1.
Caches kunnen ook de total cost of ownership (TCO) voor een gegevenslaag verminderen. Door caches te gebruiken om de meest voorkomende query's te verwerken en de databasebelasting te verminderen, kunt u de behoefte aan overinrichting van database-exemplaren verminderen, wat resulteert in aanzienlijke kostenbesparingen en lagere TCO.
Typen caching
Uw cachingstrategie hangt af van hoe uw toepassing gegevens leest en schrijft. Is uw applicatie schrijfintensief of worden gegevens eenmalig geschreven en regelmatig gelezen? Zijn de gegevens die worden geretourneerd altijd uniek? Verschillende patronen voor gegevenstoegang hebben invloed op hoe u een cache configureert. Veelvoorkomende caching-typen zijn cache-aside, read-through/write-through en write-behind/write-back.
Cache-aside
Voor toepassingen met workloads met veel leesbewerkingen gebruiken ontwikkelaars vaak een programmeerpatroon naast de cache, of side-cache. Ze plaatsen de side-cache buiten de toepassing, die vervolgens verbinding kan maken met de cache om gegevens op te halen of rechtstreeks met de database als de gegevens zich niet in de cache bevinden. Als de toepassing de gegevens ophaalt, kopieert het deze naar de cache voor toekomstige query's.
U kunt een side-cache gebruiken om de prestaties van toepassingen te verbeteren, consistentie tussen de cache en het gegevensarchief te behouden en ervoor te zorgen dat gegevens in de cache niet verouderd raken.
Lees-/schrijfcache
Read-through-caches houden zichzelf up-to-date, terwijl bij write-through caching de applicatie gegevens naar de cache en vervolgens naar de database schrijft. Beide caches zijn in lijn met de database en de toepassing behandelt ze als de belangrijkste gegevensopslag.
Read-through-caches helpen toepassingen te vereenvoudigen waarbij dezelfde gegevens steeds opnieuw worden opgevraagd, maar de cache zelf is complexer, terwijl het tweestaps-schrijfproces latentie kan veroorzaken. Ontwikkelaars combineren de twee om te zorgen voor gegevensconsistentie tussen de cache en de database, de latentie van de cache door schrijven te verminderen en het gemakkelijker te maken om de leescache bij te werken.
Met caching van lees-/schrijfbewerkingen kunnen ontwikkelaars toepassingscode vereenvoudigen, de schaalbaarheid van de cache vergroten en de databasebelasting minimaliseren.
Cache voor write-behind/write-back
In dit scenario schrijft de toepassing gegevens naar de cache, die onmiddellijk wordt bevestigd. Vervolgens schrijft de cache zelf de gegevens terug naar de database op de achtergrond. Write-behind-caches, ook wel write-back-caches genoemd, zijn het meest geschikt voor werkbelastingen met veel schrijfbewerkingen en verbeteren de schrijfprestaties omdat de toepassing niet hoeft te wachten tot de schrijfbewerking is voltooid voordat de volgende taak wordt uitgevoerd.
Gedistribueerde cache versus sessiearchief
Mensen verwarren gedistribueerde caches vaak met sessiearchieven, die vergelijkbaar zijn, maar met verschillende vereisten en doeleinden. In plaats van een gedistribueerde cache te gebruiken om een database aan te vullen, implementeren ontwikkelaars sessiearchieven, wat tijdelijke gegevensarchieven op de gebruikerslaag zijn, voor profielen, berichten en andere gebruikersgegevens in sessiegerichte toepassingen zoals web-apps.
Wat is een sessiearchief?
Sessiegerichte toepassingen houden acties bij die gebruikers uitvoeren terwijl ze zijn aangemeld bij de toepassingen. Als u deze gegevens wilt behouden wanneer de gebruiker zich afmeldt, kunt u deze bewaren in een sessiearchief. Dit verbetert het sessiebeheer, verlaagt de kosten en versnelt de prestaties van toepassingen.
Hoe verschilt het gebruik van een sessiearchief van het opslaan in cache van een database?
In een sessiearchief worden gegevens niet gedeeld tussen verschillende gebruikers, terwijl bij caching verschillende gebruikers toegang hebben tot dezelfde cache. Ontwikkelaars gebruiken caching om de prestaties van een database of opslagexemplaar te verbeteren, terwijl ze sessiearchieven gebruiken om de prestaties van toepassingen te verbeteren door gegevens naar het geheugenarchief te schrijven, waardoor ze helemaal geen toegang meer hebben tot een database.
Gegevens die naar een sessiearchief worden geschreven, hebben doorgaans een korte levensduur, terwijl gegevens die in de cache zijn opgeslagen met een primaire database meestal veel langer duren. Een sessiearchief vereist replicatie, hoge beschikbaarheid en duurzaamheid van gegevens om ervoor te zorgen dat transactionele gegevens niet verloren gaan en gebruikers betrokken blijven. Als de gegevens in een side-cache verloren gaan, is er echter altijd een kopie van de gegevens in de permanente database.
Voordelen van opslaan in cache
Verbeterde prestaties van toepassingen
Het lezen van gegevens uit een cache in het geheugen verloopt veel sneller dan het openen van gegevens vanuit een schijfgestuurd gegevensarchief. En met snellere toegang tot gegevens wordt de algehele toepassingservaring aanzienlijk verbeterd.
Verminderd databasegebruik en -kosten
Caching leidt tot minder databasequery's, verbetert de prestaties en verlaagt de kosten door de noodzaak om de database-infrastructuur te schalen te beperken en de doorvoerkosten te verlagen.
Schaalbare en voorspelbare prestaties
Een enkele cache-instantie kan miljoenen verzoeken per seconde verwerken en biedt een doorvoer- en schaalbaarheidsniveau dat databases niet kunnen evenaren. Caching biedt ook de flexibiliteit die u nodig hebt, of u nu uw applicaties en datastores uitschaalt of opschaalt. Dan kan uw toepassing veel gebruikers tegelijkertijd toegang geven tot dezelfde bestanden, zonder de belasting van back-enddatabases te vergroten. En als een toepassing vaak pieken in gebruik en hoge doorvoer ervaart, kunnen in-memory caches de latentie verminderen.
Waarvoor wordt caching gebruikt?
Uitvoercaching
Uitvoercaching helpt de prestaties van webpagina's te verbeteren door de volledige broncode op te slaan van pagina's, zoals HTML- en clientscripts die een server naar browsers verzendt voor rendering. Telkens wanneer een gebruiker de pagina bekijkt, cachet de server de uitvoercode in het geheugen van de toepassing. Hiermee kan de toepassing aanvragen uitvoeren zonder paginacode uit te voeren of te communiceren met andere servers.
Gegevenscaching en databasecaching
De snelheid en doorvoer van de database kunnen belangrijke factoren zijn voor de algehele prestaties van de toepassing. Databasecaching wordt gebruikt voor frequente aanroepen naar gegevens die niet vaak veranderen, zoals prijs- of inventarisgegevens. Het helpt websites en toepassingen sneller te laden, terwijl de doorvoer wordt verhoogd en de latentie voor het ophalen van gegevens uit back-enddatabases wordt verlaagd.
Gebruikerssessiegegevens opslaan
Toepassingsgebruikers genereren vaak gegevens die voor korte perioden moeten worden opgeslagen. Een gegevensarchief in het geheugen, zoals Redis, is ideaal voor het efficiënt en betrouwbaar opslaan van grote hoeveelheden sessiegegevens, zoals gebruikersinvoer, winkelwagenvermeldingen of voorkeuren voor persoonlijke instellingen tegen lagere kosten dan opslag of databases.
Berichtenbrokers en architecturen publiceren/abonneren
Cloudtoepassingen moeten vaak gegevens uitwisselen tussen services en ze kunnen caching gebruiken om publicatie-/abonnements- of message broker-architecturen te implementeren die de latentie verminderen en het gegevensbeheer versnellen.
Toepassingen en API's
Net als browsers slaan toepassingen belangrijke bestanden en gegevens op om die informatie snel opnieuw te laden wanneer dat nodig is. API-antwoorden in cache elimineren de vraag of belasting op toepassingsservers en -databases, waardoor snellere reactietijden en betere prestaties worden geleverd.
1Prestatieclaims zijn gebaseerd op gegevens uit een onderzoek dat is uitgevoerd in opdracht van Microsoft en uitgevoerd door GigaOm in oktober 2020. Het onderzoek vergeleek de prestaties van een testtoepassing met een Azure-database met en zonder implementatie van Azure Cache voor Redis als caching-oplossing. Azure SQL Database en Azure Database for PostgreSQL werden gebruikt als het database-element in het onderzoek. Een 2 vCore Gen5 General Purpose-exemplaar van Azure SQL Database en een 2 vCore General Purpose-exemplaar van Azure Database for PostgreSQL werden gebruikt met een 6 gigabyte P1 Premium-exemplaar van Azure voor Redis. Deze resultaten zijn vergeleken met 8, 16, 24 en 32 vCore Gen5 General Purpose-exemplaren van Azure SQL Database en 8, 16, 24 en 32 vCore General Purpose-exemplaren van Azure Database for PostgreSQL zonder Azure Cache for Redis. De benchmarkgegevens zijn afkomstig van de GigaOm Web Application Database Load Test, die een gemeenschappelijke webtoepassing en back-enddatabase simuleert die wordt geblokkeerd door toenemende HTTP-verzoeken. De werkelijke resultaten kunnen variëren op basis van configuratie en regio. Bekijk het volledige onderzoek.
Gratis account
Probeer Azure cloudcomputing-services maximaal 30 dagen gratis uit.
Betalen naar gebruik
Aan de slag met prijzen voor Betalen per gebruik. Er is geen verplichting vooraf—annuleer op elk gewenst moment.
Voeg een flexibele cachelaag toe aan uw toepassing met een volledig beheerde Redis-service. Lees hoe u aan de slag kunt met Azure Cache voor Redis.
Lees over Azure HPC Cache als u flexibele, op bestanden gebaseerde cachebewerkingen wilt uitvoeren voor toepassingen met hoge prestaties.