In-memory-arkitektur til webtjenester: teknologiske grundprincipper og principper

In-Memory er et sæt koncepter til lagring af data, når det er gemt i applikationens RAM, og disken bruges til backup. I klassiske tilgange lagres data på disk, og hukommelse gemmes i cache. For eksempel anmoder en webapplikation med en backend til behandling af data det til lager: den modtager det, transformerer det, og en masse data overføres over netværket. I In-Memory sendes beregninger til dataene - til lager, hvor de behandles og netværket belastes mindre.

Takket være sin arkitektur fremskynder In-Memory dataadgangen flere gange, og nogle gange endda størrelsesordener, hurtigere. For eksempel ønsker bankanalytikere at se i en analytisk applikation en rapport om udstedte lån i dynamik om dagen for det sidste år. Denne proces vil tage minutter på en klassisk DBMS, men med In-Memory vises den næsten med det samme. Dette skyldes, at tilgangen giver dig mulighed for at cache meget mere information, og den er gemt i RAM "ved hånden". Applikationen behøver ikke at anmode om data fra harddisken, hvis tilgængelighed er begrænset af netværk og diskhastighed.

Hvilke andre muligheder er tilgængelige med In-Memory, og hvilken slags tilgang er dette? Vladimir Pligin - ingeniør hos GridGain. Dette gennemgangsmateriale vil være nyttigt for webapplikations-backend-udviklere, som ikke har arbejdet med In-Memory og ønsker at prøve eller er interesseret i moderne trends inden for softwareudvikling og arkitekturdesign.

Bemærk. Artiklen er baseret på udskriften af ​​Vladimirs rapport på #GetIT Conf. Før introduktionen af ​​selvisolering afholdt vi regelmæssigt møder og konferencer for udviklere i Moskva og St. Petersborg: vi diskuterede tendenser, aktuelle udviklingsproblemer, problemer og deres løsninger. Det er ikke muligt at holde en konference nu, men det er tid til at dele nyttige materialer fra tidligere.

Hvem bruger In-Memory og hvordan

In-Memory bruges oftest, hvor der kræves hurtig brugerinteraktion eller behandling af store mængder data.

• Banker bruge In-Memory, for eksempel til at reducere forsinkelser, når kunder bruger applikationer, eller til at analysere kunden, før de udsteder et lån.
• Fintech bruger In-Memory til at forbedre ydeevnen af ​​tjenester og applikationer til banker, der outsourcer databehandling og analyse. 
• Forsikringsselskaber: at beregne risici, for eksempel ved at analysere kundedata over flere år.
• Logistikvirksomheder. De behandler en masse data, for eksempel for at beregne optimale ruter for gods- og passagertransport med tusindvis af parametre og spore status for forsendelser.
• Detailhandel. In-Memory-løsninger hjælper med at betjene kunder hurtigere og behandle store mængder information: forsendelser, fakturaer, transaktioner, tilstedeværelsen af ​​tusindvis af varer på lagre og udarbejde analytiske rapporter.
• В IoT In-Memory erstatter traditionelle databaser.
• Farmaceutisk virksomheder bruger for eksempel In-Memory til at sortere i kombinationer af lægemiddelsammensætninger. 

Jeg vil fortælle dig et par eksempler på, hvordan vores kunder bruger In-Memory-løsninger, og hvordan du selv kan implementere dem.

In-Memory som primært lager

En af vores kunder er en stor leverandør af medicinsk videnskabeligt udstyr fra USA. De bruger en In-Memory-løsning som deres primære datalager. Alle data gemmes på disken, og den delmængde af data, der bruges aktivt, opbevares i RAM. Lagringsadgangsmetoderne er standard - GDBC (Generic Database Connector) og SQL-forespørgselssprog.

Tilsammen kaldes dette In-Memory Database (IMDB) eller Memory-Centric Storage. Denne klasse af løsninger har mange navne, disse er ikke de eneste. 

IMDB funktioner:

• De data, der gemmes i In-Memory og tilgås via SQL, er de samme som i andre tilgange. De er synkroniserede, kun måden at præsentere, måden at adressere dem på er anderledes. Transaktionalitet fungerer mellem data.

• IMDB er hurtigere end relationelle databaser, fordi det er hurtigere at hente information fra RAM end fra disk. 
• Interne optimeringsalgoritmer har færre instruktioner.
• IMDB'er er velegnede til at administrere data, begivenheder og transaktioner i applikationer.

IMDB'er understøtter delvist ACID: Atomicity, Consistency og Isolation. Men de understøtter ikke "holdbarhed" - når strømmen er slukket, går alle data tabt. For at løse problemet kan du bruge snapshots - et "snapshot" af databasen, analogt med en database backup på en harddisk, eller registrere transaktioner (logfiler) for at gendanne data efter en genstart.

