Hopp over navigasjon

Hva er hurtigbufring?

Utviklere og IT-eksperter bruker hurtigbufring til å lagre og få tilgang til nøkkelverdidata i midlertidig minne raskere og med mindre innsats enn data som er lagret i konvensjonell datalagring. Hurtigbufre er nyttige i flere scenarier med flere teknologier, for eksempel datamaskinhurtigbufring med RAM (Random Access Memory), nettverkshurtigbufring på et innholdsleveringsnettverk, en nettbuffer for multimediedata eller en skyhurtigbuffer for å gjøre skyapper mer elastiske. Utviklere utformer ofte programmer for hurtigbufring av behandlede data og bruker dem deretter på nytt for å behandle forespørsler raskere enn i standard databasespørringer.

Du kan bruke hurtigbufring til å redusere databasekostnader, levere høyere gjennomstrømming og lavere ventetid enn de fleste databaser kan tilby, og øke ytelsen til sky- og nettprogrammer.

Hvordan fungerer hurtigbufring for databaser?

Utviklere kan supplere en primær database med en databasebuffer, som de kan plassere i databasen eller programmet, eller konfigurere som et frittstående lag. Selv om de vanligvis er avhengige av en vanlig database for å lagre store, varige, komplette datasett, bruker de en hurtigbuffer til å lagre midlertidige delsett med data for rask henting.

Du kan bruke hurtigbufring med alle typer datalagre, inkludert NoSQL-databaser samt relasjonsdatabaser som SQL Server, MySQL eller MariaDB. Hurtigbufring fungerer også bra med mange spesifikke dataplattformer, som for eksempel Azure Database for PostgreSQL, Azure SQL Database eller Azure SQL Managed Instance. Vi anbefaler at du undersøker hva slags datalager som oppfyller kravene dine best før du begynner å konfigurere en dataarkitektur. Du bør for eksempel forstå hva PostgreSQL er før du bruker det til å kombinere relasjonelle og ustrukturerte datalagre.

Fordelene med hurtigbufferlag, og hva er Redis egentlig?

Utviklere bruker hurtigbuffere på flere nivåer, kalt hurtigbufferlag, for å lagre ulike typer data i separate hurtigbuffere etter behov. Ved å legge til et hurtigbufferlag eller flere, kan du forbedre gjennomstrømmingen og ventetidsytelsen til et datalag betraktelig.

Redis er en populær datastruktur med åpen kildekode som brukes til å bygge hurtigbufferlag med høy ytelse og andre datalagre. En nylig studie viste at å legge til Azure Cache for Redis til et eksempelprogram økte datagjennomstrømming med over 800 prosent og forbedret ventetidsytelsen med over 1000 prosent1.

Hurtigbuffere kan også redusere de totale eierkostnadene (TCO) for et datalag. Ved å bruke hurtigbuffere til å betjene de vanligste spørringene og redusere databasebelastningen, kan du redusere behovet for å ha unødig mange databaseforekomster, noe som resulterer i betydelige kostnadsbesparelser og lavere totale eierkostnader.

Hurtigbufringstyper

Hurtigbufringsstrategien din avhenger av hvordan programmet leser og skriver data. Skriver programmet mye, eller skrives data én gang og leses ofte? Er dataene som returneres alltid unike? Ulike mønstre for datatilgang vil påvirke hvordan du konfigurerer en hurtigbuffer. Vanlige hurtigbufringstyper inkluderer cache-aside, read-through/write-through og write-behind/write-back.

Cache-aside

For programmer med lese-tunge arbeidsbelastninger bruker utviklere ofte et cache-aside-programmeringsmønster, eller "sidebuffer". De finner sidebufferen utenfor programmet, som deretter kan koble til hurtigbufferen for å spørre etter og hente data, eller direkte til databasen hvis dataene ikke er i hurtigbufferen. Når programmet henter dataene, kopieres de til hurtigbufferen for fremtidige spørringer.

