In-Memory je sada konceptů pro ukládání dat, když jsou uložena v paměti RAM aplikace a disk se používá pro zálohování. V klasických přístupech jsou data uložena na disku a paměť je uložena v cache. Například webová aplikace s backendem pro zpracování dat si je vyžádá do úložiště: přijme je, transformuje a mnoho dat se přenese po síti. V In-Memory se výpočty odesílají do dat – do úložiště, kde se zpracovávají a síť je méně zatěžována.
Jaké další možnosti nabízí In-Memory a o jaký přístup se jedná? Vladimír Pligin - inženýr ve společnosti GridGain. Tento recenzní materiál bude užitečný pro vývojáře backendu webových aplikací, kteří s In-Memory nepracovali a chtějí to vyzkoušet nebo se zajímají o moderní trendy ve vývoji softwaru a designu architektury.
Poznámka. Článek je založen na přepisu Vladimírovy zprávy na #GetIT Conf. Před zavedením sebeizolace jsme pravidelně pořádali meetingy a konference pro vývojáře v Moskvě a Petrohradu: diskutovali jsme o trendech, aktuálních rozvojových problémech, problémech a jejich řešeních. Nyní není možné uspořádat konferenci, ale je čas podělit se o užitečné materiály z minulých.
Kdo a jak používá In-Memory
In-Memory se nejčastěji používá tam, kde je vyžadována rychlá interakce uživatele nebo zpracování velkého množství dat.
- Banky využít In-Memory například ke snížení prodlení při používání aplikací klienty nebo k analýze klienta před vydáním úvěru.
- Fintech využívá In-Memory ke zlepšení výkonu služeb a aplikací pro banky, které outsourcují zpracování a analýzu dat.
- Pojišťovny: vypočítat rizika, například analýzou zákaznických dat za několik let.
- Logistické společnosti. Zpracovávají mnoho dat, například pro výpočet optimálních tras pro nákladní a osobní dopravu s tisíci parametry a sledování stavu zásilek.
- Maloobchodní. Řešení In-Memory pomáhají zákazníkům rychleji obsluhovat a zpracovávat velké objemy informací: zásilky, faktury, transakce, přítomnost tisíců zboží ve skladech a připravovat analytické zprávy.
- В IoT In-Memory nahrazuje tradiční databáze.
- Farmaceutické společnosti používají In-Memory například k třídění kombinací složení léků.
Řeknu vám pár příkladů, jak naši klienti používají řešení In-Memory a jak je můžete sami implementovat.
In-Memory jako primární úložiště
Jedním z našich klientů je velký dodavatel lékařského vědeckého vybavení z USA. Jako hlavní úložiště dat používají řešení In-Memory. Všechna data jsou uložena na disku a podmnožina dat, která se aktivně používá, je uchovávána v paměti RAM. Metody přístupu k úložišti jsou standardní – GDBC (Generic Database Connector) a dotazovací jazyk SQL.
Souhrnně se tomu říká In-Memory Database (IMDB) nebo Memory-Centric Storage. Tato třída řešení má mnoho jmen, tato nejsou jediná.
Vlastnosti IMDB:
- Data, která jsou uložena v paměti a ke kterým se přistupuje prostřednictvím SQL, jsou stejná jako v jiných přístupech. Jsou synchronizované, odlišný je pouze způsob prezentace, způsob jejich oslovování. Mezi daty funguje transakce.
- IMDB je rychlejší než relační databáze, protože je rychlejší načíst informace z RAM než z disku.
- Interní optimalizační algoritmy mají méně instrukcí.
- IMDB jsou vhodné pro správu dat, událostí a transakcí v aplikacích.
IMDB částečně podporují ACID: Atomicity, Consistency, and Isolation. Nepodporují však „trvanlivost“ - když je napájení vypnuto, všechna data jsou ztracena. K vyřešení problému můžete použít snímky – „snímek“ databáze, obdobu zálohy databáze na pevný disk, nebo záznam transakcí (protokolů) pro obnovu dat po restartu.
Chcete-li vytvářet aplikace odolné proti chybám
Představme si klasickou architekturu webové aplikace odolné proti chybám. Funguje to takto: všechny požadavky jsou distribuovány webovým balancérem mezi servery. Tento systém je stabilní, protože servery se navzájem duplikují a zálohují v případě incidentů.
Balancér směruje všechny požadavky z jedné relace striktně na jeden server. Toto je mechanismus relace stick: každá relace je spojena se serverem, kde je lokálně uložena a zpracována.
Co se stane, když jeden ze serverů selže?
Služba nebude ovlivněna, protože architektura je duplicitní. Ale přijdeme o podmnožinu relací mrtvého serveru. A zároveň uživatelé, kteří jsou na tyto relace vázáni. Klient například zadá objednávku a najednou ho vyhodí z kanceláře. Bude nešťastný, když se znovu přihlásí a zjistí, že vše bude muset udělat znovu.
Webová aplikace je nutná pro podporu velkého počtu uživatelů a nezpomalení, aby mohli pohodlně pracovat. Pokud je však odmítnut, s každým dalším požadavkem se prodlouží čas potřebný ke komunikaci s úložištěm relací. To zvyšuje průměrnou latenci pro ostatní uživatele. Nechtějí ale čekat déle, než jsou zvyklí.
Tento problém lze vyřešit jako náš další klient, velký poskytovatel PASS z USA. Ke clusterování webových relací používá In-Memory. K tomu je neukládá lokálně, ale centrálně – v In-Memory clusteru. V tomto případě jsou relace dostupné mnohem rychleji, protože jsou již v paměti RAM.
Když se server zhroutí, balancer odešle požadavky z havarovaného serveru na jiné servery, jako v klasické architektuře. Ale je tu důležitý rozdíl: relace jsou uloženy v clusteru In-Memory a servery mají přístup k relacím padlého serveru.
Tato architektura zvyšuje odolnost proti chybám celého systému. Navíc je možné úplně opustit mechanismus relací s páčkou.
Hybridní transakční analytické zpracování (HTAP)
Transakční a analytické systémy jsou obvykle udržovány odděleně. Když se oddělí, hlavní základna je zatížena. Pro analytické zpracování jsou data zkopírována do repliky, takže analytické zpracování nenarušuje transakční procesy. Ke kopírování však dochází se zpožděním – replikaci bez zpoždění je nemožné. Pokud to uděláme synchronně, zpomalí to také hlavní základnu a nezískáme žádnou výhru.
V HTAP vše funguje jinak – stejné úložiště dat se používá pro transakční zatížení z aplikací a pro analytické dotazy, jejichž dokončení může trvat dlouho. Když jsou data v paměti RAM, analytické dotazy se provádějí rychleji a server s databází je méně zatížen (v průměru).
Hybridní přístup boří zeď mezi zpracováním transakcí a analýzou. Pokud provádíme analýzy na stejném úložišti, spustí se analytické dotazy na data z RAM. Jsou mnohem přesnější, lépe interpretovatelné a adekvátní.
Integrace řešení In-Memory
(Relativně) jednoduchý způsob - rozvíjet vše od nuly. Data uchováváme na disku a horká data ukládáme do paměti. To pomáhá přežít restartování serveru nebo výpadky.
Při ukládání dat na disk zde fungují dva hlavní scénáře. V první chceme přežít pády nebo pravidelné restarty clusteru nebo částí – chceme to používat jako jednoduchou databázi. Ve druhém scénáři, když je příliš mnoho dat, část z nich je v paměti.
Pokud není možné postavit vše od začátku, je možné integrovat In-Memory do již stávající architektura. Ale ne všechna řešení In-Memory jsou pro to vhodná. Jsou zde tři povinné podmínky. Řešení In-Memory musí podporovat:
- standardní způsob připojení k databázi, která bude umístěna pod ní (například MySQL);
- standardní dotazovací jazyk, aby nedošlo k přepsání a změně logiky interakce s úložištěm;
- transakční – zachovat sémantiku interakce.
Pokud jsou splněny všechny tři podmínky, je integrace možná. Mezi aplikaci a databázi umístíme In-Memory Data Grid. Nyní budou požadavky na zápis delegovány na podkladovou databázi a požadavky na čtení budou delegovány na podkladovou databázi, pokud data nejsou v mezipaměti.
Pokud je pro vás rychlý přístup k datům a jejich zpracování důležitý například pro obchodní analytiku, můžete přemýšlet o implementaci In-Memory. A pro implementaci můžete použít oba způsoby při návrhu nové architektury.
Zdroj: www.habr.com