In-Memory este un set de concepte pentru stocarea datelor atunci când acestea sunt stocate în RAM-ul aplicației, iar discul este folosit pentru backup. În abordările clasice, datele sunt stocate pe disc, iar memoria este stocată în cache. De exemplu, o aplicație web cu un backend pentru procesarea datelor le solicită în stocare: o primește, o transformă și o mulțime de date sunt transferate prin rețea. În In-Memory, calculele sunt trimise către date - către stocare, unde sunt procesate și rețeaua este mai puțin încărcată.
Ce alte posibilități sunt disponibile cu In-Memory și ce fel de abordare este aceasta? Vladimir Pligin - inginer la GridGain. Acest material de revizuire va fi util dezvoltatorilor de aplicații web backend care nu au lucrat cu In-Memory și doresc să încerce sau sunt interesați de tendințele moderne în dezvoltarea de software și designul arhitecturii.
Nota. Articolul se bazează pe transcrierea raportului lui Vladimir la #GetIT Conf. Înainte de introducerea autoizolării, am organizat în mod regulat întâlniri și conferințe pentru dezvoltatori la Moscova și Sankt Petersburg: am discutat despre tendințe, probleme actuale de dezvoltare, probleme și soluțiile acestora. Nu este posibil să ținem o conferință acum, dar este timpul să împărtășim materiale utile din cele din trecut.
Cine folosește In-Memory și cum
In-Memory este folosit cel mai adesea acolo unde este necesară interacțiunea rapidă a utilizatorului sau procesarea unor cantități mari de date.
- Băncile utilizați In-Memory, de exemplu, pentru a reduce întârzierile atunci când clienții folosesc aplicații sau pentru a analiza clientul înainte de a acorda un împrumut.
- Fintech folosește In-Memory pentru a îmbunătăți performanța serviciilor și aplicațiilor pentru băncile care externalizează procesarea și analiza datelor.
- Firme de asigurari: pentru a calcula riscurile, de exemplu, prin analiza datelor clienților pe mai mulți ani.
- Firme de logistică. Ei procesează o mulțime de date, de exemplu, pentru a calcula rute optime pentru transportul de mărfuri și pasageri cu mii de parametri și pentru a urmări starea transporturilor.
- Cu amănuntul. Soluțiile In-Memory ajută la deservirea mai rapidă a clienților și la procesarea unor volume mari de informații: expedieri, facturi, tranzacții, prezența a mii de mărfuri în depozite și pregătirea de rapoarte analitice.
- В IoT In-Memory înlocuiește bazele de date tradiționale.
- Farmaceutic companiile folosesc In-Memory, de exemplu, pentru a sorta combinațiile de compoziții de medicamente.
Vă voi spune câteva exemple despre modul în care clienții noștri folosesc soluțiile In-Memory și cum le puteți implementa singur.
În memorie ca stocare principală
Unul dintre clienții noștri este un mare furnizor de echipamente medicale științifice din SUA. Ei folosesc o soluție în memorie ca stocare principală a datelor. Toate datele sunt stocate pe disc, iar subsetul de date care este utilizat în mod activ este păstrat în RAM. Metodele de acces la stocare sunt standard - GDBC (Generic Database Connector) și limbajul de interogare SQL.
În mod colectiv, aceasta se numește bază de date în memorie (IMDB) sau stocare centrată pe memorie. Această clasă de soluții are multe nume, acestea nu sunt singurele.
Caracteristici IMDB:
- Datele care sunt stocate în memorie și accesate prin SQL sunt aceleași ca în alte abordări. Sunt sincronizate, doar modul de prezentare, modul de a le adresa este diferit. Tranzacționalitatea funcționează între date.
- IMDB este mai rapid decât bazele de date relaționale, deoarece este mai rapid pentru a prelua informații din RAM decât de pe disc.
- Algoritmii interni de optimizare au mai puține instrucțiuni.
- IMDB-urile sunt potrivite pentru gestionarea datelor, evenimentelor și tranzacțiilor în aplicații.
IMDB-urile suportă parțial ACID: Atomicity, Consistency, and Isolation. Dar nu acceptă „durabilitate” - atunci când alimentarea este oprită, toate datele se pierd. Pentru a rezolva problema, puteți utiliza instantanee - un „instantaneu” al bazei de date, similar cu o copie de rezervă a bazei de date pe un hard disk sau puteți înregistra tranzacții (jurnale) pentru a restaura datele după o repornire.
Pentru a crea aplicații tolerante la erori
Să ne imaginăm arhitectura clasică a unei aplicații web tolerante la erori. Funcționează astfel: toate cererile sunt distribuite de un echilibrator web între servere. Acest sistem este stabil deoarece serverele se dublează între ele și fac backup în caz de incidente.
Echilibratorul direcționează toate cererile de la o sesiune strict către un singur server. Acesta este un mecanism de sesiune stick: fiecare sesiune este asociată cu un server unde este stocată și procesată local.
Ce se întâmplă când unul dintre servere eșuează?
Serviciul nu va fi afectat deoarece arhitectura este duplicată. Dar vom pierde un subset de sesiuni ale serverului mort. Și, în același timp, utilizatorii care sunt legați de aceste sesiuni. De exemplu, un client plasează o comandă și îl dă brusc afară din birou. Va fi nemulțumit când se va conecta din nou și va constata că totul va trebui făcut din nou.
O aplicație web este necesară pentru a sprijini un număr mare de utilizatori și pentru a nu încetini, astfel încât aceștia să poată lucra confortabil. Dar dacă este refuzată, cu fiecare solicitare ulterioară, timpul necesar pentru a comunica cu magazinul de sesiuni va crește. Acest lucru crește latența medie pentru alți utilizatori. Dar ei nu vor să aștepte mai mult decât sunt obișnuiți.
Această problemă poate fi rezolvată ca și celălalt client al nostru, un mare furnizor PASS din SUA. Utilizează In-Memory pentru a grupa sesiunile web. Pentru a face acest lucru, le stochează nu local, ci central - într-un cluster în memorie. În acest caz, sesiunile sunt disponibile mult mai rapid deoarece sunt deja în RAM.
Când un server se prăbușește, echilibrerul trimite cereri de la serverul blocat către alte servere, ca în arhitectura clasică. Dar există o diferență importantă: sesiunile sunt stocate într-un cluster în memorie iar serverele au acces la sesiunile serverului căzut.
Această arhitectură mărește toleranța la erori a întregului sistem. Mai mult, este posibil să renunți cu totul la mecanismul sesiunii stick.
Procesare analitică tranzacțională hibridă (HTAP)
De obicei, sistemele tranzacționale și analitice sunt ținute separate. Când se separă, baza principală intră sub sarcină. Pentru procesarea analitică, datele sunt copiate într-o replică, astfel încât procesarea analitică să nu interfereze cu procesele tranzacționale. Dar copierea are loc cu un decalaj - este imposibil de replicat fără un decalaj. Dacă facem acest lucru sincron, va încetini și baza principală și nu vom obține niciun câștig.
În HTAP, totul funcționează diferit - același depozit de date este utilizat pentru încărcarea tranzacțională din aplicații și pentru interogări analitice care pot dura mult timp pentru a se finaliza. Când datele sunt în RAM, interogările analitice sunt executate mai rapid, iar serverul cu baza de date este mai puțin încărcat (în medie).
O abordare hibridă sparge zidul dintre procesarea tranzacțiilor și analiză. Dacă efectuăm analize pe aceeași stocare, atunci se lansează interogări analitice pe datele din RAM. Sunt mult mai precise, mai interpretabile și mai adecvate.
Integrarea solutiilor In-Memory
O modalitate (relativ) simplă - dezvolta totul de la zero. Păstrăm datele pe disc și stocăm datele fierbinți în memorie. Acest lucru ajută la supraviețuirea repornirilor sau întreruperilor de server.
Există două scenarii principale la lucru aici când datele sunt stocate pe disc. În primul, vrem să supraviețuim blocărilor sau repornirilor regulate ale clusterului sau ale părților - vrem să-l folosim ca bază de date simplă. În al doilea scenariu, când există prea multe date, unele dintre ele sunt în memorie.
Dacă nu este posibil să construiți totul de la zero, este posibil să integrați In-Memory într-un arhitectura existenta. Dar nu toate soluțiile In-Memory sunt potrivite pentru asta. Există trei condiții obligatorii. Soluția în memorie trebuie să accepte:
- modalitate standard de conectare la baza de date care va fi situată sub ea (de exemplu, MySQL);
- un limbaj de interogare standard, pentru a nu rescrie și schimba logica interacțiunii cu stocarea;
- tranzacționale - păstrează semantica interacțiunii.
Dacă sunt îndeplinite toate cele trei condiții, atunci integrarea este posibilă. Plasăm grila de date în memorie între aplicație și baza de date. Acum cererile de scriere vor fi delegate bazei de date de bază, iar cererile de citire vor fi delegate bazei de date de bază dacă datele nu sunt în cache.
Dacă accesul rapid la date și procesarea acestora este important pentru dvs., de exemplu, pentru analiza de afaceri, vă puteți gândi la implementarea In-Memory. Și pentru implementare, puteți utiliza ambele metode atunci când proiectați o nouă arhitectură.
Sursa: www.habr.com