In-Memory on mõistete kogum andmete salvestamiseks, kui need salvestatakse rakenduse RAM-i ja ketast kasutatakse varundamiseks. Klassikaliste lähenemisviiside korral salvestatakse andmed kettale ja mälu vahemällu. Näiteks pärib andmete töötlemise taustaprogrammiga veebirakendus need salvestusruumi: võtab need vastu, teisendab ja palju andmeid edastatakse üle võrgu. In-Memorys saadetakse arvutused andmetele – salvestusruumi, kus neid töödeldakse ja võrk on vähem koormatud.
Milliseid muid võimalusi on In-Memory abil saadaval ja milline on see lähenemine? Vladimir Pligin - GridGaini insener. See ülevaatematerjal on kasulik veebirakenduste taustaprogrammi arendajatele, kes pole In-Memoryga töötanud ja soovivad proovida või on huvitatud tarkvaraarenduse ja arhitektuuri disaini kaasaegsetest suundumustest.
Märkus. Artikkel põhineb Vladimiri aruande ärakirjal #GetIT Conf. Enne isolatsiooni kasutuselevõttu korraldasime regulaarselt Moskvas ja Peterburis arendajatele mõeldud kohtumisi ja konverentse: arutasime trende, aktuaalseid arenguprobleeme, probleeme ja nende lahendusi. Praegu pole võimalik konverentsi pidada, kuid on aeg jagada kasulikke materjale varasematest.
Kes ja kuidas In-Memoryt kasutab
In-Memory kasutatakse kõige sagedamini seal, kus on vaja kiiret kasutajapoolset suhtlemist või suurte andmemahtude töötlemist.
- Pangad kasutage rakendust In-Memory näiteks selleks, et vähendada viivitusi klientide rakenduste kasutamisel või analüüsida klienti enne laenu väljastamist.
- Fintech kasutab In-Memoryt teenuste ja rakenduste jõudluse parandamiseks pankadele, kes tellivad andmetöötlust ja analüüsi.
- Kindlustusfirmad: riskide arvutamiseks näiteks mitme aasta kliendiandmeid analüüsides.
- Logistikafirmad. Nad töötlevad palju andmeid, näiteks arvutavad tuhandete parameetritega kauba- ja reisijateveoks optimaalseid marsruute ning jälgivad saadetiste olekut.
- Jaekaubandus. In-Memory lahendused aitavad kliente kiiremini teenindada ja töödelda suuri infomahtusid: saadetisi, arveid, tehinguid, tuhandete kaupade olemasolu ladudes ning koostada analüütilisi aruandeid.
- В IoT In-Memory asendab traditsioonilisi andmebaase.
- Farmaatsia ettevõtted kasutavad In-Memoryt näiteks ravimikompositsioonide kombinatsioonide sortimiseks.
Toon teile mõned näited, kuidas meie kliendid In-Memory lahendusi kasutavad ja kuidas saate neid ise juurutada.
Mälus kui esmane salvestusruum
Üks meie klientidest on USA suur teaduslike meditsiiniseadmete tarnija. Peamise andmesalvestusena kasutavad nad mälus olevat lahendust. Kõik andmed salvestatakse kettale ja aktiivselt kasutatavat alamhulka hoitakse RAM-is. Salvestusruumi juurdepääsumeetodid on standardsed – GDBC (Generic Database Connector) ja SQL päringukeel.
Ühiselt nimetatakse seda mälusiseseks andmebaasiks (IMDB) või mälukeskseks salvestusruumiks. Sellel lahenduste klassil on palju nimesid, need pole ainsad.
IMDB funktsioonid:
- Andmed, mis salvestatakse mälusse ja millele pääseb juurde SQL-i kaudu, on samad, mis teistes lähenemisviisides. Need on sünkroniseeritud, erinev on ainult esitusviis, nende käsitlemise viis. Tehingulisus toimib andmete vahel.
- IMDB on kiirem kui relatsiooniandmebaasid, kuna see on kiirem teabe hankimiseks RAM-ist kui kettalt.
- Sisemisel optimeerimisalgoritmil on vähem juhiseid.
- IMDB-d sobivad andmete, sündmuste ja tehingute haldamiseks rakendustes.
IMDB-d toetavad osaliselt ACID-i: Aatomilisus, järjepidevus ja isolatsioon. Kuid need ei toeta "vastupidavust" - toite väljalülitamisel lähevad kõik andmed kaotsi. Probleemi lahendamiseks saate kasutada hetktõmmiseid - andmebaasi "hetktõmmist", mis on analoogne andmebaasi varukoopiaga kõvakettale, või tehingute (logide) salvestamiseks andmete taastamiseks pärast taaskäivitamist.
Tõrketaluvate rakenduste loomiseks
Kujutagem ette tõrketaluva veebirakenduse klassikalist arhitektuuri. See toimib järgmiselt: kõik päringud jaotatakse serverite vahel veebibalansiriga. See süsteem on stabiilne, kuna serverid dubleerivad üksteist ja varundavad intsidentide korral.
Tasakaalustaja suunab kõik päringud ühest seansist rangelt ühte serverisse. See on seansi mehhanism: iga seanss on seotud serveriga, kus seda lokaalselt salvestatakse ja töödeldakse.
Mis juhtub, kui üks serveritest ebaõnnestub?
Teenust see ei mõjuta, kuna arhitektuur on dubleeritud. Kuid me kaotame surnud serveri seansside alamhulga. Ja samal ajal kasutajad, kes on nende seanssidega seotud. Näiteks klient esitab tellimuse ja viskab ta ootamatult kontorist välja. Ta on õnnetu, kui logib uuesti sisse ja leiab, et kõike tuleb uuesti teha.
Veebirakendus on vajalik suure hulga kasutajate toetamiseks ja mitte aeglustamiseks, et nad saaksid mugavalt töötada. Kui aga sellest keeldutakse, pikeneb iga järgneva päringuga seansipoega suhtlemiseks kuluv aeg. See suurendab teiste kasutajate keskmist latentsusaega. Kuid nad ei taha oodata kauem, kui nad on harjunud.
Seda probleemi saab lahendada nagu meie teist klienti, suurt PASS-i pakkujat USA-st. See kasutab veebiseansside rühmitamiseks mälusisest funktsiooni. Selleks salvestab see need mitte lokaalselt, vaid tsentraalselt – mälus olevasse klastris. Sel juhul on seansid saadaval palju kiiremini, kuna need on juba RAM-is.
Kui server jookseb kokku, saadab tasakaalustaja päringuid kokkujooksnud serverist teistele serveritele, nagu klassikalises arhitektuuris. Kuid on oluline erinevus: seansid salvestatakse mälus olevasse klastris ja serveritel on juurdepääs langenud serveri seanssidele.
See arhitektuur suurendab kogu süsteemi veataluvust. Veelgi enam, pulgaseansi mehhanismist on võimalik üldse loobuda.
Hübriidtehingute analüütiline töötlemine (HTAP)
Tavaliselt hoitakse tehingu- ja analüütilisi süsteeme lahus. Kui need eralduvad, satub põhialus koormuse alla. Analüütiliseks töötlemiseks kopeeritakse andmed koopiasse, nii et analüütiline töötlemine ei sega tehinguprotsesse. Kuid kopeerimine toimub viivitusega – ilma viivituseta on võimatu kopeerida. Kui teeme seda sünkroonselt, aeglustab see ka põhibaasi ja me ei saa võitu.
HTAP-is töötab kõik teisiti – sama andmesalvesti kasutatakse rakenduste tehingute laadimiseks ja analüütiliste päringute jaoks, mille täitmine võib võtta kaua aega. Kui andmed on RAM-is, täidetakse analüütilisi päringuid kiiremini ja andmebaasiga server on vähem koormatud (keskmiselt).
Hübriidne lähenemine lõhub müüri tehingute töötlemise ja analüüsi vahel. Kui teeme analüüsi samal salvestusruumil, käivitatakse RAM-i andmete kohta analüütilised päringud. Need on palju täpsemad, paremini tõlgendatavad ja adekvaatsemad.
In-Memory lahenduste integreerimine
(Suhteliselt) lihtne viis - arendada kõike nullist. Hoiame andmeid kettal ja salvestame kuumad andmed mällu. See aitab üle elada serveri taaskäivitamise või katkestuste korral.
Andmete kettale salvestamisel toimib siin kaks peamist stsenaariumi. Esimeses soovime üle elada klastri või osade kokkujooksmised või korrapärased taaskäivitused – tahame seda kasutada lihtsa andmebaasina. Teise stsenaariumi korral, kui andmeid on liiga palju, on osa neist mälus.
Kui kõike pole võimalik nullist üles ehitada, on võimalik In-Memory integreerida juba olemasolevat arhitektuuri. Kuid mitte kõik In-Memory lahendused ei sobi selleks. On kolm kohustuslikku tingimust. Mälusisene lahendus peab toetama:
- standardne viis selle all asuva andmebaasiga ühenduse loomiseks (näiteks MySQL);
- standardne päringukeel, et mitte ümber kirjutada ja salvestusega suhtlemise loogikat muuta;
- tehinguline – säilitab interaktsiooni semantika.
Kui kõik kolm tingimust on täidetud, on integreerimine võimalik. Asetame mälus oleva andmevõrgu rakenduse ja andmebaasi vahele. Nüüd delegeeritakse kirjutamispäringud aluseks olevale andmebaasile ja lugemispäringud delegeeritakse aluseks olevale andmebaasile, kui andmeid pole vahemälus.
Kui teie jaoks on näiteks ärianalüütika jaoks oluline kiire juurdepääs andmetele ja nende töötlemine, võite mõelda In-Memory juurutamisele. Ja rakendamiseks saate uue arhitektuuri kujundamisel kasutada mõlemat meetodit.
Allikas: www.habr.com