Verkkopalveluiden muistiarkkitehtuuri: tekniikan perusteet ja periaatteet

In-Memory on joukko käsitteitä tietojen tallentamiseksi, kun ne tallennetaan sovelluksen RAM-muistiin, ja levyä käytetään varmuuskopiointiin. Klassisissa lähestymistavoissa tiedot tallennetaan levylle ja muisti välimuistiin. Esimerkiksi web-sovellus, jossa on taustaohjelma tietojen käsittelyä varten, pyytää ne tallennustilaan: se vastaanottaa sen, muuntaa sen ja paljon dataa siirretään verkon yli. In-Memoryssa laskelmat lähetetään dataan - tallennustilaan, jossa ne käsitellään ja verkko on vähemmän kuormitettu.

Arkkitehtuurinsa ansiosta In-Memory nopeuttaa tietojen käyttöä useita kertoja, joskus jopa suuruusluokkaa nopeammin. Esimerkiksi pankkien analyytikot haluavat nähdä analyyttisessä sovelluksessa raportin kuluneen vuoden aikana myönnetyistä lainoista päivädynamiikkana. Tämä prosessi kestää minuutteja klassisessa DBMS:ssä, mutta In-Memoryn kanssa se tulee näkyviin melkein välittömästi. Tämä johtuu siitä, että lähestymistavan avulla voit tallentaa välimuistiin paljon enemmän tietoa ja se tallennetaan "käsillä" olevaan RAM-muistiin. Sovelluksen ei tarvitse pyytää tietoja kiintolevyltä, jonka saatavuutta rajoittavat verkko ja levyn nopeus.

Mitä muita mahdollisuuksia In-Memory tarjoaa ja millainen lähestymistapa tämä on, hän kertoo sinulle Vladimir Pligin - GridGainin insinööri. Tämä arvostelumateriaali on hyödyllinen web-sovellusten taustakehittäjille, jotka eivät ole työskennelleet In-Memoryn kanssa ja haluavat kokeilla tai ovat kiinnostuneita ohjelmistokehityksen ja arkkitehtuurin suunnittelun nykyaikaisista trendeistä.

Huomata. Artikkeli perustuu Vladimirin raportin tekstiin #GetIT Conf. Ennen itseeristyksen käyttöönottoa järjestimme säännöllisesti Moskovassa ja Pietarissa tapaamisia ja konferensseja kehittäjille: keskustelimme trendeistä, ajankohtaisista kehityskysymyksistä, ongelmista ja niiden ratkaisuista. Nyt ei ole mahdollista järjestää konferenssia, mutta on aika jakaa hyödyllistä materiaalia menneistä.

Kuka käyttää In-Memorya ja miten

In-Memorya käytetään useimmiten silloin, kun tarvitaan nopeaa käyttäjän vuorovaikutusta tai suurten tietomäärien käsittelyä.

• Pankit Käytä In-Memorya esimerkiksi vähentääksesi viiveitä asiakkaiden käyttäessä sovelluksia tai analysoidaksesi asiakasta ennen lainan myöntämistä.
• Fintech käyttää In-Memorya parantaakseen tietojenkäsittelyn ja analysoinnin ulkoistavien pankkien palveluiden ja sovellusten suorituskykyä. 
• Vakuutusyhtiöt: laskea riskejä esimerkiksi analysoimalla asiakastietoja usean vuoden ajalta.
• Logistiikkayritykset. Ne käsittelevät paljon tietoa esimerkiksi laskeakseen optimaaliset reitit rahti- ja matkustajaliikenteelle tuhansien parametrien avulla ja seuratakseen lähetysten tilaa.
• Jälleenmyynti. In-Memory -ratkaisut auttavat palvelemaan asiakkaita nopeammin ja käsittelemään suuria tietomääriä: lähetyksiä, laskuja, tapahtumia, tuhansien tavaroiden läsnäoloa varastossa ja laatimaan analyyttisiä raportteja.
• В Esineiden internet In-Memory korvaa perinteiset tietokannat.
• Farmasia yritykset käyttävät In-Memoryta esimerkiksi lääkekoostumusten yhdistelmien lajitteluun. 

