Memoria barnean datuak gordetzeko kontzeptu multzo bat da, aplikazioaren RAM memorian gordeta daudenean, eta diskoa babeskopia egiteko erabiltzen da. Planteamendu klasikoetan, datuak diskoan gordetzen dira eta memoria cachean. Adibidez, datuak prozesatzeko backend-a duen web aplikazio batek biltegiratzeko eskaera egiten du: jasotzen ditu, eraldatzen ditu eta sarean datu asko transferitzen dira. Memorian, kalkuluak datuetara bidaltzen dira, biltegiratzera, non prozesatzen dira eta sarea gutxiago kargatzen da.
Zein beste aukera daude In-Memory-rekin eta zer nolako ikuspegia da hau? Vladimir Pligin - GridGain-eko ingeniaria. Berrikuspen-material hau erabilgarria izango da In-Memory-rekin lan egin ez duten eta probatu nahi duten edo software garapenaren eta arkitektura-diseinuaren joera modernoetan interesa duten web aplikazioen backend garatzaileentzat.
Kontuan izan. Artikulua Vladimirren txostenaren transkripzioan oinarritzen da #GetIT Conf. Auto-isolamendua ezarri aurretik, aldian-aldian garatzaileentzako bilerak eta hitzaldiak egin genituen Moskun eta San Petersburgon: joerak, egungo garapen-arazoak, arazoak eta haien irtenbideak eztabaidatu genituen. Orain ezin da hitzaldirik egin, baina iraganeko material erabilgarriak partekatzeko garaia da.
Nork erabiltzen du In-Memory eta nola
Memoria barnean erabiltzen da gehienetan erabiltzaileen interakzio azkarra edo datu kopuru handiak prozesatzea behar den tokietan.
- Kutxen Erabili In-Memory, adibidez, bezeroek aplikazioak erabiltzen dituztenean atzerapenak murrizteko edo bezeroa mailegua eman aurretik aztertzeko.
- Fintech In-Memory erabiltzen du datuen tratamendua eta azterketa azpikontratatzen duten bankuentzako zerbitzu eta aplikazioen errendimendua hobetzeko.
- Aseguru konpainiak: arriskuak kalkulatzeko, adibidez, hainbat urtetan bezeroen datuak aztertuz.
- Logistika enpresak. Datu asko prozesatzen dituzte, adibidez, milaka parametrorekin salgaiak eta bidaiariak garraiatzeko ibilbide optimoak kalkulatzeko eta bidalketen egoeraren jarraipena egiteko.
- Txikizkako salmenta. Memoria barneko soluzioek bezeroei azkarrago zerbitzatzen eta informazio bolumen handia prozesatzen laguntzen dute: bidalketak, fakturak, transakzioak, biltegietan milaka salgai egotea eta txosten analitikoak prestatzen.
- Π IoT In-Memory-k ohiko datu-baseak ordezkatzen ditu.
- Farmazia enpresek In-Memory erabiltzen dute, adibidez, droga-konposizioen konbinazioak ordenatzeko.
Gure bezeroek Memoria barneko soluzioak nola erabiltzen dituzten eta zuk zeuk ezar ditzakezun adibide batzuk esango dizkizut.
Memoria barneko biltegiratze nagusi gisa
Gure bezeroetako bat AEBetako ekipamendu zientifiko medikoen hornitzaile handi bat da. In-Memory irtenbide bat erabiltzen dute datu biltegiratze nagusi gisa. Datu guztiak diskoan gordetzen dira, eta aktiboki erabiltzen den datuen azpimultzoa RAMan gordetzen da. Biltegiratzeko sarbide-metodoak estandarrak dira: GDBC (Generic Database Connector) eta SQL kontsulta-lengoaia.
Orokorrean, memoria-datu-basea (IMDB) edo memorian zentratutako biltegiratzea deitzen zaio. Soluzio klase honek izen asko ditu, hauek ez dira bakarrak.
IMDB Ezaugarriak:
- Memorian gordetzen diren eta SQL bidez atzitzen diren datuak beste ikuspegi batzuetan bezalakoak dira. Sinkronizatuta daude, soilik aurkezteko modua, heltzeko modua ezberdina da. Transakzionaltasunak datuen artean funtzionatzen du.
- IMDB datu-base erlazionalak baino azkarragoa da RAMetik informazioa diskotik baino azkarragoa delako berreskuratzea.
- Barne optimizazio algoritmoek argibide gutxiago dituzte.
- IMDBak egokiak dira aplikazioetako datuak, gertaerak eta transakzioak kudeatzeko.
IMDBek partzialki onartzen dute ACID: atomotasuna, koherentzia eta isolamendua. Baina ez dute "iraunkortasuna" onartzen - boterea itzaltzen denean, datu guztiak galtzen dira. Arazoa konpontzeko, argazkiak erabil ditzakezu - datu-basearen "instantanea" bat, disko gogorrean datu-basearen babeskopiaren antzekoa, edo transakzioak (erregistroak) grabatu datuak berrabiarazi ondoren datuak berreskuratzeko.
Akatsekiko tolerantzia duten aplikazioak sortzeko
Imajina dezagun hutsegite-tolerantzia web aplikazio baten arkitektura klasikoa. Honela funtzionatzen du: eskaera guztiak web-orekatzaile batek banatzen ditu zerbitzarien artean. Sistema hau egonkorra da zerbitzariek bata bestea bikoizten dutelako eta intzidentziaren kasuan babeskopia egiten dutelako.
Balantzaileak saio batetik zerbitzari batera zuzentzen ditu eskaera guztiak. Hau makila-saio-mekanismo bat da: saio bakoitza zerbitzari batekin lotzen da, non lokalean gorde eta prozesatzen den.
Zer gertatzen da zerbitzarietako batek huts egiten duenean?
Zerbitzuari ez zaio eragingo arkitektura bikoiztuta dagoelako. Baina hildako zerbitzariaren saioen azpimultzo bat galduko dugu. Eta, aldi berean, saio horiei lotuta dauden erabiltzaileak. Adibidez, bezero batek eskaera bat egiten du eta bat-batean bulegotik botatzen du. Berriro saioa hasten denean atsekabetuko da eta dena berriro egin beharko dela ikusten du.
Web-aplikazio bat behar da erabiltzaile kopuru handi bat onartzeko eta ez moteldu, eroso lan egin dezaten. Baina uko egiten bazaio, ondorengo eskaera bakoitzarekin saio-dendarekin komunikatzeko behar den denbora handitu egingo da. Horrek beste erabiltzaile batzuen batez besteko latentzia handitzen du. Baina ez dute ohituta baino gehiago itxaron nahi.
Arazo hau gure beste bezero bezala konpondu daiteke, AEBko PASS hornitzaile handi bat. In-Memory erabiltzen du web saioak multzokatzeko. Horretarako, ez lokalean gordetzen ditu, zentralki baizik - Memoria barneko kluster batean. Kasu honetan, saioak askoz azkarrago daude eskuragarri, dagoeneko RAM-ean daudelako.
Zerbitzari bat huts egiten denean, orekatzaileak huts egin duen zerbitzaritik eskaerak bidaltzen ditu beste zerbitzarietara, arkitektura klasikoan bezala. Baina alde garrantzitsu bat dago: saioak Memoriako kluster batean gordetzen dira eta zerbitzariek eroritako zerbitzariaren saioetarako sarbidea dute.
Arkitektura honek sistema osoaren akatsen tolerantzia areagotzen du. Gainera, posible da makila-saio-mekanismoa guztiz alde batera uztea.
Prozesamendu analitiko transakzional hibridoa (HTAP)
Normalean, sistema transakzionalak eta analitikoak bereizita mantentzen dira. Banatzen direnean, oinarri nagusia kargapean geratzen da. Prozesamendu analitikoa egiteko, datuak erreplika batera kopiatzen dira, prozesamendu analitikoak transakzio-prozesuak oztopatzeko. Baina kopiatzea atzerapenarekin gertatzen da; ezinezkoa da atzerapenik gabe errepikatzea. Sinkronoki egiten badugu, oinarri nagusia ere motelduko da eta ez dugu irabazirik lortuko.
HTAPen, dena modu desberdinean funtzionatzen du: datu biltegi bera erabiltzen da aplikazioen karga transakzionaletarako eta betetzeko denbora luzea izan dezaketen kontsulta analitikoetarako. Datuak RAMan daudenean, kontsulta analitikoak azkarrago exekutatzen dira, eta datu-basea duen zerbitzaria gutxiago kargatzen da (batez beste).
Ikuspegi hibrido batek transakzioen prozesamenduaren eta analisiaren arteko horma hausten du. Biltegiratze berean analitikoak egiten baditugu, kontsulta analitikoak abiarazten dira RAM datuetan. Askoz zehatzagoak, interpretagarriagoak eta egokiagoak dira.
Memoria barneko soluzioen integrazioa
Modu (nahiko) sinplea - dena hutsetik garatu. Datuak diskoan gordetzen ditugu eta datu beroak memorian gordetzen ditugu. Horrek zerbitzariaren berrabiarazi edo etenaldietatik irauten laguntzen du.
Bi eszenatoki nagusi daude lanean hemen datuak diskoan gordetzen direnean. Lehenengoan, hutsegiteei edo klusterraren edo zatien ohiko berrabiarazteei eutsi nahi diegu - datu-base soil gisa erabili nahi dugu. Bigarren eszenatokian, datu gehiegi daudenean, horietako batzuk memorian daude.
Ezin bada dena hutsetik eraiki, posible da In-Memory dagoeneko integratzea. dagoen arkitektura. Baina Memoria barneko soluzio guztiak ez dira horretarako egokiak. Derrigorrezko hiru baldintza daude. Memoria barneko irtenbideak honako hauek onartu behar ditu:
- azpian kokatuko den datu-basera konektatzeko modu estandarra (adibidez, MySQL);
- kontsulta-lengoaia estandar bat, biltegiarekin elkarreraginaren logika berridatzi eta aldatzeko;
- transakzionalak - elkarrekintzaren semantika gorde.
Hiru baldintzak betetzen badira, orduan integrazioa posible da. Aplikazioaren eta datu-basearen artean Memoria barneko datuen sareta jartzen dugu. Orain idazketa-eskaerak azpiko datu-basean delegatuko dira, eta irakurketa-eskaerak azpiko datu-basean eskuordetuko dira datuak cachean ez badaude.
Datuetarako sarbide azkarra eta haien prozesatzea garrantzitsua bada zuretzat, adibidez, negozio-analisietarako, In-Memory ezartzea pentsa dezakezu. Eta ezartzeko, bi metodoak erabil ditzakezu arkitektura berri bat diseinatzerakoan.
Iturria: www.habr.com