Trace Id is missing
Naar hoofdinhoud gaan

Wat zijn cachegeheugens?

Ontwikkelaars en IT-medewerkers gebruiken het cachegeheugen om belangrijke gegevens sneller en eenvoudiger in een tijdelijk geheugen op te slaan dan wanneer gegevens in een conventionele gegevensopslag worden opgeslagen. Cachegeheugens zijn nuttig in meerdere scenario's met meerdere technologieën, zoals computercachegeheugens met RAM (Random Access Memory), netwerkcachegeheugens in een netwerk voor contentlevering, een webcache voor webmultimediagegevens of een cloudcache om cloud-apps bestendiger te maken. Ontwikkelaars ontwerpen vaak toepassingen om verwerkte gegevens in de cache op te slaan en deze vervolgens voor een nieuw doeleinde te gebruiken om aanvragen sneller te verwerken dan bij standaarddatabasequery's.

Je kunt cachegeheugens gebruiken om de databasekosten te verlagen, een hogere doorvoer en kortere wachttijd te leveren dan de meeste databases kunnen bieden en de prestaties van cloud- en webtoepassingen te verbeteren.

Hoe worden cachegeheugens gebruikt voor databases?

Ontwikkelaars kunnen een primaire database aanvullen met een databasecache, die ze in de database of toepassing kunnen plaatsen of kunnen instellen als een zelfstandige laag. Hoewel ze doorgaans een conventionele database gebruiken voor het opslaan van grote, duurzame, volledige gegevenssets, gebruiken ze een cachegeheugen voor het opslaan van tijdelijke subsets van gegevens die snel moeten worden opgehaald.

U kunt caching gebruiken met alle typen gegevensarchieven, waaronder NoSQL-databases en relationele databases zoals SQL Server, MySQL of MariaDB. Caching werkt ook goed met veel specifieke gegevensplatformen, zoals Azure Database for PostgreSQLAzure SQL Database, of  Azure SQL Managed Instance. We raden je aan om eerst te onderzoeken welk type gegevensopslag het beste aan je behoeften voldoet voordat je begint met het configureren van een gegevensarchitectuur. Je wilt bijvoorbeeld weten wat PostgreSQL is voordat je deze gebruikt om opslag van relationele en ongestructureerde gegevens te combineren.

De voordelen van cachelagen en wat is Redis eigenlijk?

Ontwikkelaars gebruiken cachegeheugens met meerdere lagen, cachelagen genoemd, om verschillende typen gegevens op te slaan in afzonderlijke cachegeheugens op basis van de vraag. Door een of meer cachelagen toe te voegen, kun je de doorvoer- en wachttijdprestaties van een gegevenslaag aanzienlijk verbeteren.

Redis is een populaire opensource-gegevensstructuur in het geheugen die wordt gebruikt voor het maken van cachelagen en andere gegevensarchieven van hoge kwaliteit. Uit een recent onderzoek is gebleken dat door het toevoegen van Azure Cache voor Redis aan een voorbeeldtoepassing de gegevensdoorvoer met meer dan 800 procent is verhoogd en de wachttijdprestaties met meer dan 1000 procent is verbeterd1.

Cachegeheugens kunnen ook de total cost of ownership (TCO) voor een gegevenslaag verminderen. Door cachegeheugens te gebruiken om de meest voorkomende query's te verwerken en de databasebelasting te verminderen, hoef je niet te veel database-instanties in te richten, wat resulteert in aanzienlijke kostenbesparingen en een lagere TCO.

Typen cachegeheugens

Je cachegeheugenstrategie is afhankelijk van de wijze waarop je toepassingsgegevens leest en schrijft. Worden er in uw toepassing veel schrijfbewerkingen uitgevoerd of worden gegevens eenmaal geschreven en veelvuldig gelezen? Zijn de gegevens die worden geretourneerd altijd uniek? Verschillende patronen voor gegevenstoegang zijn van invloed op de wijze waarop u een cache configureert. Veelvoorkomende cachegeheugentypen zijn zijdelingse cache, read-through/write-through cache en write-behind/write-back cache.

Zijdelingse cache

Voor toepassingen met workloads met zeer veel leesbewerkingen gebruiken ontwikkelaars vaak een programmeerpatroon voor een zijdelingse cache of "zijcache." Ze plaatsen de zijcache buiten de toepassing, die vervolgens verbinding kan maken met de cache om gegevens op te vragen en op te halen of rechtstreeks met de database als de gegevens niet in de cache staan. Wanneer de toepassing de gegevens ophaalt, kopieert de toepassing deze naar de cache voor toekomstige query's.

Je kunt een zijcache gebruiken om de toepassingsprestaties te verbeteren, consistentie tussen de cache en de gegevensopslag te waarborgen en ervoor te zorgen dat gegevens in de cache niet verouderd raken.

