Az In-Memory az adatok tárolására szolgáló fogalmak halmaza, amikor azokat az alkalmazás RAM-jában tárolják, és a lemezt biztonsági mentésre használják. A klasszikus megközelítésekben az adatokat a lemezen, a memóriát pedig a gyorsítótárban tárolják. Például egy webes alkalmazás adatfeldolgozási háttérrel bekéri a tárhelyre: fogadja, átalakítja, és sok adatot továbbít a hálózaton. Az In-Memory-ban a számításokat az adatokhoz küldik - a tárolóba, ahol feldolgozzák azokat, és kevésbé terhelik a hálózatot.
Milyen további lehetőségek állnak rendelkezésre az In-Memory-ban, és milyen megközelítés ez? Vlagyimir Pligin - mérnök a GridGainnél. Ez az áttekintő anyag hasznos lesz azoknak a webalkalmazás-háttérfejlesztőknek, akik még nem dolgoztak az In-Memory-val, és szeretnének kipróbálni, vagy érdeklődnek a szoftverfejlesztés és architektúratervezés modern trendjei iránt.
Megjegyzés. A cikk Vladimir jelentésének átiratán alapul a #GetIT Conf. Az önizoláció bevezetése előtt rendszeresen tartottunk találkozókat, konferenciákat fejlesztőknek Moszkvában és Szentpéterváron: megbeszéltük a trendeket, aktuális fejlesztési kérdéseket, problémákat és azok megoldásait. Konferenciát most nem lehet tartani, de ideje megosztani a korábbiak hasznos anyagait.
Ki és hogyan használja az In-Memory-t
Az In-Memory leggyakrabban ott használatos, ahol gyors felhasználói interakcióra vagy nagy mennyiségű adat feldolgozására van szükség.
- Banks használja az In-Memory funkciót például a késedelmek csökkentése érdekében, amikor az ügyfelek alkalmazásokat használnak, vagy elemezheti az ügyfelet a kölcsön kiadása előtt.
- Fintech Az In-Memory segítségével javítja a szolgáltatások és alkalmazások teljesítményét az adatfeldolgozást és -elemzést kihelyező bankok számára.
- biztosító társaságok: kockázatok kiszámítására, például az ügyfelek adatainak több éves elemzésével.
- Logisztikai cégek. Rengeteg adatot dolgoznak fel, például több ezer paraméterrel optimális útvonalakat számítanak ki az áru- és személyszállításhoz, nyomon követik a szállítmányok állapotát.
- Kiskereskedelem. Az In-Memory megoldások segítik az ügyfelek gyorsabb kiszolgálását és nagy mennyiségű információ feldolgozását: szállítmányok, számlák, tranzakciók, több ezer áru raktárban való jelenléte, elemző jelentések elkészítése.
- В Tárgyak internete Az In-Memory felváltja a hagyományos adatbázisokat.
- Gyógyszerészeti a cégek például az In-Memory szolgáltatást használják a gyógyszerkészítmények kombinációinak válogatására.
Mondok néhány példát arra, hogyan használják ügyfeleink az In-Memory megoldásokat, és hogyan valósíthatja meg ezeket Ön is.
In-Memory, mint elsődleges tároló
Egyik ügyfelünk orvosi tudományos berendezések nagy szállítója az USA-ból. In-Memory megoldást használnak fő adattárolóként. Minden adat a lemezen van tárolva, és az aktívan használt adatok részhalmaza a RAM-ban tárolódik. A tárolási hozzáférési módszerek szabványosak - GDBC (általános adatbázis-csatlakozó) és SQL lekérdezési nyelv.
Ezt együttesen In-Memory Database-nek (IMDB) vagy memóriaközpontú tárolónak nevezik. Ennek a megoldási osztálynak sok neve van, nem ezek az egyetlenek.
Az IMDB jellemzői:
- Az In-Memory-ban tárolt és az SQL-en keresztül elérhető adatok ugyanazok, mint a többi megközelítésben. Szinkronban vannak, csak a bemutatás módja, megszólítása más. A tranzakciók az adatok között működnek.
- Az IMDB gyorsabb, mint a relációs adatbázisok, mert gyorsabban kéri le az információkat a RAM-ból, mint a lemezről.
- A belső optimalizálási algoritmusok kevesebb utasítást tartalmaznak.
- Az IMDB-k alkalmasak adatok, események és tranzakciók kezelésére alkalmazásokban.
Az IMDB-k részben támogatják az ACID-t: Atomicity, Consistency és Isolation. De nem támogatják a „tartósságot” - amikor a tápellátást kikapcsolják, minden adat elveszik. A probléma megoldásához használhat pillanatfelvételeket - az adatbázis „pillanatfelvételét”, amely hasonló a merevlemezen lévő adatbázis biztonsági másolatához, vagy rögzítheti a tranzakciókat (naplókat) az adatok újraindítás utáni helyreállításához.
Hibatűrő alkalmazások létrehozásához
Képzeljük el egy hibatűrő webalkalmazás klasszikus architektúráját. Ez így működik: az összes kérést egy webes kiegyenlítő osztja el a szerverek között. Ez a rendszer stabil, mert a szerverek duplikálják egymást, és biztonsági mentést készítenek incidens esetén.
A kiegyenlítő minden kérést egy munkamenetből szigorúan egy szerverre irányít. Ez egy stick munkamenet mechanizmus: minden munkamenet egy szerverhez van társítva, ahol helyileg tárolják és feldolgozzák.
Mi történik, ha az egyik szerver meghibásodik?
A szolgáltatást ez nem érinti, mert az architektúra duplikált. De elveszítjük a halott szerver munkameneteinek egy részét. És ugyanakkor azok a felhasználók, akik ezekhez a munkamenetekhez kötődnek. Például egy ügyfél megrendelést ad le, és hirtelen kidobja az irodából. Boldogtalan lesz, amikor újra bejelentkezik, és azt tapasztalja, hogy mindent újra meg kell tenni.
Egy webes alkalmazás szükséges ahhoz, hogy nagyszámú felhasználót támogasson, és ne lassítson, hogy kényelmesen dolgozhassanak. De ha elutasítják, minden további kéréssel megnő a munkamenettárolóval való kommunikációhoz szükséges idő. Ez növeli a többi felhasználó átlagos késleltetési idejét. De nem akarnak tovább várni, mint ahogy megszokták.
Ez a probléma megoldható, mint a másik ügyfelünk, egy nagy PASS szolgáltató az USA-ból. In-Memory-t használ a webes munkamenetek fürtözésére. Ehhez nem helyben, hanem központilag - egy In-Memory fürtben - tárolja azokat. Ebben az esetben a munkamenetek sokkal gyorsabban érhetők el, mert már a RAM-ban vannak.
Amikor egy kiszolgáló összeomlik, a kiegyenlítő kéréseket küld a lefagyott kiszolgálóról más szerverekre, mint a klasszikus architektúrában. De van egy lényeges különbség: a munkamenetek egy In-Memory fürtben vannak tárolva és a szerverek hozzáférnek a kiesett szerver munkameneteihez.
Ez az architektúra növeli a teljes rendszer hibatűrését. Sőt, lehetőség van a stick session mechanizmus teljes elhagyására is.
Hibrid tranzakcióelemző feldolgozás (HTAP)
Jellemzően a tranzakciós és az elemzési rendszereket külön kell tartani. Amikor szétválnak, a fő alap terhelés alá kerül. Az analitikai feldolgozáshoz az adatokat egy replikába másolják, így az analitikai feldolgozás nem zavarja a tranzakciós folyamatokat. A másolás azonban késéssel történik – késés nélkül lehetetlen replikálni. Ha ezt szinkronban tesszük, az a fő bázist is lelassítja, és nem kapunk nyereményt.
A HTAP-ban minden másképp működik – ugyanazt az adattárat használják az alkalmazásokból származó tranzakciós betöltésekhez és az olyan elemző lekérdezésekhez, amelyek végrehajtása hosszú ideig tarthat. Ha az adatok a RAM-ban vannak, az analitikus lekérdezések gyorsabban futnak le, és az adatbázist tartalmazó szerver kevésbé terhelődik (átlagosan).
A hibrid megközelítés lebontja a falat a tranzakciófeldolgozás és az elemzés között. Ha ugyanazon a tárolón végezzük az elemzést, akkor a RAM-ból származó adatokra elemzési lekérdezések indulnak. Sokkal pontosabbak, értelmezhetőbbek és megfelelőbbek.
In-Memory megoldások integrációja
Egy (viszonylag) egyszerű módszer - fejleszteni mindent a nulláról. Az adatokat lemezen tároljuk, és a forró adatokat a memóriában tároljuk. Ez segít túlélni a szerver újraindítását vagy leállását.
Két fő forgatókönyv működik itt, amikor az adatokat a lemezen tárolják. Az elsőben a klaszter vagy egyes részek összeomlását vagy rendszeres újraindítását akarjuk túlélni - egyszerű adatbázisként szeretnénk használni. A második forgatókönyvben, amikor túl sok adat van, egy része a memóriában van.
Ha nem lehet mindent a nulláról felépíteni, akkor az In-Memory már integrálható meglévő architektúra. De nem minden In-Memory megoldás alkalmas erre. Három kötelező feltétel van. Az In-Memory megoldásnak támogatnia kell:
- szabványos mód az alatta található adatbázishoz való csatlakozáshoz (például MySQL);
- szabványos lekérdezési nyelv, hogy ne írja át és ne változtassa meg a tárolóval való interakció logikáját;
- tranzakciós - megőrzi az interakció szemantikáját.
Ha mindhárom feltétel teljesül, akkor lehetséges az integráció. Az In-Memory Data Grid-et az alkalmazás és az adatbázis közé helyezzük. Mostantól az írási kérelmek az alapul szolgáló adatbázishoz, az olvasási kérelmek pedig az alapul szolgáló adatbázishoz lesznek delegálva, ha az adatok nincsenek a gyorsítótárban.
Ha az adatokhoz való gyors hozzáférés és azok feldolgozása fontos számodra, például az üzleti elemzéshez, akkor elgondolkodhatsz az In-Memory megvalósításán. A megvalósításhoz pedig mindkét módszert használhatja új architektúra tervezésekor.
Forrás: will.com