In-Memory er et sett med konsepter for lagring av data når de er lagret i applikasjonens RAM, og disken brukes til sikkerhetskopiering. I klassiske tilnærminger lagres data på disk og minne lagres i cache. For eksempel, en nettapplikasjon med en backend for behandling av data ber om den til lagring: den mottar den, transformerer den og mye data overføres over nettverket. I In-Memory sendes beregninger til dataene – til lagring, hvor de behandles og nettverket belastes mindre.
Hvilke andre muligheter er tilgjengelige med In-Memory og hva slags tilnærming er dette? Vladimir Pligin - ingeniør hos GridGain. Dette gjennomgangsmaterialet vil være nyttig for backend-utviklere av nettapplikasjoner som ikke har jobbet med In-Memory og ønsker å prøve, eller er interessert i moderne trender innen programvareutvikling og arkitekturdesign.
Note. Artikkelen er basert på transkripsjonen av Vladimirs rapport på #GetIT Conf. Før introduksjonen av selvisolering holdt vi jevnlig møter og konferanser for utviklere i Moskva og St. Petersburg: vi diskuterte trender, aktuelle utviklingsspørsmål, problemer og deres løsninger. Det er ikke mulig å holde en konferanse nå, men det er på tide å dele nyttig materiale fra tidligere.
Hvem bruker In-Memory og hvordan
In-Memory brukes oftest der det kreves rask brukerinteraksjon eller behandling av store datamengder.
- Banker bruk In-Memory, for eksempel for å redusere forsinkelser når klienter bruker applikasjoner eller for å analysere klienten før utstedelse av lån.
- Fintech bruker In-Memory for å forbedre ytelsen til tjenester og applikasjoner for banker som outsourcer databehandling og analyse.
- Forsikringsselskap: å beregne risiko, for eksempel ved å analysere kundedata over flere år.
- Logistikkbedrifter. De behandler mye data, for eksempel for å beregne optimale ruter for gods- og passasjertransport med tusenvis av parametere, og spore status for forsendelser.
- Detaljhandel. In-Memory-løsninger bidrar til å betjene kunder raskere og behandle store mengder informasjon: forsendelser, fakturaer, transaksjoner, tilstedeværelsen av tusenvis av varer i varehusene og utarbeide analytiske rapporter.
- В IOT In-Memory erstatter tradisjonelle databaser.
- Farmasøytisk selskaper bruker for eksempel In-Memory for å sortere gjennom kombinasjoner av legemiddelsammensetninger.
Jeg skal fortelle deg noen eksempler på hvordan våre kunder bruker In-Memory-løsninger og hvordan du kan implementere dem selv.
In-Memory som primær lagring
En av våre kunder er en stor leverandør av medisinsk vitenskapelig utstyr fra USA. De bruker en In-Memory-løsning som hoveddatalagring. Alle data lagres på disk, og delmengden av data som brukes aktivt, holdes i RAM. Lagringstilgangsmetodene er standard - GDBC (Generic Database Connector) og SQL-spørringsspråk.
Til sammen kalles dette In-Memory Database (IMDB) eller Memory-Centric Storage. Denne klassen av løsninger har mange navn, disse er ikke de eneste.
IMDB-funksjoner:
- Dataene som er lagret i In-Memory og tilgang til gjennom SQL er de samme som i andre tilnærminger. De er synkronisert, bare måten å presentere på, måten å adressere dem på er annerledes. Transaksjonalitet fungerer mellom data.
- IMDB er raskere enn relasjonsdatabaser fordi det er raskere å hente informasjon fra RAM enn fra disk.
- Interne optimaliseringsalgoritmer har færre instruksjoner.
- IMDB er egnet for å administrere data, hendelser og transaksjoner i applikasjoner.
IMDB-er støtter delvis ACID: Atomicity, Consistency og Isolation. Men de støtter ikke "holdbarhet" - når strømmen er slått av, går all data tapt. For å løse problemet kan du bruke øyeblikksbilder - et "øyeblikksbilde" av databasen, analogt med en databasesikkerhetskopi på en harddisk, eller registrere transaksjoner (logger) for å gjenopprette data etter en omstart.
For å lage feiltolerante applikasjoner
La oss forestille oss den klassiske arkitekturen til en feiltolerant nettapplikasjon. Det fungerer slik: alle forespørsler distribueres av en webbalanser mellom servere. Dette systemet er stabilt fordi serverne dupliserer hverandre og sikkerhetskopierer i tilfelle hendelser.
Balanseren dirigerer alle forespørsler fra én sesjon strengt tatt til én server. Dette er en pinne-sesjonsmekanisme: hver sesjon er knyttet til en server hvor den lagres og behandles lokalt.
Hva skjer når en av serverne svikter?
Tjenesten vil ikke bli berørt fordi arkitekturen er duplisert. Men vi vil miste et undersett av den døde serverens økter. Og samtidig brukerne som er knyttet til disse øktene. For eksempel legger en klient inn en ordre og kaster ham plutselig ut av kontoret. Han vil være misfornøyd når han logger på igjen og finner ut at alt må gjøres på nytt.
En nettapplikasjon er nødvendig for å støtte et stort antall brukere og ikke bremse ned slik at de kan jobbe komfortabelt. Men hvis den blir avslått, vil tiden det tar å kommunisere med øktbutikken øke med hver påfølgende forespørsel. Dette øker den gjennomsnittlige ventetiden for andre brukere. Men de vil ikke vente lenger enn de er vant til.
Dette problemet kan løses som vår andre klient, en stor PASS-leverandør fra USA. Den bruker In-Memory for å gruppere nettøkter. For å gjøre dette lagrer den dem ikke lokalt, men sentralt - i en In-Memory-klynge. I dette tilfellet er økter tilgjengelig mye raskere fordi de allerede er i RAM.
Når en server krasjer, sender balanseringsenheten forespørsler fra den krasjet serveren til andre servere, som i den klassiske arkitekturen. Men det er en viktig forskjell: økter lagres i en In-Memory-klynge og serverne har tilgang til øktene til den falne serveren.
Denne arkitekturen øker feiltoleransen til hele systemet. Dessuten er det mulig å forlate pinneøktmekanismen helt.
Hybrid Transactional Analytical Processing (HTAP)
Vanligvis holdes transaksjonelle og analytiske systemer atskilt. Når de skilles, blir hovedbasen belastet. For analytisk behandling kopieres data til en replika slik at analytisk behandling ikke forstyrrer transaksjonsprosesser. Men kopiering skjer med etterslep – det er umulig å replikere uten etterslep. Hvis vi gjør dette synkront, vil det også bremse hovedbasen og vi vil ikke få noen gevinster.
I HTAP fungerer alt annerledes – det samme datalageret brukes til transaksjonsbelastning fra applikasjoner, og for analytiske spørringer som kan ta lang tid å fullføre. Når dataene er i RAM, utføres analytiske spørringer raskere, og serveren med databasen er mindre belastet (i gjennomsnitt).
En hybrid tilnærming bryter ned veggen mellom transaksjonsbehandling og analyse. Hvis vi utfører analyser på samme lagring, blir analytiske spørringer lansert på data fra RAM. De er mye mer nøyaktige, mer tolkbare og tilstrekkelige.
Integrasjon av In-Memory løsninger
En (relativt) enkel måte - utvikle alt fra bunnen av. Vi holder data på disk og lagrer varme data i minnet. Dette hjelper deg med å overleve omstart av server eller driftsstans.
Det er to hovedscenarier på jobb her når data er lagret på disk. I det første ønsker vi å overleve krasj eller regelmessige omstarter av klyngen eller delene - vi ønsker å bruke den som en enkel database. I det andre scenariet, når det er for mye data, er noe av det i minnet.
Hvis det ikke er mulig å bygge alt fra bunnen av, er det mulig å integrere In-Memory i en allerede eksisterende arkitektur. Men ikke alle In-Memory-løsninger er egnet for dette. Det er tre obligatoriske betingelser. In-Memory-løsningen må støtte:
- standard måte å koble til databasen som vil være plassert under den (for eksempel MySQL);
- et standard spørringsspråk, for ikke å omskrive og endre logikken for interaksjon med lagringen;
- transaksjonell - bevar semantikken til interaksjon.
Hvis alle tre betingelsene er oppfylt, er integrering mulig. Vi plasserer In-Memory Data Grid mellom applikasjonen og databasen. Nå vil skriveforespørsler delegeres til den underliggende databasen, og leseforespørsler vil bli delegert til den underliggende databasen hvis dataene ikke er i hurtigbufferen.
Hvis rask tilgang til data og behandlingen av dem er viktig for deg, for eksempel for forretningsanalyse, kan du tenke på å implementere In-Memory. Og for implementering kan du bruke begge metodene når du designer en ny arkitektur.
Kilde: www.habr.com