Bedste svar
Som Scott McNulty tidligere svarede på dette spørgsmål, er SQL Caching lagring af resultatsæt genereret som et resultat af en forespørgsel mod en database og bruge kopien af resultatet til senere resultater. Når det er sagt, er der MEGET mere til dette spørgsmål end bare “cache”. Det virkelige problem cachelagrer ikke, det er ugyldiggørelsen, der er den hårde del. Det er ikke svært at gemme oplysninger. At vide, hvornår de er ugyldige, er.
Der er også et andet, mere subtilt problem involveret i caching, og det er netværksforsinkelsen af caching. De fleste cacheløsninger fungerer som en uafhængig server, ligesom en database gør. For at forespørge cachen skal der igen udføres en rundtur på tværs af netværket, ligesom til en database. Hvis cachen ikke har svaret pålideligt OG svarer hurtigere end databasen, er det meget vanskeligt faktisk at forbedre ydeevnen med cachen.
For at cache SQL optimalt har du brug for en løsning, der kan løse flere problemer:
- Hvilket indhold skal cachelagres?
- Hvis der er et cache-resultat, skal det betragtes som ugyldigt?
- Hvis cachen ramte sats er for lav, vil cache-logikken automatisk justeres for at stoppe caching og stoppe med at opslag for at undgå straf?
Virkeligheden er, at det tager en meget kompleks for at tage højde for de fleste hjørnesager. sæt logik for at sikre et optimalt scenarie for caching. Dette er ikke så simpelt som at implementere en cache-motor som Redis eller Hazelcast i din applikation . I stedet har du brug for en intelligent cache-motor, der kan inspicere, hvilke data der ændres, automatisk ugyldiggøre data og på anden måde optimere de anmodninger, der kan fremsættes til en ekstern cache-motor i forhold til hvad der foretages mod databasen.
En sådan motor er fra Heimdall Data (ansvarsfraskrivelse, jeg er CTO for Heimdall Data). Heimdall-motoren cachelagrer automatisk indhold, der er rettet fra applikationen til databasen, som enten en JDBC-driver eller som en proxy på protokolniveau, annullerer automatisk indholdet og optimerer også, hvilket indhold der er cache. Dette giver udviklere mulighed for at fokusere på funktioner, ikke cache, hvilket i nogle tilfælde kan spare 20–40\% af udvikling og fejlretningstid for en applikation.
Svar
Cache generelt lagres resultaterne af en proces, der er ressourceintensiv, så ressourcerne ikke behøver at blive brugt igen.
I SQL; det er altid specifikt for leverandørteknologien. MS-SQL, Oracle, MySQL og PostGres har alle forskellige valg for hvad de cache. Resultaterne, forespørgslen, selv udførelsesplanen for forespørgslen kan alle gemmes til brug ved senere forsøg på at behandle de samme oplysninger.
I tilfælde af at de underliggende data ændres, har systemet normalt en mekanisme at angive, at de cachelagrede oplysninger er “beskidte” og ikke længere kan bruges fuldt ud; så forespørgslen kan køres igen af systemet.
Du ser dette hele tiden. Hvor lang tid tager min forespørgsel? Hvorfor er det altid hurtigere, hvis jeg kører det en anden gang? Nå det er derfor. Systemet husker effektivt, hvad du har bedt om det før, og giver dig det svar, det husker fra det tidspunkt.