Beste svaret
Som Scott McNulty tidligere svarte på dette spørsmålet, er SQL Caching lagring av resultatsett generert som et resultat av et spørsmål mot en database, og bruke kopien av resultatet for senere resultater. Når det er sagt, er det mye mer i denne saken enn bare «caching». Det virkelige problemet er ikke hurtigbufring, det er ugyldiggjørelsen som er den vanskelige delen. Det er ikke vanskelig å lagre informasjon. Å vite når den er ugyldig er.
Det er også et annet, mer subtilt problem involvert i caching, og det er nettverkets latenspåvirkning av caching. De fleste cacheløsninger fungerer som en uavhengig server, omtrent som en database gjør. For å spørre hurtigbufferen, må en rundtur over nettverket utføres, igjen, som til en database. Hvis hurtigbufferen ikke har svaret pålitelig OG svarer raskere enn databasen, er det veldig vanskelig å faktisk forbedre ytelsen med hurtigbufferen.
For å cache SQL optimalt, trenger du en løsning som kan løse flere problemer:
- Hvilket innhold skal bufres?
- Hvis det er et hurtigbufret resultat, bør det betraktes som ugyldig?
- Hvis hurtigbufferen traff frekvensen er for lav, vil hurtigbufferlogikken automatisk justeres for å stoppe hurtigbufring og slutte å slå opp for å unngå straffen?
Virkeligheten er at for å ta hensyn til de fleste hjørnesaker, tar det en veldig kompleks sett med logikk for å sikre et best-case ytelsesscenario for hurtigbufring. Dette er ikke så enkelt som å implementere en hurtigbuffermotor som Redis eller Hazelcast i applikasjonen din . I stedet trenger du en intelligent hurtigbuffermotor som kan inspisere hvilke data som endres, automatisk ugyldiggjøre data, og ellers optimalisere forespørslene til en ekstern hurtigbuffermotor mot det som blir gjort mot databasen.
En slik motor er fra Heimdall Data (ansvarsfraskrivelse, jeg er CTO for Heimdall Data). Heimdall-motoren cacher automatisk innhold som er dirigert fra applikasjonen til databasen, enten som en JDBC-driver, eller som en proxy på protokollnivå, ugyldiggjør innhold automatisk, og optimaliserer også hvilket innhold som er hurtigbufret. Dette gjør at utviklere kan fokusere på funksjoner, ikke hurtigbuffer, som i noen tilfeller kan spare 20–40\% av utvikling og feilsøkingstid for et program.
Svar
Caching generelt lagres resultatene av en prosess som er ressurskrevende slik at ressursene ikke trenger å bli brukt igjen.
I SQL; det er alltid spesifikt for leverandørteknologien. MS-SQL, Oracle, MySQL og PostGres har forskjellige valg for hva de cache. Resultatene, spørringen, til og med utførelsesplanen for spørringen, kan alle lagres for bruk ved senere forsøk på å behandle den samme informasjonen.
Hvis de underliggende dataene endres, har systemet vanligvis en mekanisme å indikere at den bufrede informasjonen er “skitten” og ikke lenger er fullt brukbar; slik at spørringen kan kjøres igjen av systemet.
Du ser dette hele tiden. Hvor lang tid tar spørringen min? Hvorfor er det alltid raskere hvis jeg kjører det en gang til? Vel, det er derfor. Systemet husker effektivt det du spurte om før, og gir deg svaret det husker fra den tiden.