|
Datadrivna applikationer spänner över en bred bredd av komplexitet, från enkla mikrotjänster till realtidshändelsedrivna system under betydande belastning. Men som alla utvecklings- och/eller DevOps-team med uppgift att förbättra prestanda kommer att intyga, är det "icke-trivialt" att göra datadrivna appar snabba globalt.
Moderne applikationsarkitekturer som JAMstack tvingar fram separationen av problem genom att flytta data- och beständighetskraven till API:et. Rent separerande statiskt innehåll, affärslogik och databeständighet gör att var och en kan skalas och hanteras oberoende.
Många företag är också fokuserade på att frikoppla sina monolitiska applikationer för att använda mikrotjänster och distribuerar ofta i serverlösa miljöer. Denna övergång till mer frikoppling för bättre miljöisolering kan också ge bättre regional smidighet med avseende på var affärslogik används och hur den skalas. Applikationer kan nu distribueras globalt i en enda CI/CD-åtgärd.
Datanivån utgör dock större komplexitet. Det finns praktiska utmaningar som transaktionskonsistens, hög tillgänglighet och frågeprestanda under belastning. Det finns begränsningar som att följa PII och efterlevnadskrav. Och det finns oöverstigliga gränser som de fysikens lagar ställer på latens.
Cachning av program
Många utvecklingsteam ser till att cachelagra för att lösa dessa problem i applikationslagret, med stöd av beständighetslager som Redis eller hemmagjorda system. Konceptet är enkelt:lagra den data som kunden begärt under en viss tid och om vi ser den igen har vi den redo att leverera nästa begäran utan att tillgripa ursprungsdatabasen. Konstruera en bra cachningsstrategi medför sin egen uppsättning utmaningar:vilken data som ska cachelagras, hur man cachelagrar den och när. Och kanske ännu viktigare, vad, hur och när man ska vräka data från cachen. Cachingstrategin måste vara väl definierad, förstådd och använd för varje ny funktionsuppsättning som läggs till applikationen, över utvecklare och potentiellt avdelningsteam. Utvecklingstid och komplexitet är kostnaden.
Databasläsrepliker
Alternativt löser många företag latens- och skalningsutmaningar med databasläsrepliker. Läsrepliker är skrivskyddade instanser av den primära databasen och hålls automatiskt synkroniserade (asynkront) när uppdateringar görs av den primära. Att konstruera en solid läs-replikstrategi är en skrämmande uppgift full av sina egna subtila och inte så subtila kostnader och komplexitet.
Mycket av den komplexiteten kan tämjas med ScaleGrid. Fullt hanterade läs-repliker kan distribueras med ett klick på en knapp från ScaleGrid (med HA-stöd) i alla större moln och regioner, med den viktigaste fördelen att data hålls automatiskt synkroniserade med den primära databasen.
Läsrepliker kan dock inte undgå behovet av att köra flera, kanske många flera, databasservrar och deras associerade kostnader.
Ett annat tillvägagångssätt:PolyScale.ai Edge Cache
PolyScale är en databaskantcache som tar ett annat tillvägagångssätt. PolyScales cache ger två primära fördelar:förbättrad frågefördröjning och minskad databasarbetsbelastning. Låt oss bryta ner det lite:
Regional latens löses ungefär som en CDN; PolyScale tillhandahåller ett globalt edge-nätverk av Points of Presence (PoP) och lagrar databasförfrågesvar nära den ursprungliga klienten, vilket avsevärt snabbar upp svaren.
Läsfrågeprestanda är dramatiskt förbättrad eftersom PolyScale kommer att betjäna alla cachade databasförfrågningar på <10 ms, oavsett frågans komplexitet. Dessutom, med tanke på att läsbegäranden serveras från PolyScale, påverkar denna belastning aldrig ursprungsdatabasen.
Implementering
PolyScale kan implementeras utan att skriva kod eller distribuera servrar på några minuter. Uppdatera helt enkelt databasklienten (oavsett om det är en webbapplikation, mikrotjänst eller BI-verktyg som Tableau) anslutningssträngen med PolyScale-värdnamnet. Databastrafik kommer sedan att passera genom kantnätverket och är redo för cachning.
Att vara trådkompatibel med MySQL och Postgres, är PolyScale helt transparent för databasklienter, därför förändras ingenting med din nuvarande arkitektur. Inga migreringar, inga ändringar av transaktionalitet och inga ändringar av ditt nuvarande frågespråk. Verkligen plug and play.
Hur fungerar det?
PolyScales globala nätverksproxyer och cachar inbyggda databastrådsprotokoll så att de är transparenta för alla databasklienter. Frågor inspekteras och läses (SQL SELECT ) kan cachelagras geografiskt nära det begärande ursprunget för accelererad prestanda. All annan trafik (INSERT , UPDATE och DELETE ) passerar sömlöst till källdatabasen.
PolyScales AI är på väg mot full automatisering. Istället för att konfigurera cachen efter behov kommer plattformen att mäta trafikflödet och kontinuerligt justera cacheegenskaper för att ge optimal prestanda. Du kan läsa mer om PolyScale AI-cachemodell här.
Slutsatser
PolyScale.ai erbjuder en modern plug and play-metod för prestanda och skalning på datanivån. PolyScale-plattformen är på väg mot full automatisering där, när den väl är ansluten, kommer den intelligent att hantera cachning av data för optimal prestanda.
Med tanke på att PolyScale är trådkompatibel med din nuvarande databas, är inga ändringar nödvändiga för att skala avläsningar globalt på några minuter. Ge det ett försök!