In-Memory â njĂ« grumbull konceptesh pĂ«r ruajtjen e tĂ« dhĂ«nave, kur ato ruhen nĂ« memorien ĐŸĐżĐ”ŃĐ°ŃĐžĐČĐ” tĂ« aplikacionit, ndĂ«rsa disku pĂ«rdoret pĂ«r backup. NĂ« qasjet klasike, tĂ« dhĂ«nat ruhen nĂ« disk, ndĂ«rsa memoria shĂ«rben si cache. PĂ«r shembull, njĂ« aplikacion web me backend pĂ«r pĂ«rpunimin e tĂ« dhĂ«nave kĂ«rkon ato nĂ« magazinĂ«: merr, transformon, dhe shpĂ«rndan shumĂ« tĂ« dhĂ«na nĂ«pĂ«r rrjet. NĂ« In-Memory, llogaritjet dĂ«rgohen te tĂ« dhĂ«nat â nĂ« magazinĂ«, ku ato pĂ«rpunohen dhe rrjeti ngarkohet mĂ« pak.
Cilat mundĂ«si tĂ« tjera janĂ« tĂ« disponueshme me In-Memory dhe çfarĂ« Ă«shtĂ« kjo qasje, do t'i tregojĂ« Vladimir Pligin â inxhinier i kompanisĂ« GridGain. Ky material informativ do tĂ« jetĂ« i dobishĂ«m pĂ«r zhvilluesit e backend-it tĂ« aplikacioneve web, tĂ« cilĂ«t nuk kanĂ« punuar me In-Memory dhe dĂ«shirojnĂ« tĂ« provojnĂ«, ose janĂ« tĂ« interesuar pĂ«r trendet moderne nĂ« zhvillimin e zgjidhjeve softuerike dhe projektimin e arkitekturĂ«s.
Shënim. Artikulli është i bazuar në transkriptin e një diskutimi nga Vladimir në konferencën #GetIT Conf. Para përjashtimit për shkak të vetë-izolimit, ne rregullisht organizonim mitape dhe konferenca për zhvillues në Moskë dhe Shën Petersburg: diskutonim trendet, pyetje aktuale në zhvillim, probleme dhe zgjidhjet e tyre. Tani, nuk mund të organizojmë konferenca, por është koha për të ndarë materiale të dobishme nga e kaluara.
Kush dhe si përdor In-Memory
In-Memory përdoret më shpesh aty ku kërkohet interaksion i shpejtë me përdoruesin ose përpunimi i sasisë së madhe të të dhënave.
- Bankat përdorin In-Memory, për shembull, për të reduktuar vonesat gjatë përdorimit nga klientët e aplikacioneve ose për të analizuar klientin para dhënies së një kredie.
- Fintech pĂ«rdor In-Memory pĂ«r tĂ« pĂ«rmirĂ«suar performancĂ«n e shĂ«rbimeve dhe aplikacioneve pĂ«r bankat, tĂ« cilat jashtĂ«sojnĂ« pĂ«rpunimin dhe analizĂ«n e tĂ« dhĂ«nave.Â
- Kompani sigurimi: për llogaritjen e rreziqeve, për shembull, duke analizuar të dhënat e klientëve për disa vite.
- Kompani logjistike. Ato përpunojnë shumë të dhëna, për shembull, për të llogaritur rrugët optimale për transportin e ngarkesave dhe pasagjerëve me mijëra parametrash, për të ndjekur statusin e dërgesave.
- Retail. Zgjidhjet In-Memory ndihmojnë për të shërbyer më shpejt klientët dhe për të procesuar sasi të mëdha informacioni: dërgesat, faturat, transaksionet, disponueshmërinë e mijëra produkteve në magazina, për të përgatitur raportet analitike.
- Në IoT In-Memory zëvendëson DB-të tradicionale.
- Kompani farmacautike pĂ«rdorin In-Memory, pĂ«r shembull, pĂ«r tĂ« kontrolluar kombinimet e pĂ«rbĂ«rĂ«sve tĂ« ilaçeve.Â
Unë do të tregoj disa shembuj se si klientët tanë përdorin zgjidhjet In-Memory dhe si mund t'i miratojnë ato në kompaninë e tyre.
In-Memory si ruajtja kryesore
NjĂ« nga klientĂ«t tanĂ« Ă«shtĂ« njĂ« furnizues i madh i pajisjeve shkencore mjekĂ«sore nga SHBA. Ata pĂ«rdorin zgjidhjen In-Memory si ruajtjen kryesore tĂ« tĂ« dhĂ«nave. TĂ« gjitha tĂ« dhĂ«nat ruhen nĂ« disk, ndĂ«rsa njĂ« nĂ«nsasi e tĂ« dhĂ«nave qĂ« pĂ«rdoret shumĂ« ruhen nĂ« memorien operative. Metodat e qasjes nĂ« magazinĂ« janĂ« standarde â GDBC (Generic Database Connector) dhe gjuha e pyetjeve SQL.
Kjo e gjithĂ« quhet In-Memory Database (IMDB) ose Memory-Centric Storage. Ky klas zgjidhjesh ka shumĂ« emra, kĂ«to nuk janĂ« tĂ« vetmet.Â
Karakteristikat e IMDB:
- Të dhënat që ruhen në In-Memory dhe janë të aksesueshme nëpërmjet SQL janë të njëjtat si në qasjet e tjera. Ato janë të sinkronizuara, ndryshon vetëm mënyra e paraqitjes dhe mënyra se si mund t'i aksesoni. Midis të dhënave funksionon transaksionaliteti.
- IMDB Ă«shtĂ« mĂ« e shpejtĂ« se DB-tĂ« relacionale, sepse tĂ« nxjerrĂ«sh informacion nga memoria ĐŸĐżĐ”ŃĐ°ŃĐžĐČe Ă«shtĂ« mĂ« e shpejtĂ« se sa nga disku.Â
- Algoritmet e brendshme të optimizimit kanë më pak instrukcione.
- IMDB janë të përshtatshme për menaxhimin e të dhënave, ngjarjeve dhe transaksioneve në aplikacione.
IMDB mbĂ«shtesin pjesĂ«risht ACID: atomikshmĂ«rinĂ«, koherencĂ«n dhe izolimin, por nuk mbĂ«shtesin 'pĂ«rjetĂ«sinĂ«' â nĂ«se ndalon energjia, tĂ« dhĂ«nat humbasin. PĂ«r tĂ« zgjidhur kĂ«tĂ« problem, mund tĂ« pĂ«rdoren snapshots â 'tĂ« dhĂ«na' tĂ« bazĂ«s sĂ« tĂ« dhĂ«nave, njĂ« ekuivalent me backup-in e DB nĂ« diskun e ngurtĂ«, ose pĂ«r tĂ« regjistruar transaksionet (logĂ«t), pĂ«r tĂ« rikuperuar tĂ« dhĂ«nat pas rindezjes.
Për krijimin e aplikacioneve të qëndrueshme
Le ta përshkruajmë arkitekturën klasike të një aplikacioni të qëndrueshëm në rast të dështimit. Ajo funksionon kështu: të gjitha kërkesat shpërndahen nga balancuesi i web-it midis serverëve. Ky sistem është i qëndrueshëm, sepse serverët duplifikojnë njëri-tjetrin dhe mbrojnë njëri-tjetrin gjatë incidenteve.
Balancuesi drejton tĂ« gjitha kĂ«rkesat nga njĂ« sesion ngushtĂ«sisht nĂ« njĂ« server tĂ« vetĂ«m. Ky Ă«shtĂ« njĂ« mekanizĂ«m i sesioneve tĂ« ngjitur: çdo sesion lidhet me server, nĂ« tĂ« cilin ajo ruhet dhe pĂ«rpunohet lokalmente.Â
ĂfarĂ« do tĂ« ndodhĂ« kur njĂ« nga servera?
shërbimet dështon, pasi arkitektura është e dyfishuar. Por do të humbasim një nënset të sesioneve të serverit të vdekur. Dhe gjithashtu përdoruesit që janë të lidhur me këto seanca. Për shembull, një klient bën një porosi dhe papritur e përjashton nga llogaria e tij. Ai do të jetë i pakënaqur kur të regjistrohet përsëri dhe të zbulojë se duhet ta bëjë sërish porosinë.
Një aplikacion web kërkohet të mbajë një numër të madh përdoruesish dhe të mos "ngadalësohet" që të jetë rehat për ta punuar. Por në rast dështimi, me çdo kërkesë të re, koha e komunikimit me ruajtjen e sesioneve do të rritet. Kjo e rrit vonesën mesatare (latency) për përdoruesit e tjerë. Por ata nuk duan të presin më shumë se ç'e kanë zakon.
Ky problem mund të zgjidhet, si një klient tjetër i yni - një ofrues i madh të PASS-eve nga SHBA. Ai përdor In-Memory për të grumbulluar sesionet web. Për këtë, ai i ruan ato jo lokal, por në një klasë In-Memory. Në këtë rast, sesionet janë shumë më të shpejta për t'u aksesuar, pasi ato janë tashmë në memorien operative.
Kur serveri dështon, balancuesi dërgon kërkesat e dështuar në servera të tjerë, ashtu si në arkitekturën klasike. Por ka një ndryshim të rëndësishëm: sesionet ruhet në klasën In-Memory dhe serverët kanë qasje në sesionet e serverit të dështuar.
Kjo arkitekturë rrit qëndrueshmërinë e gjithë sistemit. Për më tepër, është e mundur të hiqet krejtësisht mekanizmi i sesioneve të ngjitura.
PĂ«rpunimi hibrid tranzaksional-analitik (HTAP)
Zakonisht, sistemet tranzaksionale dhe analitike mbahen veçmas. Kur ato ndahen, ngarkesa bie mbi bazën primare. Për përpunimin analitik, të dhënat kopjohen në një replikë, në mënyrë që përpunimi analitik të mos pengojë proceset tranzaksionale. Por kopjimi ndodh me vonesë - pa vonesë, replikimi nuk është i mundur. Nëse e bëjmë këtë në mënyrë sinkrone, do të ngadalësojë gjithashtu bazën primare dhe nuk do të kemi fitime.
Në HTAP, gjithçka funksionon ndryshe - e njëjta ruajtje të dhënash përdoret për ngarkesat tranzaksionale nga aplikacionet dhe për kërkesat analitike, të cilat mund të zgjasin. Kur të dhënat janë në memorien operative, kërkesat analitike ekzekutohen më shpejt, dhe serveri me bazë të dhënash ngarkohet më pak (në mesatare).
Qasja hibride "thyhet muri" midis përpunimit të tranzaksioneve dhe analizës. Nëse ne kryejmë analizën në të njëjtën ruajtje, kërkesat analitike do të nisin në të dhënat nga memorja operative. Ato janë shumë më të sakta, më të interpretueshme dhe më të arsyeshme.
Integrimi i zgjidhjeve In-Memory
Një mënyrë e thjeshtë (relativisht) është të zhvillosh gjithçka nga e para. Ne mbajmë të dhënat në disk, ndërsa ato që janë të nxehta i mbajmë në memorie. Kjo ndihmon në përballimin e ri-ngarkimeve të serverëve ose ndërprerjeve.
Këtu punojnë dy skenarë kryesorë, kur të dhënat ruhen në disk. Në të parin, ne duam të përballojmë rëniet ose ri-ngarkimet e zakonshme të klasës ose pjesë të saj - duam ta përdorim si një bazë të thjeshtë të dhënash. Në skenarin e dytë, kur të dhënat janë shumë, një pjesë e tyre ruhet në memorie.
Nëse nuk ka mundësi të ndërtohet gjithçka nga e para, është e mundur të integrohet In-Memory në arkitekturën ekzistuese. Por jo të gjitha zgjidhjet In-Memory e mbështesin këtë. Ka tre kushte të domosdoshme. Zgjidhja In-Memory duhet të mbështesë:
- një mënyrë standarde lidhjeje me bazën, e cila do të jetë nën të (p.sh., MySQL);
- një gjuhë standarde kërkese, për të mos e riparë dhe ndryshuar logjikën e bashkëpunimit me ruajtjen;
- tranzaksionet - të ruajë semantikën e bashkëpunimit.
Nëse të tri kushtet respektohen, atëherë integrimi është i mundur. Ne vendosim In-Memory Data Grid midis aplikacionit dhe bazës. Tani kërkesat për shkruan do të delegohen te baza e poshtme, ndërsa kërkesat për lexim do të shkojnë në bazë, nëse të dhënat nuk janë në cache.
Nëse ju rëndësishëm është akses i shpejtë në të dhëna dhe procesimi i tyre, për shembull, për analitikën e biznesit - mund të mendoni për implementimin e In-Memory. Dhe për realizimin mund të përdorni të dyja mënyrat kur dizajnoni një arkitekturë të re.
Burimi: habr.com
