In-Memory â njĂ« grup konceptesh pĂ«r ruajtjen e tĂ« dhĂ«nave, kur ato ruhen nĂ« memorien operative tĂ« aplikacionit, ndĂ«rsa disku pĂ«rdoret pĂ«r backup. NĂ« qasjet klasike, tĂ« dhĂ«nat ruhen nĂ« disk, dhe memoria Ă«shtĂ« nĂ« cache. PĂ«r shembull, njĂ« aplikacion web me backend pĂ«r pĂ«rpunimin e tĂ« dhĂ«nave i kĂ«rkon ato nĂ« depo: merr, transformon, dhe nĂ« rrjet kalon njĂ« sasi tĂ« madhe tĂ« dhĂ«nash. NĂ« In-Memory, llogaritjet dĂ«rgohen nĂ« tĂ« dhĂ«na â nĂ« depo, ku pĂ«rpunohen dhe rrjeti ngarkohet mĂ« pak.
Cilat mundĂ«si tĂ« tjera janĂ« tĂ« disponueshme me In-Memory dhe çfarĂ« qasjeje Ă«shtĂ«, do tĂ« tregojĂ« Vladimir Pligin â inxhinier nĂ« kompaninĂ« GridGain. Ky material pĂ«rmbledhĂ«s do tĂ« jetĂ« i dobishĂ«m pĂ«r zhvilluesit e backend-it tĂ« aplikacioneve web qĂ« nuk kanĂ« punuar me In-Memory dhe duan tĂ« provojnĂ«, ose qĂ« janĂ« tĂ« interesuar nĂ« trendet moderne tĂ« zhvillimit tĂ« zgjidhjeve software dhe projektimin e arkitekturĂ«s.
Shënim. Artikulli është i bazuar në transkriptimin e fjalimit të Vladimirit në konferencën #GetIT Conf. Para hyrjes në vetëizolim ne zakonisht zhvillonim meet-up dhe konferenca për zhvilluesit në Moskë dhe Shën Petersburg: diskutonim trendet, çështjet e rëndësishme të zhvillimit, problemet dhe zgjidhjet e tyre. Tani nuk ka mundësi të zhvillohen konferenca, por tani është koha për të ndarë materiale të dobishme nga të kaluarat.
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ërpunimin e sasi të mëdha të të dhënave.
- Bankat përdorin In-Memory, për shembull, për të ulur vonesat kur klientët përdorin aplikacionet ose për analizën e klientëve para dhënies së kredisë.
- Fintech pĂ«rdor In-Memory pĂ«r tĂ« pĂ«rmirĂ«suar performancĂ«n e shĂ«rbimeve dhe aplikacioneve pĂ«r banka, tĂ« cilat e delegojnĂ« pĂ«rpunimin dhe analizĂ«n e tĂ« dhĂ«nave nĂ« outsource.Â
- Kompani të sigurimeve: për të llogaritur rreziqet, për shembull, duke analizuar të dhënat e klientit për disa vite.
- Kompani logjistike. Ato përpunojnë shumë të dhëna, për shembull, për të llogaritur rrugët optimale të transportit të mallrave dhe pasagjerëve me mijëra parametra, duke ndjekur statusin e dërgesave.
- Përgjigjësia. Zgjidhjet In-Memory ndihmojnë në shërbimin më të shpejtë të klientëve dhe në përpunimin e sasisë së konsiderueshme të informacionit: dërgesat, faturat, transaksionet, disponibiliteti i mijëra produkteve në depo, krijimin e raporteve analitike.
- Në IoT In-Memory zëvendëson bazat e të dhënave tradicionale.
- Kompani farmaceutike pĂ«rdorin In-Memory, pĂ«r shembull, pĂ«r tĂ« provuar kombinime tĂ« pĂ«rbĂ«rjes sĂ« ilaçeve.Â
Do flas disa shembuj se si klientët tanë përdorin zgjidhjet In-Memory dhe si mund t'i aplikoni ato në kompaninë tuaj.
In-Memory si magazina kryesore
NjĂ« prej klientĂ«ve tanĂ« Ă«shtĂ« njĂ« furnizues i madh i pajisjeve shkencore mjekĂ«sore nga SHBA. Ata pĂ«rdorin njĂ« zgjidhje In-Memory si magazinĂ« kryesore tĂ« tĂ« dhĂ«nave. TĂ« gjitha tĂ« dhĂ«nat ruhen nĂ« disk, ndĂ«rsa nĂ«ngrupi i tĂ« dhĂ«nave qĂ« pĂ«rdoret aktivisht mbahen nĂ« RAM. Metodat e qasjes nĂ« magazinĂ« janĂ« standardeâGDBC (Generic Database Connector) dhe gjuha e pyetjeve SQL.
TĂ« gjitha sĂ« bashku quhen In-Memory Database (IMDB) ose Storage Centric nĂ« Memorie. Ky klas zgjidhjesh ka shumĂ« emra, kĂ«to nuk janĂ« ato tĂ« vetmet.Â
Karakteristikat e IMDB:
- Të dhënat e ruajtura në In-Memory dhe të qasshme përmes SQL janë të njëjtat si në qasjet e tjera. Ato janë sinkronizuar, ndryshon vetëm mënyra e paraqitjes dhe mënyra e qasjes. Midis të dhënave punon transaksionaliteti.
- IMDB janĂ« mĂ« tĂ« shpejtĂ« se bazat e tĂ« dhĂ«nave relacionales, sepse Ă«shtĂ« mĂ« e shpejtĂ« tĂ« nxjerrĂ«sh informacion nga RAM sesa nga disku.Â
- Proporcionalisht, algoritmet e optimizimit të brendshëm kanë më pak instruksione.
- IMDB janë të përshtatshme për menaxhimin e të dhënave, ngjarjeve dhe transaksioneve në aplikacione.
IMDB mbĂ«shtesin pjesĂ«risht ACID: atomizimi, konsistenca dhe izolimi. Por nuk mbĂ«shtesin "qĂ«ndrueshmĂ«rinĂ«" - kur fiket energjia, tĂ« dhĂ«nat humbasin. PĂ«r tĂ« zgjidhur problemin mund tĂ« pĂ«rdoren snapshot-etâ"sĂ« paku njĂ«" e bazĂ«s sĂ« tĂ« dhĂ«nave, ekuivalenti i bkup-it tĂ« DB nĂ« diskun e fortĂ«, ose tĂ« regjistrohen transaksionet (log-et), pĂ«r tĂ« rikuperuar tĂ« dhĂ«nat pas rinisjes.
Për krijimin e aplikacioneve të besueshme
Le taqojmë arkitekturën klasike të një aplikacioni web të qëndrueshëm. Ajo funksionon kështu: të gjitha kërkesat shpërndahen nga një balancues i webit midis serverëve. Kjo sistem është i qëndrueshëm, sepse serverët përzgjidhen dhe mbështesin njëri-tjetrin në raste incidentesh.
Balancuesi drejton tĂ« gjitha kĂ«rkesat nga njĂ« seancĂ« e vetme strikt tek njĂ« server. Ky Ă«shtĂ« mekanizmi i seancave tĂ« ngjitur: çdo seancĂ« lidhet me serverit, ku ajo ruhet dhe pĂ«rpunuar lokal.Â
ĂfarĂ« do tĂ« ndodhĂ« kur njĂ« nga serverĂ«sh?
serverët dështon? Shërbimi nuk do të dëmtohet, sepse arkitektura është e dyfishuar. Por ne do të humbasim një nënmësym për sesionet e serverit të vdekur. Po ashtu dhe përdoruesit që janë të lidhur me këto seanca. Për shembull, një klient vendos një porosi dhe papritur hidhet jashtë nga llogaria. Ai do të jetë i pakënaqur kur të rihyjë dhe të zbulojë se gjithçka duhet ta bëjë përsëri.
Një aplikacion web kërkohet të mbështesë një numër të madh përdoruesish dhe të mos 'ngadalësohet', në mënyrë që ata të kenë komoditet në përdorim. Por në rast dështimi, me çdo kërkesë tjetër, koha e komunikimit me ruajtjen e sesioneve do të rritet. Kjo rrit vonesën mesatare (latency) për përdoruesit e tjerë. Por ata nuk duan të presin më shumë se çfarë janë mësuar.
Ky problem mund tĂ« zgjidhet, si njĂ« tjetĂ«r klienti ynĂ« â njĂ« provajder i madh PAS nĂ« SHBA. Ai pĂ«rdor In-Memory pĂ«r tĂ« klasterizuar sesionet web. PĂ«r kĂ«tĂ«, ato ruhen jo lokal, por nĂ« mĂ«nyrĂ« qendrore â nĂ« klasterin In-Memory. NĂ« kĂ«tĂ« rast, sesionet janĂ« shumĂ« mĂ« tĂ« shpejta, sepse ato ndodhen tashmĂ« nĂ« memorien operative.
Kur serveri dështon, balancuesi dërgon kërkesat e rënë në serverë të tjerë, ashtu si në arkitekturën klasike. Por ka një ndryshim të rëndësishëm: sesionet ruhen në klasterin In-Memory dhe serverët kanë qasje në sesionet e serverit të rënë.
Kjo arkitekturë rrit qëndrueshmërinë e gjithë sistemit. Më shumë se kaq, është e mundur të hiqet krejtësisht mekanizmi i seancave të ngjitura.
PĂ«rpunimi hibrid transaksional-analitik (HTAP)
Zakonisht, sistemet transaksionale dhe analitike mbahen veçmas. Kur ato ndahen, baza kryesore përballohet me ngarkesë. Për përpunimin analitik, të dhënat kopjohen në një replikë, në mënyrë që përpunimi analitik të mos pengojë proceset transaksionale. Por kopjimi bëhet me vonesë - pa vonesë, replikimi është i pamundur. Nëse e bëjmë këtë në mënyrë sinkrone, do të ngadalësojë gjithashtu bazën kryesore dhe nuk do të kemi fitim.
Në HTAP, gjithçka funksionon ndryshe - të njëjtin depo të dhënash përdorim për ngarkesën transaksionale nga aplikacionet dhe për kërkesat analitike, të cilat mund të zgjasin gjatë. Kur të dhënat janë në memorie operative, kërkesat analitike përfundohen më shpejt dhe serveri me DB ngarkohet më pak (në mesatare).
Qasja hibride "thyen murin" ndërmjet përpunimit të transaksioneve dhe analitikës. Nëse ne kryejmë analizën në të njëjtën depo, kërkesat analitike nisën mbi të dhënat nga memoria operative. Ato janë shumë më të sakta, më interpretueshmë dhe më adekuate.
Integrimi i zgjidhjeve In-Memory
Një mënyrë relativisht e thjeshtë - të zhvillojmë gjithçka nga fillimi. Ne mbajmë të dhënat në disk, ndërsa ato të nxehta i ruajmë në memorie. Kjo ndihmon për të përballuar rikthimet e serverëve ose ndërprerjet.
KĂ«tu funksionojnĂ« dy skenarĂ« kryesorĂ«, kur tĂ« dhĂ«nat ruhen nĂ« disk. NĂ« tĂ« parin, ne duam tĂ« pĂ«rballojmĂ« rĂ«niet ose rikthimet e zakonshme tĂ« klasterit ose pjesĂ«ve â duam ta pĂ«rdorim si njĂ« bazĂ« tĂ« thjeshtĂ« tĂ« dhĂ«nash. NĂ« skenarin e dytĂ«, kur ka shumĂ« tĂ« dhĂ«na, njĂ« pjesĂ« e tyre Ă«shtĂ« nĂ« memorie.
Nëse nuk ka mundësi të gjithë të ndërtohet nga fillimi, mund të integrohet In-Memory në tashmë arkitekturën ekzistuese. Por jo të gjitha zgjidhjet In-Memory janë të përshtatshme për këtë. Ka tre kushte të detyrueshme. Zgjidhja In-Memory duhet të mbështesë:
- një standard të mënyrës për t'u lidhur me bazën, që do të jetë nën të (për shembull, MySQL);
- njĂ« gjuhĂ« standard kĂ«rkese, pĂ«r tĂ« mos rritur dhe ndryshuar logjikĂ«n e ndĂ«rveprimit me depo;â
- transaksionalitetin - për të ruajtur semantikën e ndërveprimit.
Nëse të tri kushtet respektohen, atëherë integrimi është i mundur. Vendosim In-Memory Data Grid ndërmjet aplikacionit dhe bazës. Tani kërkesat për shkruar do të delegohen në bazën e poshtme, dhe kërkesat për të lexuar - në bazë, nëse të dhënat nuk janë në cache.
NĂ«se ju intereson qasja e shpejtĂ« nĂ« tĂ« dhĂ«na dhe pĂ«rpunimi i tyre, pĂ«r shembull, pĂ«r analizat e biznesit â mund tĂ« mendoni pĂ«r implementimin e In-Memory. PĂ«r realizimin e tij mund tĂ« pĂ«rdorni tĂ« dyja mĂ«nyrat gjatĂ« projektimit tĂ« arkitekturĂ«s sĂ« re.
Burimi: habr.com
