In-memory arhitektura za web usluge: osnove i principi tehnologije

In-Memory je skup koncepata za pohranu podataka kada su pohranjeni u RAM-u aplikacije, a disk se koristi za sigurnosno kopiranje. U klasičnim pristupima podaci se pohranjuju na disk, a memorija u predmemoriju. Na primjer, web-aplikacija s pozadinom za obradu podataka traži ih u pohranu: prima ih, transformira i puno podataka se prenosi preko mreže. U In-Memory se izračuni šalju u podatke – u pohranu, gdje se obrađuju i mreža se manje opterećuje.

Zahvaljujući svojoj arhitekturi, In-Memory ubrzava pristup podacima nekoliko puta, a ponekad čak i redova veličine brže. Na primjer, bankovni analitičari žele u analitičkoj aplikaciji vidjeti izvješće o izdanim kreditima tijekom protekle godine u dinamici po danima. Ovaj proces će trajati nekoliko minuta na klasičnom DBMS-u, ali s In-Memory će se pojaviti gotovo odmah. To je zato što vam pristup omogućuje predmemoriranje puno više informacija i one su pohranjene u RAM-u "pri ruci". Aplikacija ne treba tražiti podatke s tvrdog diska, čija je dostupnost ograničena brzinom mreže i diska.

Koje su druge mogućnosti dostupne s In-Memory i kakav je to pristup? Vladimir Pligin - inženjer u GridGainu. Ovaj pregledni materijal bit će koristan pozadinskim programerima web aplikacija koji nisu radili s In-Memory i žele isprobati ili su zainteresirani za suvremene trendove u razvoju softvera i dizajnu arhitekture.

Primijetiti. Članak se temelji na transkriptu Vladimirovog izvješća na #GetIT Conf. Prije uvođenja samoizolacije, redovito smo održavali susrete i konferencije za programere u Moskvi i Sankt Peterburgu: razgovarali smo o trendovima, aktualnim razvojnim problemima, problemima i njihovim rješenjima. Sada nije moguće održati konferenciju, ali vrijeme je da podijelite korisne materijale s prošlih.

Tko i kako koristi In-Memory

In-Memory se najčešće koristi tamo gdje je potrebna brza interakcija korisnika ili obrada velikih količina podataka.

• Banke koristite In-Memory, na primjer, za smanjenje kašnjenja kada klijenti koriste aplikacije ili za analizu klijenta prije izdavanja kredita.
• Finteh koristi In-Memory za poboljšanje performansi usluga i aplikacija za banke koje eksternaliziraju obradu podataka i analizu. 
• Osiguravajuća društva: za izračunavanje rizika, na primjer, analizom podataka o kupcima tijekom nekoliko godina.
• Logističke tvrtke. Obrađuju mnoštvo podataka, primjerice, za izračunavanje optimalnih ruta za teretni i putnički prijevoz s tisućama parametara i praćenje statusa pošiljaka.
• Maloprodaja. In-Memory rješenja pomažu u bržem usluživanju kupaca i obradi velikih količina informacija: pošiljke, fakture, transakcije, prisutnost tisuća roba u skladištima i pripremaju analitička izvješća.
• В IOT In-Memory zamjenjuje tradicionalne baze podataka.
• Farmaceutski tvrtke koriste In-Memory, na primjer, za sortiranje kombinacija sastava lijekova. 

Reći ću vam nekoliko primjera kako naši klijenti koriste In-Memory rješenja i kako ih sami možete implementirati.

In-Memory kao primarna pohrana

Jedan od naših klijenata je veliki dobavljač medicinske znanstvene opreme iz SAD-a. Kao glavnu pohranu podataka koriste In-Memory rješenje. Svi podaci pohranjuju se na disk, a podskup podataka koji se aktivno koristi čuva se u RAM-u. Metode pristupa pohrani su standardne - GDBC (Generic Database Connector) i SQL upitni jezik.

Zajedno se to naziva In-Memory Database (IMDB) ili Memory-Centric Storage. Ova klasa rješenja ima mnogo imena, ali ovo nisu jedina. 

Značajke IMDB-a:

• Podaci koji su pohranjeni u In-Memory i kojima se pristupa kroz SQL isti su kao i u drugim pristupima. One su sinkronizirane, samo je način prezentacije, način obraćanja drugačiji. Transakcionalnost funkcionira između podataka.

• IMDB je brži od relacijskih baza podataka jer je brži za dohvaćanje informacija iz RAM-a nego s diska. 
• Algoritmi interne optimizacije imaju manje uputa.
• IMDB-ovi su prikladni za upravljanje podacima, događajima i transakcijama u aplikacijama.

IMDB djelomično podržava ACID: Atomicity, Consistency, and Isolation. Ali ne podržavaju "trajnost" - kada se napajanje isključi, svi se podaci gube. Da biste riješili problem, možete koristiti snapshots - "snimak" baze podataka, analogno sigurnosnoj kopiji baze podataka na tvrdom disku, ili zabilježiti transakcije (dnevnike) za vraćanje podataka nakon ponovnog pokretanja.

