Trace Id is missing
Gå til hovedinnhold
Azure

Hva er hurtigbufring?

Utviklere og IT-profesjonelle bruker hurtigbufring for å lagre og få tilgang til nøkkelverdidata i midlertidig minne raskere og med mindre innsats enn for lagrede data i konvensjonelt datalager. Bufre er nyttige i flere scenarioer med flere teknologier, for eksempel datamaskinhurtigbufring med RAM (Random Access Memory), nettverkshurtigbufring i et innholdsleveringsnettverk, en nettbuffer for multimediedata eller en skybuffer for å gjøre skyapper mer elastiske. Utviklere utformer ofte programmer for å bufre behandlede data, for så å endre dem for å betjene forespørsler raskere enn i standard databasespørringer.

Du kan bruke hurtigbufring til å redusere databasekostnadene, levere høyere gjennomstrømming og kortere 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 et databasebuffer. Denne kan de plassere i databasen eller programmet, eller konfigurere som et frittstående lag. Mens de vanligvis er avhengige av en konvensjonell database for å lagre store, holdbare, komplette datasett, bruker de en buffer til å lagre midlertidige delsett med data for rask henting.

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

Fordelene med bufferlag – og hva er egentlig Redis?

Utviklere bruker buffere på flere nivåer kalt bufferlag til å lagre forskjellige typer data i separate buffere etter behov. Ved å legge til et eller flere bufferlag, kan du forbedre ytelsen for gjennomstrømming og ventetid for et datalag.

Redis er en populærminneintern datakonstruksjon med åpen kildekode som brukes til å bygge bufferlag med høy ytelse og andre datalager. En nylig studie viste at å legge til Azure Cache for Redis i et eksempelprogram økte datagjennomstrømmingen med over 800 prosent og forbedret ytelsen for ventetid med over 1000 prosent1.

Buffere kan også redusere de totale eierkostnadene (TCO) for et datalag. Ved å bruke buffere til å betjene de vanligste spørringene og redusere databasebelastningen, kan du redusere behovet for overklargjøring av databaseforekomster, noe som resulterer i betraktelige kostnadsbesparelser og lavere totale eierkostnader.

Typer hurtigbufring

Strategien din for hurtigbufring avhenger av hvordan programmet leser og skriver data. Er programmet ditt tungt, eller blir data skrevet én gang og ofte lest? Er dataene som sendes tilbake alltid unike? Ulike datatilgangsmønstre vil påvirke hvordan du konfigurerer en buffer. Vanlige typer hurtigbufring inkluderer ny innlasting til buffer, gjennomlesing/gjennomskrivning og skrive bak / skrive tilbake.

Ny innlasting til buffer

For programmer med lesetunge arbeidsbelastninger bruker utviklere ofte et programmeringsmønster for ny innlasting til buffer, eller "«sidebuffer»." De finner sidebufferen utenfor programmet, som deretter kan koble til bufferen for å spørre og hente data, eller gjøre dette direkte med databasen hvis dataene ikke er i bufferen. Når programmet henter dataene, kopieres de til bufferen for fremtidige spørringer.

Du kan bruke en sidebuffer til å forbedre programytelsen, opprettholde konsekvensen mellom bufferen og datalageret og forhindre at data i bufferen blir foreldede.

Buffer for gjennomlesing/gjennomskrivning

Buffere for gjennomlesing holder seg oppdatert selv, mens ved hurtigbufring for gjennomlesing skriver programmet data til bufferen og deretter til databasen. Begge bufferne er i tråd med databasen, og programmet behandler dem som hoveddatalageret.

Buffer for gjennomlesing hjelper til med å forenkle programmer der det til stadighet bes om de samme dataene, men selve bufferen er mer komplisert, mens den totrinns prosessen med gjennomskrivning kan skape ventetid. Utviklere kobler de to sammen for å sikre datakonsekvens mellom bufferen og databasen, redusere ventetid for buffer for gjennomskrivning og gjøre det lettere å oppdatere bufferen for gjennomlesing.

Med hurtigbufring for gjennomlesing/gjennomskrivning kan utviklere forenkle programkode, øke skalerbarhet for buffere og minimere belastning av databaser.

Hurtigbuffer for skriving / buffer for å skrive tilbake

I dette scenarioet skriver programmet data til hurtigbufferen som umiddelbart blir bekreftet, og deretter skriver bufferen dataene tilbake til databasen i bakgrunnen. Hurtigbuffere for skriving, noen ganger kjent som buffere for å skrive tilbake, er best for store arbeidsbelastninger. De forbedrer skriveytelsen fordi programmet ikke trenger å vente på at skrivingen er fullført før det går videre til neste oppgave.

Distribuert buffer vs. øktlager