At skabe fejltolerante applikationer

Lad os forestille os den klassiske arkitektur af en fejltolerant webapplikation. Det fungerer sådan her: alle anmodninger distribueres af en webbalancer mellem servere. Dette system er stabilt, fordi serverne duplikerer hinanden og sikkerhedskopierer i tilfælde af hændelser.

Balanceren dirigerer alle anmodninger fra én session strengt til én server. Dette er en stick-sessionsmekanisme: hver session er knyttet til en server, hvor den er lokalt lagret og behandlet. 

Hvad sker der, når en af ​​serverne fejler?

Tjenesten vil ikke blive påvirket, fordi arkitekturen er duplikeret. Men vi vil miste en delmængde af den døde servers sessioner. Og samtidig de brugere, der er bundet til disse sessioner. For eksempel afgiver en klient en ordre og smider ham pludselig ud af kontoret. Han vil være utilfreds, når han logger ind igen og opdager, at alt skal gøres igen.

En webapplikation er påkrævet for at understøtte et stort antal brugere og ikke bremse, så de kan arbejde komfortabelt. Men hvis det afvises, vil den tid, det tager at kommunikere med sessionsbutikken, stige med hver efterfølgende anmodning. Dette øger den gennemsnitlige latenstid for andre brugere. Men de vil ikke vente længere, end de er vant til.

Dette problem kan løses som vores anden klient, en stor PASS-udbyder fra USA. Den bruger In-Memory til at gruppere websessioner. For at gøre dette gemmer den dem ikke lokalt, men centralt - i en In-Memory-klynge. I dette tilfælde er sessioner tilgængelige meget hurtigere, fordi de allerede er i RAM.

Når en server går ned, sender balanceren anmodninger fra den nedbrudte server til andre servere, som i den klassiske arkitektur. Men der er en vigtig forskel: sessioner gemmes i en In-Memory-klynge og serverne har adgang til sessionerne på den faldne server.

Denne arkitektur øger fejltolerancen for hele systemet. Desuden er det muligt helt at opgive pindsessionsmekanismen.

Hybrid Transactional Analytical Processing (HTAP)

Typisk holdes transaktions- og analytiske systemer adskilt. Når de adskilles, kommer hovedbasen under belastning. Til analytisk behandling kopieres data til en replika, så analytisk behandling ikke forstyrrer transaktionsprocesser. Men kopiering sker med forsinkelse - det er umuligt at replikere uden forsinkelse. Hvis vi gør dette synkront, vil det også bremse hovedbasen, og vi får ingen gevinster.

I HTAP fungerer alt anderledes - det samme datalager bruges til transaktionsbelastning fra applikationer og til analytiske forespørgsler, der kan tage lang tid at gennemføre. Når data er i RAM, udføres analytiske forespørgsler hurtigere, og serveren med databasen er mindre belastet (i gennemsnit).

En hybrid tilgang nedbryder muren mellem transaktionsbehandling og analyse. Hvis vi udfører analyser på det samme lager, startes analytiske forespørgsler på data fra RAM. De er meget mere nøjagtige, mere fortolkelige og fyldestgørende.

Integration af In-Memory løsninger

En (relativt) enkel måde - udvikle alt fra bunden. Vi opbevarer data på disk og lagrer varme data i hukommelsen. Dette hjælper med at overleve servergenstarter eller udfald.

Der er to hovedscenarier på arbejde her, når data gemmes på disk. I den første vil vi overleve nedbrud eller regelmæssige genstarter af klyngen eller dele - vi vil bruge det som en simpel database. I det andet scenarie, når der er for mange data, er noget af det i hukommelsen.

Hvis det ikke er muligt at bygge alt fra bunden, er det muligt at integrere In-Memory i en allerede eksisterende arkitektur. Men ikke alle In-Memory-løsninger er egnede til dette. Der er tre obligatoriske betingelser. In-Memory-løsningen skal understøtte:

• standard måde at oprette forbindelse til databasen, der vil være placeret under den (for eksempel MySQL);
• et standard forespørgselssprog, for ikke at omskrive og ændre logikken i interaktion med lageret;
• transaktionel - bevar interaktionens semantik.

Hvis alle tre betingelser er opfyldt, er integration mulig. Vi placerer In-Memory Data Grid mellem applikationen og databasen. Nu vil skriveanmodninger blive delegeret til den underliggende database, og læseanmodninger vil blive delegeret til den underliggende database, hvis dataene ikke er i cachen.

Hvis hurtig adgang til data og deres behandling er vigtig for dig, for eksempel til forretningsanalyse, kan du overveje at implementere In-Memory. Og til implementering kan du bruge begge metoder, når du designer en ny arkitektur.

Kilde: www.habr.com