Forespørgsler skal cachelagres i hver tungt belastet database, der er simpelthen ingen måde for en database at håndtere al trafik med rimelig ydeevne. Der er forskellige mekanismer, hvori en forespørgselscache kan implementeres. Startende fra MySQL-forespørgselscachen, som plejede at fungere fint til for det meste skrivebeskyttede, lave samtidige arbejdsbelastninger, og som ikke har nogen plads i høje samtidige arbejdsbelastninger (i det omfang, Oracle fjernede det i MySQL 8.0), til eksterne nøgleværdi-lagre som Redis, memcached eller CouchBase.
Hovedproblemet med at bruge et eksternt dedikeret datalager (da vi ikke vil anbefale at bruge MySQL-forespørgselscache til nogen) er, at dette er endnu et datalager at administrere. Det er endnu et miljø, der skal vedligeholdes, skaleringsproblemer, der skal håndteres, fejl til fejlretning og så videre.
Så hvorfor ikke slå to fluer med ét smæk ved at udnytte din proxy? Antagelsen her er, at du bruger en proxy i dit produktionsmiljø, da det hjælper med at indlæse belastningsbalanceforespørgsler på tværs af instanser og maskere den underliggende databasetopologi ved at give et simpelt slutpunkt til applikationer. ProxySQL er et godt værktøj til jobbet, da det desuden kan fungere som et caching-lag. I dette blogindlæg viser vi dig, hvordan du cacher forespørgsler i ProxySQL ved hjælp af ClusterControl.
Hvordan fungerer forespørgselscache i ProxySQL?
Først og fremmest lidt af en baggrund. ProxySQL styrer trafik gennem forespørgselsregler, og det kan udføre forespørgselscache ved hjælp af den samme mekanisme. ProxySQL gemmer cachelagrede forespørgsler i en hukommelsesstruktur. Cachelagrede data bliver smidt ud ved hjælp af time-to-live (TTL) indstilling. TTL kan defineres for hver forespørgselsregel individuelt, så det er op til brugeren at beslutte, om forespørgselsregler skal defineres for hver enkelt forespørgsel, med særskilt TTL, eller om hun blot skal oprette et par regler, som vil matche størstedelen af trafikken.
Der er to konfigurationsindstillinger, der definerer, hvordan en forespørgselscache skal bruges. Først mysql-query_cache_size_MB som definerer en blød grænse for forespørgselscachestørrelsen. Det er ikke en hård grænse, så ProxySQL bruger muligvis lidt mere hukommelse end det, men det er nok til at holde hukommelsesudnyttelsen under kontrol. Den anden indstilling, du kan justere, er mysql-query_cache_stores_empty_result . Det definerer, om et tomt resultatsæt er cachelagret eller ej.
ProxySQL-forespørgselscache er designet som et nøgleværdilager. Værdien er resultatet af en forespørgsel, og nøglen er sammensat af sammenkædede værdier som:bruger, skema og forespørgselstekst. Derefter oprettes en hash af den streng, og den hash bruges som nøglen.
Opsætning af ProxySQL som en forespørgselscache ved hjælp af ClusterControl
Som den indledende opsætning har vi en replikeringsklynge med en master og en slave. Vi har også en enkelt ProxySQL.
Dette er på ingen måde en opsætning i produktionsgrad, da vi ville være nødt til at implementere en slags høj tilgængelighed for proxy-laget (for eksempel ved at implementere mere end én ProxySQL-instans og derefter holde i live oven på dem for flydende virtuel IP), men det vil være mere end nok til vores tests.
Først skal vi verificere ProxySQL-konfigurationen for at sikre, at indstillinger for forespørgselscache er, som vi ønsker, de skal være.
256 MB forespørgselscache burde være nogenlunde rigtigt, og vi vil også cache de tomme resultatsæt - nogle gange skal en forespørgsel, der ikke returnerer nogen data, stadig gøre en masse arbejde for at bekræfte, at der ikke er noget at returnere.
Næste trin er at oprette forespørgselsregler, som matcher de forespørgsler, du vil cache. Der er to måder at gøre det på i ClusterControl.
Manuel tilføjelse af forespørgselsregler
Den første måde kræver lidt flere manuelle handlinger. Ved at bruge ClusterControl kan du nemt oprette enhver forespørgselsregel, du ønsker, inklusive forespørgselsregler, der foretager cachen. Lad os først tage et kig på listen over reglerne:
På dette tidspunkt har vi et sæt forespørgselsregler til at udføre læse/skrive-opdelingen. Den første regel har et ID på 100. Vores nye forespørgselsregel skal behandles før den, så vi vil bruge lavere regel-id. Lad os oprette en forespørgselsregel, som vil cache forespørgsler svarende til denne:
SELECT DISTINCT c FROM sbtest8 WHERE id BETWEEN 5041 AND 5140 ORDER BY c
Der er tre måder at matche forespørgslen på:Digest, Match Digest og Match Pattern. Lad os tale lidt om dem her. Først Match Digest. Vi kan her indstille et regulært udtryk, der matcher en generaliseret forespørgselsstreng, der repræsenterer en forespørgselstype. For eksempel til vores forespørgsel:
SELECT DISTINCT c FROM sbtest8 WHERE id BETWEEN 5041 AND 5140 ORDER BY cDen generiske repræsentation vil være:
SELECT DISTINCT c FROM sbtest8 WHERE id BETWEEN ? AND ? ORDER BY cSom du kan se, fjernede det argumenterne til WHERE-sætningen, derfor er alle forespørgsler af denne type repræsenteret som en enkelt streng. Denne mulighed er ret rar at bruge, fordi den matcher hele forespørgselstypen, og hvad der er endnu vigtigere, den er fjernet fra mellemrum. Dette gør det så meget nemmere at skrive et regulært udtryk, da du ikke skal tage højde for mærkelige linjeskift, mellemrum i begyndelsen eller slutningen af strengen og så videre.
Digest er dybest set en hash, som ProxySQL beregner over Match Digest-formen.
Endelig matcher Match Pattern mod fuld forespørgselstekst, som den blev sendt af klienten. I vores tilfælde vil forespørgslen have en form for:
SELECT DISTINCT c FROM sbtest8 WHERE id BETWEEN 5041 AND 5140 ORDER BY cVi vil bruge Match Digest, da vi ønsker, at alle disse forespørgsler skal være omfattet af forespørgselsreglen. Hvis vi ønskede at cache netop den specifikke forespørgsel, ville en god mulighed være at bruge Match Pattern.
Det regulære udtryk, vi bruger, er:
SELECT DISTINCT c FROM sbtest[0-9]+ WHERE id BETWEEN \? AND \? ORDER BY cVi matcher bogstaveligt talt den nøjagtige generaliserede forespørgselsstreng med én undtagelse - vi ved, at denne forespørgsel ramte flere tabeller, derfor tilføjede vi et regulært udtryk for at matche dem alle.
Når dette er gjort, kan vi se, om forespørgselsreglen er i kraft eller ej.
Vi kan se, at 'hits' er stigende, hvilket betyder, at vores forespørgselsregel bliver brugt. Dernæst vil vi se på en anden måde at oprette en forespørgselsregel på.
Brug af ClusterControl til at oprette forespørgselsregler
ProxySQL har en nyttig funktionalitet til at indsamle statistik over de forespørgsler, den har sendt. Du kan spore data som eksekveringstid, hvor mange gange en given forespørgsel blev udført og så videre. Disse data findes også i ClusterControl:
Hvad der er endnu bedre, hvis du peger på en given forespørgselstype, kan du oprette en forespørgselsregel relateret til den. Du kan også nemt cache denne særlige forespørgselstype.
Som du kan se, er nogle af dataene som Regel IP, Cache TTL eller Schema Name allerede udfyldt. ClusterControl vil også udfylde data baseret på, hvilken matchningsmekanisme du besluttede at bruge. Vi kan nemt bruge enten hash til en given forespørgselstype, eller vi kan bruge Match Digest eller Match Pattern, hvis vi gerne vil finjustere det regulære udtryk (for eksempel at gøre det samme som vi gjorde tidligere og udvide det regulære udtryk til at matche alle tabeller i sbtest-skema).
Dette er alt hvad du behøver for nemt at oprette forespørgselscacheregler i ProxySQL. Download ClusterControl for at prøve det i dag.