Read-through/write-through cache

Read-through caches worden automatisch up-to-date gehouden. Bij write-through cachegeheugens worden door de toepassing gegevens naar de cache en vervolgens naar de database geschreven. Beide caches staan in verbinding met de database en de toepassing behandelt ze als de hoofdgegevensopslag.

Met read-through caches worden toepassingen vereenvoudigd waarvoor steeds dezelfde gegevens worden aangevraagd, maar de cache zelf is complexer. Het write-through proces dat uit twee stappen bestaat, kan vertraging veroorzaken. Ontwikkelaars koppelen de twee om voor gegevensconsistentie tussen de cache en de database te zorgen, vertraging van de write-through cache te verminderen en het eenvoudiger te maken om de read-through cache bij te werken.

Met read-through/write-through cachegeheugens kunnen ontwikkelaars toepassingscode vereenvoudigen, de schaalbaarheid van de cache vergroten en de databasebelasting beperken tot een minimum.

Write-behind/write-back cache

In dit scenario schrijft de toepassing gegevens naar de cache, wat onmiddellijk wordt bevestigd, en vervolgens schrijft de cache de gegevens weer naar de database op de achtergrond. Write-behind caches, ook wel write-back caches genoemd, zijn zeer geschikt voor workloads met veel schrijfbewerkingen en zorgen voor betere schrijfprestaties omdat de toepassing niet hoeft te wachten tot de schrijfbewerking is voltooid voordat aan de volgende taak kan worden begonnen.

Gedistribueerde cache versus sessieopslag

Mensen verwarren vaak gedistribueerde cachegeheugens met sessieopslag. Deze zijn vergelijkbaar, maar hebben verschillende vereisten en doeleinden. In plaats van een gedistribueerde cache te gebruiken als aanvulling op een database, implementeren ontwikkelaars sessieopslag, die tijdelijke gegevensopslag op de gebruikerslaag is, voor profielen, berichten en andere gebruikersgegevens in toepassingen die gebruikmaken van sessies zoals web-apps.

Wat is sessieopslag?

Toepassingen die gebruikmaken van sessies houden de acties bij die gebruikers uitvoeren terwijl ze zijn aangemeld bij de toepassingen. Als je die gegevens wilt behouden wanneer de gebruiker zich afmeldt, kun je deze bewaren in een sessieopslag, waardoor het sessiebeheer wordt verbeterd, de kosten worden verlaagd en voor snellere toepassingsprestaties wordt gezorgd.

Hoe verschilt het gebruik van sessieopslag met het opslaan van een database in het cachegeheugen?

In een sessieopslag worden gegevens niet gedeeld tussen verschillende gebruikers, terwijl met cachegeheugens verschillende gebruikers toegang hebben tot dezelfde cache. Ontwikkelaars gebruiken cachegeheugens om de prestaties van een database of opslaginstantie te verbeteren. Ze gebruiken daarentegen een sessieopslag om de prestaties van toepassingen te verbeteren door gegevens naar de opslag in het geheugen te schrijven, waardoor er helemaal geen toegang hoeft te worden verkregen tot een database.

Gegevens die naar een sessieopslag worden geschreven, hebben doorgaans een korte levensduur, terwijl gegevens die zijn opgeslagen in het cachegeheugen met een primaire database meestal een langere levensduur hebben. Voor een sessieopslag zijn replicatie, hoge beschikbaarheid en duurzaamheid van gegevens vereist om ervoor te zorgen dat transactionele gegevens niet verloren gaan en gebruikers betrokken blijven. Als de gegevens in een zijdelingse cache echter verloren gaan, is er altijd een kopie van deze gegevens beschikbaar in de permanente database.

Voordelen van cachegeheugens

Hogere prestaties van toepassingen

Het lezen van gegevens uit een cache in het geheugen gaat veel sneller dan het lezen van gegevens uit een gegevensopslag op schijf. En met snellere toegang tot gegevens wordt de algehele toepassingservaring aanzienlijk verbeterd.

Minder databasegebruik en lagere kosten

Het gebruik van cachegeheugens leidt tot minder databasequery's, waardoor de prestaties worden verbeterd en de kosten worden verminderd doordat de database-infrastructuur niet zo nodig hoeft te worden opgeschaald en de doorvoerkosten worden verminderd.

Schaalbare en voorspelbare prestaties