Du kan bruke en sidebuffer (side-cache) til å forbedre programytelsen, opprettholde konsistens mellom hurtigbufferen og datalageret, og hindre at data i hurtigbufferen blir foreldet.

Read-through/write-through cache

Read-through-buffere holder seg selv oppdatert, mens med write-through-buffere skriver programmet data til hurtigbufferen og deretter til databasen. Begge hurtigbufferne er på linje med databasen, og programmet behandler dem som hoveddatalageret.

Read-through-buffere bidrar til å forenkle programmer der de samme dataene er forespurt om og om igjen, men selve hurtigbufferen er mer kompleks, mens prosessen med to trinns write-through kan skape ventetid. Utviklere parer de to for å sikre datakonsistens mellom hurtigbufferen og databasen, redusere hurtigbufferventetid for write-through og gjøre det enklere å oppdatere read-through-bufferen.

Med read-through/write-through-hurtigbufring kan utviklere forenkle programkode, øke hurtigbufferskalerbarheten og minimere databasebelastning.

Write-behind/write-back cache

I dette scenarioet skriver programmet data til hurtigbufferen, som umiddelbart blir bekreftet, og deretter skriver selve hurtigbufferen dataene tilbake til databasen i bakgrunnen. Hurtigbuffere som skrives bak, noen ganger kalt tilbakeskrivingsbuffere, er best for skrivekrevende arbeidsbelastninger, og de forbedrer skriveytelsen fordi programmet ikke trenger å vente på at skrivingen skal fullføres før du går over til neste oppgave.

Distribuert hurtigbuffer kontra øktlager

Folk forveksler ofte distribuerte hurtigbuffere med øktlagre, som ligner, men har ulike krav og formål. I stedet for å bruke en distribuert hurtigbuffer til å supplere en database, implementerer utviklere øktlagre, noe som er midlertidige datalagre på brukernivå for profiler, meldinger og andre brukerdata i øktorienterte programmer som nettapper.

Hva er et øktlager?

Øktorienterte programmer sporer handlinger som brukerne utfører mens de er logget på programmene. Hvis du vil beholde dataene når brukeren logger av, kan du beholde dem i et øktlager, noe som forbedrer øktadministrasjon, reduserer kostnader og gir raskere programytelse.

Hvordan er det å bruke et øktlager forskjellig fra hurtigbufring av en database?

I et øktlager deles ikke data mellom forskjellige brukere, mens ulike brukere kan få tilgang til den samme hurtigbufferen med hurtigbufring. Utviklere bruker hurtigbufring til å forbedre ytelsen til en database eller lagringsforekomst, mens de bruker øktlagre til å øke programytelsen ved å skrive data til minnelageret, noe som eliminerer behovet for å få tilgang til en database i det hele tatt.

Data som er skrevet til et øktlager, er vanligvis kortvarige, mens data som hurtigbufres med en primær database er vanligvis ment å vare mye lenger. Et øktlager krever replikering, høy tilgjengelighet og dataholdbarhet for å sikre at transaksjonsdata ikke går tapt, og at brukerne forblir engasjerte. Hvis dataene i en sidebuffer derimot går tapt, er det alltid en kopi av dem i den permanente databasen.

Fordeler ved hurtigbufring

Forbedret programytelse

Det er mye raskere å lese data fra en minnehurtigbuffer enn å få tilgang til data fra et diskdrevet datalager. Og med raskere tilgang til data blir den generelle programopplevelsen betydelig bedre.

Redusert databasebruk og reduserte kostnader

Hurtigbufring fører til færre databasespørringer, noe som forbedrer ytelsen og reduserer kostnadene ved å begrense behovet for å skalere databaseinfrastruktur og redusere gjennomstrømmingskostnader.

Skalerbar og forutsigbar ytelse

