In-Memory — egy adatok tárolásának koncepciója, amikor azokat az alkalmazás memóriájában tárolják, míg a lemez a biztonsági mentéshez használatos. Klasszikus megközelítésekben az adatok a lemezen tárolódnak, míg a memória a gyorsítótárban van. Például egy webalkalmazás, amelynek backendje az adatok feldolgozására szolgál, lekéri azokat a tárolóból: megkapja, átalakítja, és sok adatot továbbít a hálózaton. Az In-Memory számítások az adatokhoz irányulnak - a tárolószámításokhoz, amelyek ahol feldolgozásra kerülnek, és a hálózat terhelése csökken.
Milyen egyéb lehetőségek érhetők el az In-Memory-val, és miről szól ez a megközelítés, azt ismerteti Vlagyimir Pligin — a GridGain cég mérnöke. Ez a bevezető anyag hasznos lesz azok számára, akik webalkalmazások backend fejlesztésével foglalkoznak, de még nem dolgoztak In-Memory-val, vagy érdeklik a modern szoftverfejlesztési trendek és az architektúra tervezése.
Megjegyzés. A cikk Vlagyimir előadásának a #GetIT Conf konferencián történt leírásán alapul. A kijárási tilalom bevezetése előtt rendszeresen tartottunk meet-upokat és konferenciákat fejlesztők számára Moszkvában és Szentpéterváron: a trendeket, aktuális fejlesztési kérdéseket, problémákat és azok megoldásait vitattuk meg. Jelenleg nem lehet konferenciát tartani, de elérkezett az idő, hogy megosszuk a múltbeli hasznos anyagokat.
Ki és hogyan használja az In-Memory-t
Az In-Memory-t leggyakrabban ott használják, ahol gyors interakcióra van szükség a felhasználókkal vagy nagy adatmennyiségek feldolgozására.
- Bankok az In-Memory használatával például csökkentik a késlekedéseket, amikor az ügyfelek alkalmazásokat használnak, vagy az ügyfél elemzésére a hitelkiadás előtt.
- Fintech az In-Memory-t használja, hogy javítsa a banki szolgáltatások és alkalmazások teljesítményét, amelyek az adatfeldolgozást és analízist kiszervezik.
- Biztosítótársaságok: a kockázatok értékeléséhez, például a kliens adatait több évre visszamenőleg elemezve.
- Logisztikai vállalatok. Nagy mennyiségű adatot dolgoznak fel, például az optimalizált útvonalak kiszámításához teher- és személyszállításhoz, ezer paraméter figyelembevételével, az elküldött csomagok státusának nyomon követésére.
- Kiskereskedelem. Az In-Memory megoldások gyorsabban szolgálják ki az ügyfeleket és kezelik a nagy mennyiségű információt: szállítások, számlák, tranzakciók, több ezer termék elérhetősége a raktárakban, analitikus jelentések készítése.
- A IoT Az In-Memory helyettesíti a hagyományos adatbázisokat.
- Gyógyszeripari vállalatok használják az In-Memory-t, például gyógyszerkombinációk kipróbálására.
Pár példát fogok bemutatni arra, hogyan használják ügyfeleink az In-Memory megoldásokat, és hogy ön hogyan implementálhatja őket.
In-Memory mint alap tároló
Az egyik ügyfelünk egy amerikai nagy orvosi tudományos eszközöket szállító vállalat. Az In-Memory megoldást használják alapadat-tárolóként. Minden adatot lemezen tárolnak, az aktívan használt adatok egy részét pedig a RAM-ban tartják. Az adattárolás módszerei szabványosak: GDBC (Generic Database Connector) és SQL kérdőnyelv.
Ezt az egészet In-Memory Database (IMDB) vagy Memory-Centric Storage néven hívják. Ennek a megoldásosztálynak sok elnevezése van, ezek nem az egyetlenek.
Az IMDB jellemzői:
- Az In-Memory-ben tárolt és SQL-en keresztül elérhető adatok megegyeznek a többi megközelítéssel. Szinkronizáltak, csak a megjelenítés módja és a hozzáférési módszer különbözik. Az adatok között tranzakciós kapcsolatok működnek.
- Az IMDB gyorsabb, mint a relációs adatbázisok, mert az információk elérése a RAM-ból gyorsabb, mint a lemezről.
- A belső optimalizáló algoritmusok kevesebb utasítással dolgoznak.
- Az IMDB-k alkalmasak az adatok, események és tranzakciók kezelésére az alkalmazásokban.
Az IMDB részben támogatják az ACID-t: atomikus, konzisztens és izolált. De nem támogatják a „tartósságot” — áramtalanítás esetén minden adat eltűnik. A probléma megoldására használhatók pillanatfelvételek — az adatbázis „képe”, a HDD-re történő biztonsági mentés analógja, vagy tranzakciók (naplók) rögzítése az adatok helyreállítása érdekében újraindítás után.
Hibatűrő alkalmazások létrehozásához
Képzeljünk el egy klasszikus hibajavító webalkalmazás-architektúrát. Ez úgy működik, hogy a webes terheléselosztó elosztja az összes kérést a szerverek között. Ez a rendszer megbízható, mert a szerverek duplikálják egymást és biztosítják a védelmet incidensek esetén.
A terheléselosztó minden kérést egyetlen munkamenetből szigorúan egy szerverre irányít. Ez a sticky session mechanizmus: minden munkamenet kötődik a szerverhez, amelyben helyben tárolódik és feldolgozásra kerül.
Mi történik, amikor az egyik szerver meghibásodik? szerverek?
A szolgáltatás nem szenved csorbát, mert az architektúra párhuzamosítva van. De elveszítünk egy részhalmazt a meghalt szerver munkameneteiből,. Továbbá a felhasználókat is, akik ezekhez a munkamenetekhez vannak kötve. Például, ha egy ügyfél megrendelést ad le, és hirtelen kirúgják a fiókjából. Ő nem lesz boldog, amikor újra be kell jelentkeznie, és rájön, hogy mindent újra kell állítani.
A webalkalmazástól elvárják, hogy támogasson nagy számú felhasználót, és ne «lassuljon le», hogy kényelmesen tudjanak dolgozni. De a hiba esetén, minden egyes további kérés lassabb válaszidőt fog eredményezni a munkamenet tárolóval való kommunikációban. Ez növeli a többi felhasználóra vonatkozó átlagos késleltetést (latency). De ők nem akarnak többet várni, mint amennyire már hozzászoktak.
Ezt a problémát meg lehet oldani, ahogyan egy másik ügyfelünk – egy nagy amerikai PASS szolgáltató. In-Memory-t használ a webmunkamenetek klaszterezésére. Ehhez nem helyben, hanem központosítva tárolja őket – In-Memory klaszterben. Ebben az esetben a munkamenetek sokkal gyorsabban elérhetők, mert már a RAM-ban vannak.
Amikor a szerver leáll, a terheléselosztó a leállt szerverre irányuló kéréseket más szerverekhez küldi, ahogyan az a klasszikus architektúrában történik. De van egy fontos különbség: a munkamenetek In-Memory klaszterben tárolódnak, és a szerverek hozzáférnek a leállt szerver munkameneteihez.
Ez az architektúra növeli az egész rendszer hibajavító képességét. Ráadásul lehetőség van a sticky session mechanizmus teljes elhagyására.
Hibrid tranzakciós-analitikai feldolgozás (HTAP)
A tranzakciós és analitikai rendszerek általában különböznek. Amikor ezek szétválasztódnak, a fő adatbázis terhelés alá kerül. Az analitikai feldolgozás érdekében az adatokat egy másolatba másolják, hogy az analitikai feldolgozás ne zavarja a tranzakciós folyamatokat. A másolás azonban késéssel történik — késés nélkül a replikáció lehetetlen. Ha ezt szinkron módon végezzük, ez a fő adatbázist is lelassítja, így nem nyerünk semmit.
Az HTAP esetében minden másképp működik — ugyanaz az adattároló használható a tranzakciós terheléshez az alkalmazásoktól, és az analitikai lekérdezésekhez, amelyek hosszú ideig tarthatnak. Amikor az adatok az operatív memóriában vannak, az analitikai lekérdezések gyorsabban futnak, és az adatbázis szerver átlaga terhelése csökken.
A hibrid megközelítés „megtöri a falat” a tranzakciók feldolgozása és az analitika között. Ha ugyanazon a tárolón végezzük az analitikát, az analitikai lekérdezések az operatív memóriából indulnak el. Ezek sokkal pontosabbak, jobban értelmezhetők és megfelelőbbek.
In-Memory megoldások integrálása
Egy viszonylag egyszerű mód — mindent a nulláról megtervezni. Az adatokat a lemezen tartjuk, a forrókat pedig a memóriában. Ez segít túlélni a szerverek újraindítását vagy leállítását.
Itt két alapvető forgatókönyv működik, amikor az adatok a lemezen vannak tárolva. Az elsőben az eséseket vagy a klaszter vagy részeinek normál újraindítását akarjuk túlélni — szeretnénk egyszerű adatbázisként használni. A második forgatókönyvben, amikor túl sok adat van, egy részük a memóriában van.
Ha nincs lehetőség mindent a nulláról építeni, az In-Memory integrálható egy már létező architektúrába. De nem minden In-Memory megoldás alkalmas erre. Három kötelező feltétel van. Az In-Memory megoldásnak támogatnia kell:
- a normál kapcsolódási módot az alatta lévő adatbázishoz (például MySQL);
- a standard lekérdező nyelvet, hogy ne kelljen átírni és megváltoztatni a tárolókkal való interakció logikáját;
- a tranzakcionális jelleget — megőrizni az interakció szemantikáját.
Ha mindhárom feltétel teljesül, akkor a integráció lehetséges. Az In-Memory Data Gridet az alkalmazás és az adatbázis közé helyezzük. Most a írási lekérdezések az alsóbb szintű adatbázisnak, míg az olvasási lekérdezések az adatbázisnak lesznek delegálva, ha az adatok nincsenek a gyorsítótárban.
Ha fontos az adatok gyors hozzáférése és feldolgozása, például üzleti elemzésekhez, akkor érdemes elgondolkodni az In-Memory bevezetésén. Az új architektúra tervezése során mindkét módszert felhasználhatja a megvalósításhoz.
Forrás: habr.com