Za izradu aplikacija otpornih na greške

Zamislimo klasičnu arhitekturu web aplikacije otporne na greške. Funkcionira ovako: svi zahtjevi se distribuiraju web balanserom između poslužitelja. Ovaj sustav je stabilan jer se poslužitelji međusobno dupliciraju i stvaraju sigurnosne kopije u slučaju incidenata.

Balanser usmjerava sve zahtjeve iz jedne sesije striktno na jedan poslužitelj. Ovo je mehanizam stick sesije: svaka je sesija povezana s poslužiteljem gdje se lokalno pohranjuje i obrađuje. 

Što se događa kada jedan od poslužitelja zakaže?

Usluga neće biti pogođena jer je arhitektura duplicirana. Ali izgubit ćemo podskup sesija mrtvog poslužitelja. I u isto vrijeme, korisnici koji su vezani za te sesije. Na primjer, klijent naruči i iznenada ga izbaci iz ureda. Bit će nesretan kad se ponovno prijavi i ustanovi da će sve morati učiniti ponovno.

Web aplikacija mora podržavati veliki broj korisnika i ne usporavati kako bi mogli ugodno raditi. Ali ako se odbije, sa svakim sljedećim zahtjevom vrijeme potrebno za komunikaciju sa pohranom sesije će se povećavati. Ovo povećava prosječnu latenciju za druge korisnike. Ali ne žele čekati više nego što su navikli.

Ovaj problem se može riješiti kao i naš drugi klijent, veliki PASS provider iz SAD-a. Koristi In-Memory za grupiranje web sesija. Da bi to učinio, ne pohranjuje ih lokalno, već centralno - u In-Memory klaster. U ovom slučaju, sesije su dostupne mnogo brže jer su već u RAM-u.

Kada se poslužitelj sruši, balanser šalje zahtjeve s srušenog poslužitelja drugim poslužiteljima, kao u klasičnoj arhitekturi. Ali postoji bitna razlika: sesije su pohranjene u In-Memory cluster a poslužitelji imaju pristup sesijama palog poslužitelja.

Ovakva arhitektura povećava otpornost na pogreške cijelog sustava. Štoviše, moguće je u potpunosti napustiti mehanizam stick sesije.

Hibridna transakcijska analitička obrada (HTAP)

Obično se transakcijski i analitički sustavi drže odvojeno. Kada se odvoje, glavna baza dolazi pod opterećenje. Za analitičku obradu podaci se kopiraju u repliku tako da analitička obrada ne ometa transakcijske procese. Ali kopiranje se događa s odgodom — nemoguće je replicirati bez odgode. Ako to radimo sinkrono, to će također usporiti glavnu bazu i nećemo dobiti nikakve dobitke.

U HTAP-u sve funkcionira drugačije - ista pohrana podataka koristi se za transakcijsko opterećenje aplikacija i za analitičke upite koji mogu dugo trajati. Kada su podaci u RAM-u, analitički upiti se brže izvršavaju, a poslužitelj s bazom manje je opterećen (u prosjeku).

Hibridni pristup ruši zid između obrade transakcija i analitike. Ako provodimo analitiku na istoj pohrani, tada se analitički upiti pokreću na podacima iz RAM-a. Puno su točniji, razumljiviji i adekvatniji.

Integracija In-Memory rješenja

(Relativno) jednostavan način - razviti sve od nule. Čuvamo podatke na disku i spremamo vruće podatke u memoriju. To pomaže preživjeti ponovno pokretanje poslužitelja ili prekid rada.

Ovdje postoje dva glavna scenarija kada se podaci pohranjuju na disk. U prvom, želimo preživjeti padove ili redovita ponovna pokretanja klastera ili dijelova - želimo ga koristiti kao jednostavnu bazu podataka. U drugom scenariju, kada ima previše podataka, neki od njih su u memoriji.

Ako nije moguće izgraditi sve od nule, moguće je integrirati In-Memory u već postojeća arhitektura. Ali nisu sva In-Memory rješenja prikladna za to. Postoje tri obvezna uvjeta. In-Memory rješenje mora podržavati:

• standardni način povezivanja s bazom podataka koja će se nalaziti ispod njega (na primjer, MySQL);
• standardni jezik upita, kako ne bi prepisivali i mijenjali logiku interakcije s pohranom;
• transakcijski – čuvaju semantiku interakcije.

Ako su ispunjena sva tri uvjeta, integracija je moguća. In-Memory Data Grid postavljamo između aplikacije i baze podataka. Sada će zahtjevi za pisanje biti delegirani osnovnoj bazi podataka, a zahtjevi za čitanje će biti delegirani osnovnoj bazi podataka ako podaci nisu u predmemorij.

Ako vam je važan brz pristup podacima i njihova obrada, primjerice za poslovnu analitiku, možete razmisliti o implementaciji In-Memory-a. A za implementaciju, možete koristiti obje metode pri projektiranju nove arhitekture.

Izvor: www.habr.com