Kerron sinulle muutaman esimerkin siitä, kuinka asiakkaamme käyttävät In-Memory-ratkaisuja ja kuinka voit toteuttaa ne itse.

In-Memory ensisijaisena tallennustilana

Yksi asiakkaistamme on suuri lääketieteellisten tieteellisten laitteiden toimittaja Yhdysvalloista. He käyttävät In-Memory -ratkaisua pääasiallisena tallennustilana. Kaikki tiedot tallennetaan levylle, ja aktiivisesti käytetyt tiedot säilytetään RAM-muistissa. Tallennuskäyttötavat ovat vakiomuotoisia - GDBC (Generic Database Connector) ja SQL-kyselykieli.

Tätä kutsutaan yhteisesti IMDB (In-Memory Database) tai Memory-Centric Storageksi. Tällä ratkaisuluokalla on monia nimiä, eivätkä nämä ole ainoita. 

IMDB:n ominaisuudet:

• Muistiin tallennetut ja SQL:n kautta käytettävät tiedot ovat samat kuin muissa lähestymistavoissa. Ne ovat synkronoituja, vain esitystapa, tapa käsitellä niitä on erilainen. Transaktio toimii tietojen välillä.

• IMDB on nopeampi kuin relaatiotietokannat, koska se on nopeampi hakea tietoja RAM-muistista kuin levyltä. 
• Sisäisillä optimointialgoritmeilla on vähemmän ohjeita.
• IMDB:t soveltuvat tietojen, tapahtumien ja tapahtumien hallintaan sovelluksissa.

IMDB:t tukevat osittain ACID:tä: Atomicity, Consistency ja Isolation. Mutta ne eivät tue "kestävyyttä" - kun virta katkaistaan, kaikki tiedot menetetään. Ongelman ratkaisemiseksi voit käyttää tilannekuvia - tietokannan "otosta", joka on analoginen tietokannan varmuuskopion kanssa kiintolevylle, tai tallentaa tapahtumia (lokeja) tietojen palauttamiseksi uudelleenkäynnistyksen jälkeen.

Luodaan vikasietoisia sovelluksia

Kuvittelemme vikasietoisen verkkosovelluksen klassista arkkitehtuuria. Se toimii näin: kaikki pyynnöt jakaa web-tasapainotin palvelimien välillä. Tämä järjestelmä on vakaa, koska palvelimet kopioivat toisiaan ja varmuuskopioivat tapausten sattuessa.

Tasapainotin ohjaa kaikki pyynnöt yhdestä istunnosta tiukasti yhdelle palvelimelle. Tämä on kiinni-istuntomekanismi: jokainen istunto liittyy palvelimeen, jossa se tallennetaan ja käsitellään paikallisesti. 

Mitä tapahtuu, kun yksi palvelimista epäonnistuu?

Tämä ei vaikuta palveluun, koska arkkitehtuuri on monistettu. Mutta menetämme osan kuolleen palvelimen istunnoista. Ja samaan aikaan näihin istuntoihin sidotut käyttäjät. Esimerkiksi asiakas tekee tilauksen ja yhtäkkiä heittää hänet ulos toimistosta. Hän on onneton, kun hän kirjautuu uudelleen sisään ja huomaa, että kaikki on tehtävä uudelleen.

Verkkosovellusta tarvitaan tukemaan suurta määrää käyttäjiä eikä hidastumaan, jotta he voivat työskennellä mukavasti. Mutta jos se evätään, jokaisen myöhemmän pyynnön yhteydessä istuntomuistin kanssa kommunikointiin kuluva aika kasvaa. Tämä lisää muiden käyttäjien keskimääräistä viivettä. Mutta he eivät halua odottaa pidempään kuin ovat tottuneet.

Tämä ongelma voidaan ratkaista kuten toinen asiakkaamme, suuri PASS-palveluntarjoaja Yhdysvalloista. Se käyttää In-Memoryta web-istuntojen klusterointiin. Tätä varten se ei tallenna niitä paikallisesti, vaan keskitetysti - muistin sisäiseen klusteriin. Tässä tapauksessa istunnot ovat saatavilla paljon nopeammin, koska ne ovat jo RAM-muistissa.