En enkelt bufferforekomst kan håndtere millioner av forespørsler per sekund og tilbyr et nivå av gjennomstrømming og skalerbarhet som databaser ikke kan matche. Hurtigbufring tilbyr også fleksibiliteten du trenger, enten du skalerer ut eller skalerer opp programmene og datalagrene. Da kan programmet gi mange brukere tilgang til de samme filene samtidig, uten å øke belastningen på den bakenforliggende databasen. Og hvis et program ofte opplever topper i bruk og høy gjennomstrømming, kan hurtigbuffere i minnet redusere ventetiden.

Hva brukes hurtigbufring til?

Hurtigbufring av utdata

Hurtigbufring av utdata bidrar til å øke ytelsen på nettsiden ved å lagre den fullstendige kildekode for sider, som for eksempel HTML og klientskript som en server sender til nettlesere for gjengivelse. Hver gang en bruker viser siden, bufrer serveren utdatakoden i programmets minne. Dette gjør det mulig for programmet å behandle forespørsler uten å kjøre sidekode eller kommunisere med andre servere.

Hurtigbufring av data og databasehurtigbufring

Databasehastighet og gjennomstrømming kan være viktige faktorer i den generelle programytelsen. Databasehurtigbufring brukes til hyppige kall til data som ikke endres ofte, for eksempel priser eller lagerdata. Det hjelper nettsteder og programmer med å laste raskere, samtidig som du øker gjennomstrømmingen og reduserer ventetiden for datahenting fra den bakenforliggende databasen.

Lagre brukerøktdata

Programbrukere genererer ofte data som må lagres i korte perioder. Et minneinternt datalager som Redis er perfekt for effektiv lagring og pålitelig lagring av store mengder øktdata som brukerinndata, handlekurvoppføringer eller tilpassingsinnstillinger til en lavere pris enn lagring eller databaser.

Meldingsmeglere og arkitekturer for publisering/abonnement

Skyprogrammer trenger ofte å utveksle data mellom tjenester, og de kan bruke hurtigbufring til å implementere arkitekturer for publisering/abonnering eller meldingsmegler som reduserer ventetiden og akselererer dataadministrasjonen.

Programmer og API-er

I likhet med nettlesere lagrer programmer viktige filer og data for raskt å laste inn denne informasjonen på nytt ved behov. Bufrede API-svar eliminerer etterspørselen eller belastningen på programservere og databaser, noe som gir raskere responstider og bedre ytelse.

1 Utsagn om ytelse er basert på data fra en undersøkelse som ble bestilt av Microsoft og utført av GigaOm i oktober 2020. Studien sammenlignet ytelsen til et testprogram ved hjelp av en Azure-database med og uten å implementere Azure Cache for Redis som en hurtigbufringsløsning. Azure SQL Database og Azure Database for PostgreSQL ble brukt som databaseelement i studien. En 2 vCore Gen5 generell bruk-forekomst av Azure SQL Database og en 2 vCore generell bruk-forekomst av Azure Database for PostgreSQL ble brukt med en P1 Premium-forekomst på 6 gigabyte i Azure for Redis. Disse resultatene ble sammenlignet med 8, 16, 24 og 32 vCore Gen5 generell bruk-forekomster av Azure SQL Database og 8, 16, 24 og 32 vCore generell bruk-forekomster av Azure Database for PostgreSQL uten Azure Cache for Redis. Ytelsestestdataene hentes fra GigaOm Web Application Database Load Test, som simulerer et vanlig nettprogram og en back-end-database som blir bombadert med økende HTTP-forespørsler. Faktiske resultater kan variere basert på konfigurasjon og område. Se hele studien.

Legg til et raskt hurtigbufringslag i programmet med en totaladministrert Redis-tjeneste: Finn ut hvordan du kommer i gang med Azure Cache for Redis.

Hvis du vil kjøre fleksibel, filbasert hurtigbufring for programmer med høy ytelse, kan du lese om Azure HPC Cache.

Kan vi hjelpe deg?