Folk forveksler ofte distribuerte bufre med øktlager, som er like, men med forskjellige krav og formål. I stedet for å bruke en distribuert buffer for å supplere en database, implementerer utviklere øktlager, som er midlertidige datalager i brukerlaget, for profiler, meldinger og andre brukerdata i øktorienterte programmer som nettapper.

Hva er et øktlager?

Øktorienterte programmer sporer handlinger som brukere utfører mens de er logget på programmene. Hvis du vil bevare dataene når brukeren logger av, kan du oppbevare dem i et øktlager. Dette forbedrer øktadministrasjonen, reduserer kostnadene og gir raskere programytelse.

Hvordan er det å bruke et øktlager annerledes enn hurtigbufring i en database?

I et øktlager deles ikke data mellom forskjellige brukere, mens ved hurtigbufring kan forskjellige brukere få tilgang til samme buffer. Utviklere bruker hurtigbufring til å forbedre ytelsen til en database eller lagringsforekomst, mens de bruker øktlager til å øke programytelsen ved å skrive data til minnet. Dette 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 er lagret i en primær database vanligvis er ment å vare lenger. Et øktlager krever replikering, høy tilgjengelighet og holdbarhet for data for å sikre at transaksjonsdata ikke går tapt og brukerne forblir engasjerte. Hvis derimot dataene i en sidebuffer går tapt, er det alltid en kopi av dem i den permanente databasen.

Fordeler ved hurtigbufring

Forbedret programytelse

Å lese data fra en minneintern buffer går mye raskere enn å få tilgang til data fra et diskdrevet datalager. Og med raskere tilgang til data forbedres den samlede programopplevelsen betraktelig.

Lavere databasebruk og -kostnader

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

Skalerbar og forutsigbar ytelse

En enkelt bufferforekomst kan håndtere millioner av forespørsler per sekund, og tilbyr et nivå på gjennomstrømming og skalerbarhet som databaser ikke kan matche. Hurtigbufring tilbyr også den fleksibiliteten du trenger, uansett om du skalerer ut eller skalerer opp programmer og datalager. Programmet kan da la mange brukere få tilgang til de samme filene samtidig, uten å øke belastningen på serverdeldatabaser. Og hvis et program ofte opplever topper i bruk og høy gjennomstrømming, kan minneinterne buffere redusere ventetiden.

Hva brukes hurtigbufring til?

Hurtigbufring av utdata

Hurtigbufring av utdata hjelper deg med å øke ytelsen til nettsiden ved å lagre hele kildekoden til sider som HTML og klientskript som en server sender til nettlesere for gjengivelse. Hver gang en bruker ser siden, bufrer serveren utdatakoden i programmets minne. Dette gjør at programmet kan betjene forespørsler uten å kjøre sidekode eller kommunisere med andre servere.

Databufring og databasehurtigbufring

Databasehastighet og gjennomstrømming kan være nøkkelfaktorer i den generelle programytelsen. Databasebufring brukes til hyppige oppkall til data som ikke endres ofte, for eksempel priser eller beholdningsdata. Det hjelper nettsteder og programmer med å laste inn raskere, samtidig som det øker gjennomstrømmingen og senker datahentingsforsinkelsen fra serverdeldatabaser.

Lagring av brukerøktdata

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

Arkitekturer for publisering/abonnering og meldingsmegling

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

Programmer og API-er

I likhet med nettlesere lagrer programmer viktige filer og data for raskt å laste inn informasjonen når det er nødvendig. Bufrede API-svar eliminerer etterspørsel eller belastning på programservere og databaser, og gir raskere svartid og bedre ytelse.

[1] Ytelseskrav er basert på data fra en studie 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 databaseelementet i studien. En Gen5 Azure SQL Database-forekomst med 2 virtuelle kjerner til generell bruk og en forekomst av Azure Database for PostgreSQL med 2 virtuelle kjerner til generell bruk ble brukt med en P1 Premium-forekomst på 6 gigabyte av Azure for Redis. Disse resultatene ble sammenlignet med Gen5 Azure SQL-databaseforekomster med 8, 16, 24 og 32 virtuelle kjerner til generell bruk og forekomster av Azure Database for PostgreSQL med 8, 16, 24 og 32 virtuelle kjerner til generell bruk uten Azure Cache for Redis. Referanseverdidataene er hentet fra GigaOm Web Application Database Load Test, som simulerer et vanlig nettprogram og en serverdeldatabase som er sperret av økende HTTP-forespørsler. Faktiske resultater kan variere basert på konfigurasjon og område. Se hele studien.

Kostnadsfri konto

Prøv Azure-tjenester for databehandling i skyen gratis i opptil 30 dager.

Bruksbasert

Kom i gang med forbruksbetaling. Ingen forhåndsforpliktelser – avbryt når som helst.

Legg til et kjapt bufferlag i programmet ditt 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.