In-Memory është një grup konceptesh për ruajtjen e të dhënave kur ato ruhen në RAM-in e aplikacionit dhe disku përdoret për kopje rezervë. Në qasjet klasike, të dhënat ruhen në disk dhe memoria ruhet në cache. Për shembull, një aplikacion ueb me një backend për përpunimin e të dhënave i kërkon ato në ruajtje: ai e merr atë, e transformon atë dhe shumë të dhëna transferohen në rrjet. Në Memory, llogaritjet dërgohen te të dhënat - në ruajtje, ku përpunohen dhe rrjeti është më pak i ngarkuar.
Cilat mundësi të tjera janë të disponueshme me In-Memory dhe çfarë lloj qasjeje është kjo? Vladimir Pligin - inxhinier në GridGain. Ky material rishikimi do të jetë i dobishëm për zhvilluesit e aplikacioneve në ueb që nuk kanë punuar me In-Memory dhe duan të provojnë ose janë të interesuar për tendencat moderne në zhvillimin e softuerit dhe dizajnin e arkitekturës.
Shënim. Artikulli bazohet në transkriptin e raportit të Vladimirit në #GetIT Conf. Para futjes së izolimit, ne organizonim rregullisht takime dhe konferenca për zhvilluesit në Moskë dhe Shën Petersburg: diskutuam tendencat, çështjet aktuale të zhvillimit, problemet dhe zgjidhjet e tyre. Nuk është e mundur të mbahet një konferencë tani, por është koha për të ndarë materiale të dobishme nga ato të kaluara.
Kush e përdor In-Memory dhe si
In-Memory përdoret më shpesh aty ku kërkohet ndërveprimi i shpejtë i përdoruesit ose përpunimi i sasive të mëdha të të dhënave.
- Bankat përdorni In-Memory, për shembull, për të reduktuar vonesat kur klientët përdorin aplikacione ose për të analizuar klientin përpara se të lëshojnë një kredi.
- Fintech përdor In-Memory për të përmirësuar performancën e shërbimeve dhe aplikacioneve për bankat që japin përpunimin dhe analizën e të dhënave.
- Kompanitë e sigurimit: për të llogaritur rreziqet, për shembull, duke analizuar të dhënat e klientëve gjatë disa viteve.
- Kompanitë e logjistikës. Ata përpunojnë shumë të dhëna, për shembull, për të llogaritur rrugët optimale për transportin e mallrave dhe pasagjerëve me mijëra parametra dhe për të gjurmuar statusin e dërgesave.
- Shitje me pakicë. Zgjidhjet në memorie ndihmojnë për t'i shërbyer klientëve më shpejt dhe për të përpunuar vëllime të mëdha informacioni: dërgesa, fatura, transaksione, prania e mijëra mallrave në magazina dhe përgatitja e raporteve analitike.
- В IOT In-Memory zëvendëson bazat e të dhënave tradicionale.
- Farmaceutike kompanitë përdorin In-Memory, për shembull, për të renditur kombinimet e përbërjeve të barnave.
Unë do t'ju tregoj disa shembuj se si klientët tanë përdorin zgjidhjet In-Memory dhe si mund t'i zbatoni ato vetë.
Në memorie si memorie kryesore
Një nga klientët tanë është një furnizues i madh i pajisjeve mjekësore shkencore nga SHBA. Ata përdorin një zgjidhje In-Memory si ruajtjen e tyre kryesore të të dhënave. Të gjitha të dhënat ruhen në disk dhe nëngrupi i të dhënave që përdoret në mënyrë aktive ruhet në RAM. Metodat standarde të aksesit të ruajtjes janë GDBC (Generic Database Connector) dhe gjuha e pyetjes SQL.
Së bashku kjo quhet Baza e të Dhënave In-Memory (IMDB) ose Memory-Centric Storage. Kjo klasë zgjidhjesh ka shumë emra, këta nuk janë të vetmit.
Karakteristikat e IMDB:
- Të dhënat që ruhen në Memory dhe aksesohen përmes SQL janë të njëjta si në qasjet e tjera. Ato janë të sinkronizuara, vetëm mënyra e paraqitjes, mënyra e adresimit të tyre është e ndryshme. Transaksionaliteti funksionon ndërmjet të dhënave.
- IMDB është më i shpejtë se bazat e të dhënave relacionale sepse është më i shpejtë për të marrë informacion nga RAM sesa nga disku.
- Algoritmet e optimizimit të brendshëm kanë më pak udhëzime.
- IMDB-të janë të përshtatshme për menaxhimin e të dhënave, ngjarjeve dhe transaksioneve në aplikacione.
IMDB-të mbështesin pjesërisht ACID: Atomiciteti, Konsistenca dhe Izolimi. Por ata nuk mbështesin "qëndrueshmërinë" - kur fikni energjinë, të gjitha të dhënat humbasin. Për të zgjidhur problemin, mund të përdorni fotografitë - një "fotografi" e bazës së të dhënave, analoge me një kopje rezervë të bazës së të dhënave në një hard disk, ose të regjistroni transaksione (regjistrat) për të rivendosur të dhënat pas një rindezjeje.
Për të krijuar aplikacione tolerante ndaj gabimeve
Le të imagjinojmë arkitekturën klasike të një aplikacioni ueb tolerant ndaj gabimeve. Ajo funksionon si kjo: të gjitha kërkesat shpërndahen nga një balancues në internet midis serverëve. Ky sistem është i qëndrueshëm sepse serverët kopjojnë njëri-tjetrin dhe bëjnë kopje rezervë në rast incidentesh.
Balancuesi drejton të gjitha kërkesat nga një seancë në mënyrë rigoroze në një server. Ky është një mekanizëm i sesionit ngjitës: çdo sesion shoqërohet me një server ku ruhet dhe përpunohet në nivel lokal.
Çfarë ndodh kur një nga serverët dështon?
Shërbimi nuk do të ndikohet sepse arkitektura është e dyfishuar. Por ne do të humbasim një nëngrup të seancave të serverit të vdekur. Dhe në të njëjtën kohë, përdoruesit që janë të lidhur me këto seanca. Për shembull, një klient bën një porosi dhe befas e nxjerr nga zyra. Ai do të jetë i pakënaqur kur të regjistrohet përsëri dhe të zbulojë se gjithçka do të duhet të bëhet përsëri.
Kërkohet një aplikacion në internet për të mbështetur një numër të madh përdoruesish dhe për të mos ngadalësuar në mënyrë që ata të mund të punojnë rehat. Por nëse refuzohet, me çdo kërkesë të mëpasshme koha që duhet për të komunikuar me dyqanin e sesioneve do të rritet. Kjo rrit vonesën mesatare për përdoruesit e tjerë. Por ata nuk duan të presin më shumë nga sa janë mësuar.
Ky problem mund të zgjidhet si klienti ynë tjetër, një ofrues i madh PASS nga SHBA. Ai përdor In-Memory për të grumbulluar seancat në ueb. Për ta bërë këtë, ai i ruan ato jo në nivel lokal, por në qendër - në një grupim In-Memory. Në këtë rast, seancat janë të disponueshme shumë më shpejt sepse ato janë tashmë në RAM.
Kur një server prishet, balancuesi dërgon kërkesa nga serveri i dëmtuar në serverë të tjerë, si në arkitekturën klasike. Por ka një ndryshim të rëndësishëm: seancat ruhen në një grup në memorie dhe serverët kanë qasje në sesionet e serverit të rënë.
Kjo arkitekturë rrit tolerancën ndaj gabimeve të të gjithë sistemit. Për më tepër, është e mundur të braktisësh plotësisht mekanizmin e sesionit të shkopit.
Përpunimi analitik i transaksioneve hibride (HTAP)
Në mënyrë tipike, sistemet transaksionale dhe analitike mbahen të ndara. Kur ato ndahen, baza kryesore vjen nën ngarkesë. Për përpunimin analitik, të dhënat kopjohen në një kopje në mënyrë që përpunimi analitik të mos ndërhyjë në proceset transaksionale. Por kopjimi ndodh me një vonesë - është e pamundur të përsëritet pa vonesë. Nëse e bëjmë këtë në mënyrë sinkrone, do të ngadalësojë gjithashtu bazën kryesore dhe nuk do të marrim asnjë fitim.
Në HTAP, gjithçka funksionon ndryshe - i njëjti dyqan të dhënash përdoret për ngarkesën e transaksioneve nga aplikacionet dhe për pyetjet analitike që mund të kërkojnë shumë kohë për t'u përfunduar. Kur të dhënat janë në RAM, pyetjet analitike ekzekutohen më shpejt, dhe serveri me bazën e të dhënave është më pak i ngarkuar (mesatarisht).
Një qasje hibride thyen murin midis përpunimit të transaksioneve dhe analitikës. Nëse kryejmë analitikë në të njëjtën ruajtje, atëherë pyetjet analitike hapen në të dhënat nga RAM. Ato janë shumë më të sakta, më të interpretueshme dhe adekuate.
Integrimi i zgjidhjeve në memorie
Një mënyrë (relativisht) e thjeshtë - zhvilloni gjithçka nga e para. Ne mbajmë të dhëna në disk dhe ruajmë të dhëna të nxehta në memorie. Kjo ndihmon për të mbijetuar rindezjet ose ndërprerjet e serverit.
Ka dy skenarë kryesorë në punë këtu kur të dhënat ruhen në disk. Në të parën, ne duam t'i mbijetojmë përplasjeve ose rindezjeve të rregullta të grupit ose pjesëve - ne duam ta përdorim atë si një bazë të dhënash të thjeshtë. Në skenarin e dytë, kur ka shumë të dhëna, disa prej tyre janë në memorie.
Nëse nuk është e mundur të ndërtohet gjithçka nga e para, është e mundur të integrohet In-Memory në një tashmë arkitekturës ekzistuese. Por jo të gjitha zgjidhjet In-Memory janë të përshtatshme për këtë. Janë tre kushte të detyrueshme. Zgjidhja In-Memory duhet të mbështesë:
- mënyra standarde për t'u lidhur me bazën e të dhënave që do të gjendet nën të (për shembull, MySQL);
- një gjuhë standarde e pyetjeve, në mënyrë që të mos rishkruhet dhe ndryshohet logjika e ndërveprimit me ruajtjen;
- transaksionale - ruaj semantikën e ndërveprimit.
Nëse plotësohen të tre kushtet, atëherë integrimi është i mundur. Ne vendosim Rrjetin e të Dhënave In-Memory midis aplikacionit dhe bazës së të dhënave. Tani kërkesat për shkrim do të delegohen në bazën e të dhënave bazë, dhe kërkesat për leximin do të delegohen në bazën e të dhënave bazë nëse të dhënat nuk janë në cache.
Nëse aksesi i shpejtë në të dhëna dhe përpunimi i tyre është i rëndësishëm për ju, për shembull, për analitikën e biznesit, mund të mendoni për zbatimin e In-Memory. Dhe për zbatim, mund të përdorni të dyja metodat kur hartoni një arkitekturë të re.
Burimi: www.habr.com