En-Memoro estas aro de konceptoj por stoki datumojn kiam ĝi estas konservita en la RAM de la aplikaĵo, kaj la disko estas uzata por sekurkopio. En klasikaj aliroj, datenoj estas stokitaj sur disko kaj memoro estas stokita en kaŝmemoro. Ekzemple, TTT-apliko kun backend por prilaborado de datumoj petas ĝin en stokadon: ĝi ricevas ĝin, transformas ĝin, kaj multe da datumoj estas transdonitaj tra la reto. En In-Memory, kalkuloj estas senditaj al la datumoj - al stokado, kie ili estas procesitaj kaj la reto estas malpli ŝarĝita.
Kiuj aliaj eblecoj disponeblas kun In-Memory kaj kia aliro ĉi tio estas? Vladimir Pligin - inĝeniero ĉe GridGain. Ĉi tiu revizia materialo estos utila al programistoj de retaj aplikaĵoj, kiuj ne laboris kun In-Memory kaj volas provi aŭ interesiĝas pri modernaj tendencoj pri programaro kaj arkitekturo-dezajno.
Примечание. La artikolo baziĝas sur la transskribo de la raporto de Vladimir ĉe la #GetIT Conf. Antaŭ la enkonduko de mem-izolado, ni regule okazigis renkontiĝojn kaj konferencojn por programistoj en Moskvo kaj Sankt-Peterburgo: ni diskutis tendencojn, aktualajn disvolvajn problemojn, problemojn kaj iliajn solvojn. Nun ne eblas okazigi konferencon, sed estas tempo por kunhavi utilajn materialojn el pasintaj.
Kiu uzas In-Memory kaj kiel
En-Memoro estas plej ofte uzata kie rapida uzantinterago aŭ prilaborado de grandaj kvantoj da datumoj estas postulataj.
- Bankoj uzu In-Memory, ekzemple, por redukti prokrastojn kiam klientoj uzas aplikojn aŭ por analizi la klienton antaŭ eldoni prunton.
- Fintech uzas In-Memory por plibonigi la agadon de servoj kaj aplikoj por bankoj kiuj subkontraktas datumtraktadon kaj analizon.
- Asekuraj kompanioj: kalkuli riskojn, ekzemple, analizante klientajn datumojn dum pluraj jaroj.
- Loĝistikaj kompanioj. Ili prilaboras multajn datumojn, ekzemple, por kalkuli optimumajn itinerojn por ŝarĝo kaj pasaĝero transportado kun miloj da parametroj, kaj spuri la staton de sendoj.
- Podetala komerco. En-Memoraj solvoj helpas servi klientojn pli rapide kaj prilabori grandajn volumojn de informoj: sendaĵoj, fakturoj, transakcioj, la ĉeesto de miloj da varoj en magazenoj kaj prepari analizajn raportojn.
- В IoT En-Memoro anstataŭigas tradiciajn datumbazojn.
- Farmacia kompanioj uzas In-Memory, ekzemple, por ordigi kombinaĵojn de drogkunmetaĵoj.
Mi rakontos al vi kelkajn ekzemplojn pri kiel niaj klientoj uzas En-Memorajn solvojn kaj kiel vi povas efektivigi ilin mem.
En-Memoro kiel ĉefa stokado
Unu el niaj klientoj estas granda provizanto de medicina scienca ekipaĵo el Usono. Ili uzas En-Memoran solvon kiel sian ĉefan datumstokadon. Ĉiuj datumoj estas konservitaj sur disko, kaj la subaro de datumoj aktive uzataj estas konservitaj en RAM. La stokaj alirmetodoj estas normaj - GDBC (Generic Database Connector) kaj SQL-demanda lingvo.
Kolektive tio estas nomita En-Memory Database (IMDB) aŭ Memoro-Centrita Stokado. Ĉi tiu klaso de solvoj havas multajn nomojn, ĉi tiuj ne estas la solaj.
Trajtoj de IMDB:
- La datumoj stokitaj en En-Memorio kaj alireblaj per SQL estas la sama kiel en aliaj aliroj. Ili estas sinkronigitaj, nur la maniero de prezento, la maniero de trakti ilin estas malsama. Transakcieco funkcias inter datumoj.
- IMDB estas pli rapida ol interrilataj datumbazoj ĉar estas pli rapide preni informojn de RAM ol de disko.
- Internaj optimumigaj algoritmoj havas malpli da instrukcioj.
- IMDB-oj taŭgas por administri datumojn, eventojn kaj transakciojn en aplikoj.
IMDB-oj parte subtenas ACIDO: Atomiko, Konsistenco, kaj Izoliteco. Sed ili ne subtenas "daŭrecon" - kiam la potenco estas malŝaltita, ĉiuj datumoj estas perditaj. Por solvi la problemon, vi povas uzi fotojn - "foton" de la datumbazo, analoga al datumbaza sekurkopio sur malmola disko, aŭ registri transakciojn (protokolojn) por restarigi datumojn post rekomenco.
Por krei misfunkciajn aplikaĵojn
Ni imagu la klasikan arkitekturon de mistolerema TTT-apliko. Ĝi funkcias jene: ĉiuj petoj estas distribuataj de retbalancilo inter serviloj. Ĉi tiu sistemo estas stabila ĉar la serviloj duobligas unu la alian kaj rezervas en kazo de incidentoj.
La ekvilibristo direktas ĉiujn petojn de unu sesio strikte al unu servilo. Ĉi tio estas bastonsesio-mekanismo: ĉiu sesio estas rilata al servilo kie ĝi estas loke stokita kaj prilaborita.
Kio okazas kiam unu el la serviloj malsukcesas?
La servo ne estos tuŝita ĉar la arkitekturo estas duobligita. Sed ni perdos subaron de la sesioj de la mortinta servilo. Kaj samtempe, la uzantoj, kiuj estas ligitaj al ĉi tiuj sesioj. Ekzemple, kliento faras mendon kaj subite forĵetas lin el la oficejo. Li estos malfeliĉa kiam li ensalutos denove kaj trovos, ke ĉio devos esti farita denove.
Reta aplikaĵo estas postulata por subteni grandan nombron da uzantoj kaj ne malrapidigi por ke ili povu labori komforte. Sed se ĝi estas rifuzita, kun ĉiu posta peto pliiĝos la tempo necesa por komuniki kun la sesiobutiko. Ĉi tio pliigas la averaĝan latentecon por aliaj uzantoj. Sed ili ne volas atendi pli longe ol ili kutimis.
Ĉi tiu problemo povas esti solvita kiel nia alia kliento, granda PASS-provizanto de Usono. Ĝi uzas In-Memory por kolekti retsesiojn. Por fari tion, ĝi stokas ilin ne loke, sed centre - en En-Memoria areto. En ĉi tiu kazo, sesioj estas disponeblaj multe pli rapide ĉar ili jam estas en RAM.
Kiam servilo kraŝas, la ekvilibristo sendas petojn de la kraŝinta servilo al aliaj serviloj, kiel en la klasika arkitekturo. Sed estas grava diferenco: sesioj estas stokitaj en En-Memoria areto kaj la serviloj havas aliron al la sesioj de la falinta servilo.
Ĉi tiu arkitekturo pliigas la faŭltoleremon de la tuta sistemo. Plie, eblas tute forlasi la bastonan sean mekanismon.
Hibrida Transakcia Analiza Pretigo (HTAP)
Tipe, transakciaj kaj analizaj sistemoj estas konservitaj apartaj. Kiam ili disiĝas, la ĉefa bazo estas ŝarĝita. Por analiza pretigo, datenoj estas kopiitaj al kopio tiel ke analiza pretigo ne malhelpas transakciajn procezojn. Sed kopiado okazas kun malfruo—estas neeble reprodukti sen malfruo. Se ni faras tion sinkrone, ĝi ankaŭ malrapidigos la ĉefan bazon kaj ni ne ricevos gajnon.
En HTAP, ĉio funkcias alimaniere - la sama datumvendejo estas uzata por transakcia ŝarĝo de aplikaĵoj, kaj por analizaj demandoj, kiuj povas daŭri longan tempon. Kiam la datumoj estas en RAM, analizaj demandoj estas efektivigitaj pli rapide, kaj la servilo kun la datumbazo estas malpli ŝarĝita (averaĝe).
Hibrida aliro malkonstruas la muron inter transakcia prilaborado kaj analizo. Se ni faras analizojn sur la sama stokado, tiam analizaj demandoj estas lanĉitaj sur datumoj de RAM. Ili estas multe pli precizaj, pli interpreteblaj kaj adekvataj.
Integriĝo de En-Memoriaj solvoj
(relative) simpla maniero - disvolvi ĉion de nulo. Ni konservas datumojn sur disko kaj konservas varmajn datumojn en memoro. Ĉi tio helpas postvivi servilojn rekomencojn aŭ malfunkciojn.
Estas du ĉefaj scenaroj en laboro ĉi tie kiam datumoj estas stokitaj sur disko. En la unua, ni volas postvivi kraŝojn aŭ regulajn rekomencojn de la areto aŭ partoj - ni volas uzi ĝin kiel simplan datumbazon. En la dua scenaro, kiam estas tro da datumoj, iuj el ili estas en memoro.
Se ne eblas konstrui ĉion de nulo, eblas integri In-Memory en jam ekzistanta arkitekturo. Sed ne ĉiuj En-Memoraj solvoj taŭgas por ĉi tio. Estas tri devigaj kondiĉoj. La En-Memoria solvo devas subteni:
- norma maniero konekti al la datumbazo, kiu troviĝos sub ĝi (ekzemple, MySQL);
- norma demanda lingvo, por ne reverki kaj ŝanĝi la logikon de interago kun la stokado;
- transakcia - konservi la semantikon de interagado.
Se ĉiuj tri kondiĉoj estas plenumitaj, tiam integriĝo eblas. Ni metas la En-Memorian Datuman Reton inter la aplikaĵo kaj la datumbazo. Nun skribpetoj estos delegitaj al la subesta datumbazo, kaj legaj petoj estos delegitaj al la suba datumbazo se la datumoj ne estas en la kaŝmemoro.
Se rapida aliro al datumoj kaj ĝia prilaborado gravas por vi, ekzemple por komerca analizo, vi povas pensi pri efektivigo de In-Memory. Kaj por efektivigo, vi povas uzi ambaŭ metodojn kiam vi desegnas novan arkitekturon.
fonto: www.habr.com