|
Datadrevne applikationer spænder over en bred bredde af kompleksitet, fra simple mikrotjenester til hændelsesdrevne systemer i realtid under betydelig belastning. Men som ethvert udviklings- og/eller DevOps-team, der har til opgave at forbedre ydeevnen, vil bevidne, er det "ikke-trivielt" at gøre datadrevne apps hurtige globalt.
Moderne applikationsarkitekturer såsom JAMstack håndhæver adskillelsen af bekymringer ved at flytte data- og persistenskravene til API'en. Ren adskillelse af statisk indhold, forretningslogik og datapersistens gør det muligt at skalere og administrere hver enkelt uafhængigt.
Mange virksomheder er også fokuseret på at afkoble deres monolitiske applikationer for at bruge mikrotjenester og implementerer ofte i serverløse miljøer. Dette skift til mere afkobling for bedre miljøisolering kan også give bedre regional smidighed med hensyn til, hvor forretningslogikken er implementeret, og hvordan den skaleres. Programmer kan nu implementeres globalt i en enkelt CI/CD-handling.
Datalaget udgør dog større kompleksitet. Der er praktiske udfordringer såsom transaktionskonsistens, høj tilgængelighed og forespørgselsydeevne under belastning. Der er begrænsninger såsom overholdelse af PII og overholdelseskrav. Og der er uoverstigelige grænser som dem, fysikkens love pålægger latens.
Applikationscaching
Mange udviklingsteams ser på caching for at løse disse problemer på applikationslaget, understøttet af persistenslag som Redis eller hjemmelavede systemer. Konceptet er enkelt:Gem de data, som klienten anmoder om, i en periode, og hvis vi ser dem igen, har vi dem klar til at betjene den næste anmodning uden at ty til oprindelsesdatabasen. Udvikling af en god cachestrategi bringer sit eget sæt af udfordringer:hvilke data der skal cachelagres, hvordan cachelagres det, og hvornår. Og måske endnu vigtigere, hvad, hvordan og hvornår man skal fjerne data fra cachen. Cachingstrategien skal være veldefineret, forstået og anvendt for hvert nyt funktionssæt, der føjes til applikationen, på tværs af udviklere og potentielt afdelingsteams. Udviklingstid og kompleksitet er prisen.
Database læse-replikaer
Alternativt løser mange virksomheder latens- og skaleringsudfordringer med databaselæse replikaer. Læse replikaer er skrivebeskyttede forekomster af den primære database og holdes automatisk synkroniseret (asynkront), efterhånden som der foretages opdateringer til den primære. Udvikling af en solid læse-replika-strategi er en skræmmende opgave fuld af sine egne subtile og ikke så subtile omkostninger og kompleksiteter.
Meget af denne kompleksitet kan tæmmes med ScaleGrid. Fuldt administrerede læsereplikaer kan implementeres med et klik på en knap fra ScaleGrid (med HA-understøttelse) i alle større skyer og regioner, med den vigtigste fordel, at data holdes synkroniseret med den primære database automatisk.
Læse replikaer kan dog ikke undslippe nødvendigheden af at køre flere, måske mange flere, databaseservere og deres tilknyttede omkostninger.
En anden tilgang:PolyScale.ai Edge Cache
PolyScale er en database edge cache, der har en anden tilgang. PolyScales cache giver to primære fordele:forbedret forespørgselsforsinkelse og reduceret databasearbejdsbelastning. Lad os bryde det lidt ned:
Regional latenstid løses meget som en CDN; PolyScale leverer et globalt kantnetværk af Points of Presence (PoP) og gemmer databaseforespørgselssvar tæt på den oprindelige klient, hvilket fremskynder svarene betydeligt.
Læseforespørgselsydeevne er dramatisk forbedret, da PolyScale vil tjene enhver cachelagret databaseanmodning på <10 ms, uanset forespørgslens kompleksitet. Da læseanmodninger leveres fra PolyScale, påvirker denne belastning desuden aldrig oprindelsesdatabasen.
Implementering
PolyScale kan implementeres uden at skrive kode eller installere servere på få minutter. Opdater blot databaseklienten (det være sig en webapplikation, mikroservice eller BI-værktøj såsom Tableau) forbindelsesstrengen med PolyScale-værtsnavnet. Databasetrafik vil derefter passere gennem edge-netværket og er klar til caching.
Der er trådkompatibel med MySQL og Postgres, PolyScale er fuldstændig gennemsigtig for databaseklienter, og derfor ændres intet med din nuværende arkitektur. Ingen migreringer, ingen ændringer i transaktionsevnen og ingen ændringer i dit nuværende forespørgselssprog. Virkelig plug and play.
Hvordan fungerer det?
PolyScales globale netværksproxyer og cacher native database-wire-protokoller, så det er gennemsigtigt for enhver databaseklient. Forespørgsler inspiceres og læses (SQL SELECT ) kan cachelagres geografisk tæt på den anmodende oprindelse for accelereret ydeevne. Al anden trafik (INSERT , UPDATE og DELETE ) går problemfrit igennem til kildedatabasen.
PolyScales AI er på vej mod fuld automatisering. I stedet for at konfigurere cachen efter behov, vil platformen måle strømmen af trafik og løbende justere cacheegenskaberne for at give optimal ydeevne. Du kan læse mere om PolyScale AI-cachemodellen her.
Konklusioner
PolyScale.ai giver en moderne plug and play tilgang til ydeevne og skalering på dataniveauet. PolyScale-platformen er på vej mod fuld automatisering, hvor den, når den er tilsluttet, intelligent vil administrere caching af dataene for optimal ydeevne.
I betragtning af at PolyScale er trådkompatibel med din nuværende database, er der ingen ændringer nødvendige for at skalere læsninger globalt på få minutter. Prøv det!