Eén cache-instantie kan miljoenen aanvragen per seconde verwerken en biedt zo een doorvoer- en schaalbaarheidsniveau die niet te evenaren zijn door databases. Het gebruik van cachegeheugens biedt ook de flexibiliteit die u nodig hebt, ongeacht of u uw toepassingen en gegevensopslag uitbreidt of opschaalt. Vervolgens kan uw toepassingen veel gebruikers tegelijkertijd toegang verlenen tot dezelfde bestanden, zonder dat de belasting van de back-enddatabases wordt verhoogd. En als een toepassing vaak pieken in het gebruik en een hoge doorvoer heeft, kunnen caches in het geheugen zorgen voor een kortere wachttijd.

Waarvoor worden cachegeheugens gebruikt?

Uitvoer in de cache opslaan

Door het opslaan van de uitvoer in de cache kunnen de prestaties voor webpagina's worden verhoogd door het opslaan van de volledige broncode van pagina's zoals HTML en clientscripts die een server verzendt naar browsers voor het weergeven van de pagina's. Elke keer dat een gebruiker de pagina bekijkt, slaat de server de uitvoercode op in de cache in het geheugen van de toepassing. Hierdoor kan de toepassing aanvragen verwerken zonder dat er paginacode hoeft te worden uitgevoerd of hoeft te worden gecommuniceerd met andere servers.

Gegevens en databases opslaan in de cache

Databasesnelheid en -doorvoer zijn kernfactoren in de algehele toepassingsprestaties. Het opslaan van databasegegevens in de cache wordt gebruikt voor frequente oproepen van gegevens die niet vaak veranderen, zoals prijzen of voorraadgegevens. Websites en toepassingen kunnen op deze manier sneller worden geladen, terwijl de doorvoer wordt verhoogd en de wachttijd voor het ophalen van gegevens uit back-enddatabases wordt verkort.

Gebruikerssessiegegevens opslaan

Gebruikers van toepassingen genereren vaak gegevens die voor korte tijd moeten worden opgeslagen. Een gegevensopslag in het geheugen, zoals Redis, is een perfecte methode voor het efficiënt en betrouwbaar opslaan van grote volumes sessiegegevens, zoals gebruikersinvoer, winkelwagenvermeldingen of persoonlijke voorkeuren tegen een lagere prijs dan opslag of databases.

Een architectuur voor berichtenuitwisseling en voor publiceren en abonneren

Cloudtoepassingen moeten vaak gegevens uitwisselen tussen services en ze kunnen cachegeheugens gebruiken om een architectuur voor berichtenuitwisseling of voor publiceren en abonneren te implementeren die de wachttijd verkort en zorgt voor een sneller gegevensbeheer.

Toepassingen en API's

Toepassingen slaan, net als browsers, belangrijke bestanden en gegevens op om die gegevens snel weer te laden wanneer ze nodig zijn. Met opgeslagen API-reacties wordt de vraag naar of het laden op toepassingsservers en in databases overbodig gemaakt, hetgeen resulteert in snellere reactietijden en betere prestaties.

[1] Prestatieclaims zijn gebaseerd op gegevens van een onderzoek dat GigaOm in oktober 2020 heeft uitgevoerd in opdracht van Microsoft. In dit onderzoek zijn de prestaties van een testtoepassing met een Azure-database vergeleken met en zonder implementatie van Azure Cache voor Redis als cacheoplossing. Azure SQL Database en Azure Database for PostgreSQL zijn gebruikt als het database-element in het onderzoek. Een 2 vCore Gen 5-instantie voor algemeen gebruik van Azure SQL Database en een 2 vCore-instantie voor algemeen gebruik van Azure Database for PostgreSQL zijn gebruikt met een 6 GB P1 Premium-instantie van Azure voor Redis. Deze resultaten zijn vergeleken met 8, 16, 24 en 32 vCore Gen 5-instanties voor algemeen gebruik van Azure SQL Database en 8, 16, 24 en 32 vCore-instanties voor algemeen gebruik van Azure Database for PostgreSQL zonder Azure Cache voor Redis. De benchmarkgegevens waren afkomstig uit de Web Application Database Load Test van GigaOm die een gangbare webtoepassing met back-enddatabase simuleert die wordt onderworpen aan een toenemend aantal HTTP-aanvragen. De werkelijke resultaten kunnen afwijken afhankelijk van de configuratie en regio. Bekijk het volledige onderzoekBekijk het volledige onderzoek.

Gratis account

Probeer cloud-computingservices van Azure 30 dagen gratis uit.

Betalen naar gebruik

Ga aan de slag met betalen per gebruik. Je zit nergens aan vast: je kunt op elk gewenst moment opzeggen.

Voeg een lichtvoetige cachegeheugenlaag toe aan je toepassing met een volledig beheerde Redis-service. Ontdek hoe je aan de slag kunt gaan met Azure Cache voor Redis.

Lees meer over Azure HPC Cache als je flexibele cachegeheugens op basis van bestanden wilt gebruiken voor toepassingen met hoge prestaties.