Kun palvelin kaatuu, tasapainotin lähettää pyynnöt kaatuneelta palvelimelta muille palvelimille, kuten perinteisessä arkkitehtuurissa. Mutta on tärkeä ero: istunnot tallennetaan In-Memory-klusteriin ja palvelimilla on pääsy kaatuneen palvelimen istuntoihin.

Tämä arkkitehtuuri lisää koko järjestelmän vikasietoisuutta. Lisäksi on mahdollista luopua stick-istuntomekanismista kokonaan.

Hybriditransaktioiden analyyttinen käsittely (HTAP)

Tyypillisesti tapahtuma- ja analyyttiset järjestelmät pidetään erillään. Kun ne erottuvat, pääjalusta joutuu kuormitukseen. Analyyttistä käsittelyä varten tiedot kopioidaan replikaan, jotta analyyttinen käsittely ei häiritse tapahtumaprosesseja. Mutta kopiointi tapahtuu viiveellä – on mahdotonta replikoida ilman viivettä. Jos teemme tämän synkronisesti, se myös hidastaa pääpohjaa, emmekä saa voittoja.

HTAP:ssa kaikki toimii eri tavalla – samaa tietovarastoa käytetään sovellusten tapahtumien lataamiseen ja analyyttisiin kyselyihin, joiden suorittaminen voi kestää kauan. Kun tiedot ovat RAM-muistissa, analyyttiset kyselyt suoritetaan nopeammin ja tietokannan sisältävä palvelin on vähemmän kuormitettu (keskimäärin).

Hybridilähestymistapa murtaa muurin tapahtumien käsittelyn ja analytiikan välillä. Jos suoritamme analytiikkaa samalle tallennustilalle, analyyttiset kyselyt käynnistetään tiedoista RAM-muistista. Ne ovat paljon tarkempia, tulkittavampia ja riittävämpiä.

In-Memory-ratkaisujen integrointi

(Suhteellisen) yksinkertainen tapa - kehittää kaikkea alusta alkaen. Säilytämme tiedot levyllä ja tallennamme kuumat tiedot muistiin. Tämä auttaa selviytymään palvelimen uudelleenkäynnistyksistä tai katkoksista.

Tässä on kaksi pääskenaariota, kun tietoja tallennetaan levylle. Ensimmäisessä haluamme selviytyä klusterin tai osien kaatumisista tai säännöllisistä uudelleenkäynnistyksistä - haluamme käyttää sitä yksinkertaisena tietokantana. Toisessa skenaariossa, kun dataa on liikaa, osa siitä on muistissa.

Jos kaikkea ei ole mahdollista rakentaa tyhjästä, on mahdollista integroida In-Memory jo valmiiksi olemassa olevaa arkkitehtuuria. Mutta kaikki In-Memory-ratkaisut eivät sovellu tähän. Pakollisia ehtoja on kolme. In-Memory-ratkaisun tulee tukea:

• tavallinen tapa muodostaa yhteys tietokantaan, joka sijaitsee sen alla (esimerkiksi MySQL);
• tavallinen kyselykieli, jotta ei kirjoiteta uudelleen ja muuteta vuorovaikutuksen logiikkaa tallennustilan kanssa;
• transaktionaalinen - säilyttää vuorovaikutuksen semantiikka.

Jos kaikki kolme ehtoa täyttyvät, integrointi on mahdollista. Sijoitamme In-Memory Data Gridin sovelluksen ja tietokannan väliin. Nyt kirjoituspyynnöt delegoidaan taustalla olevaan tietokantaan ja lukupyynnöt taustalla olevaan tietokantaan, jos tiedot eivät ole välimuistissa.

Jos nopea pääsy dataan ja sen käsittely on sinulle tärkeää esimerkiksi yritysanalytiikan kannalta, voit harkita In-Memoryn käyttöönottoa. Ja toteutuksessa voit käyttää molempia menetelmiä uuden arkkitehtuurin suunnittelussa.

Lähde: will.com