In-Memory je súbor konceptov na ukladanie údajov, keď sú uložené v pamäti RAM aplikácie a disk sa používa na zálohovanie. V klasických prístupoch sú dáta uložené na disku a pamäť je uložená vo vyrovnávacej pamäti. Napríklad webová aplikácia s backendom na spracovanie údajov si ich vyžiada do úložiska: prijme ich, transformuje a množstvo údajov sa prenesie cez sieť. V In-Memory sa výpočty posielajú do dát – do úložiska, kde sa spracujú a sieť je menej zaťažená.
Aké ďalšie možnosti ponúka In-Memory a o aký prístup ide? Vladimír Pligin - inžinier v spoločnosti GridGain. Tento recenzný materiál bude užitočný pre vývojárov backendu webových aplikácií, ktorí nepracovali s In-Memory a chcú to vyskúšať, alebo sa zaujímajú o moderné trendy vo vývoji softvéru a dizajne architektúry.
Poznámka. Článok je založený na prepise Vladimírovej správy na #GetIT Conf. Pred zavedením samoizolácie sme pravidelne organizovali stretnutia a konferencie pre vývojárov v Moskve a Petrohrade: diskutovali sme o trendoch, aktuálnych problémoch vývoja, problémoch a ich riešeniach. Teraz nie je možné usporiadať konferenciu, ale je čas podeliť sa o užitočné materiály z minulých.
Kto a ako používa In-Memory
In-Memory sa najčastejšie používa tam, kde je potrebná rýchla interakcia používateľa alebo spracovanie veľkého množstva dát.
- Banky využiť In-Memory napríklad na skrátenie oneskorení pri používaní aplikácií klientmi alebo na analýzu klienta pred poskytnutím úveru.
- Fintech používa In-Memory na zlepšenie výkonu služieb a aplikácií pre banky, ktoré outsourcujú spracovanie a analýzu údajov.
- Poisťovne: na výpočet rizík, napríklad analýzou údajov o zákazníkoch počas niekoľkých rokov.
- Logistické spoločnosti. Spracúvajú množstvo údajov napríklad na výpočet optimálnych trás pre nákladnú a osobnú dopravu s tisíckami parametrov a sledujú stav zásielok.
- Maloobchod. In-Memory riešenia pomáhajú rýchlejšie obsluhovať zákazníkov a spracovávať veľké objemy informácií: zásielky, faktúry, transakcie, prítomnosť tisícov tovaru v skladoch a pripravovať analytické správy.
- В IoT In-Memory nahrádza tradičné databázy.
- Farmaceutický spoločnosti používajú In-Memory napríklad na triedenie kombinácií liekových kompozícií.
Poviem vám niekoľko príkladov toho, ako naši klienti používajú riešenia In-Memory a ako ich môžete sami implementovať.
In-Memory ako primárne úložisko
Jedným z našich klientov je veľký dodávateľ medicínskeho vedeckého vybavenia z USA. Ako hlavné úložisko dát používajú riešenie In-Memory. Všetky údaje sú uložené na disku a podmnožina údajov, ktoré sa aktívne používajú, sa uchováva v pamäti RAM. Metódy prístupu k úložisku sú štandardné – GDBC (Generic Database Connector) a dotazovací jazyk SQL.
Súhrnne sa to nazýva In-Memory Database (IMDB) alebo Memory-Centric Storage. Táto trieda riešení má veľa mien, nie sú to jediné.
Vlastnosti IMDB:
- Údaje, ktoré sú uložené v pamäti a ku ktorým sa pristupuje prostredníctvom SQL, sú rovnaké ako v iných prístupoch. Sú synchronizované, odlišný je len spôsob prezentácie, spôsob ich oslovovania. Medzi dátami funguje transakcia.
- IMDB je rýchlejšia ako relačné databázy, pretože je rýchlejšie získavať informácie z RAM ako z disku.
- Interné optimalizačné algoritmy majú menej inštrukcií.
- IMDB sú vhodné na správu dát, udalostí a transakcií v aplikáciách.
IMDB čiastočne podporujú ACID: Atomicity, Consistency a Isolation. Nepodporujú však „trvanlivosť“ - keď sa vypne napájanie, všetky údaje sa stratia. Na vyriešenie problému môžete použiť snímky – „snímku“ databázy, analogickú so zálohou databázy na pevný disk, alebo zaznamenávať transakcie (protokoly) na obnovenie údajov po reštarte.
Na vytváranie aplikácií odolných voči chybám
Predstavme si klasickú architektúru webovej aplikácie odolnej voči chybám. Funguje to takto: všetky požiadavky sú distribuované webovým balancérom medzi servermi. Tento systém je stabilný, pretože servery sa navzájom duplikujú a zálohujú v prípade incidentov.
Balancér nasmeruje všetky požiadavky z jednej relácie striktne na jeden server. Toto je mechanizmus relácie tyče: každá relácia je spojená so serverom, kde je lokálne uložená a spracovaná.
Čo sa stane, keď jeden zo serverov zlyhá?
Služba nebude ovplyvnená, pretože architektúra je duplikovaná. Ale prídeme o podmnožinu relácií mŕtveho servera. A zároveň aj používatelia, ktorí sú na tieto relácie viazaní. Napríklad klient zadá objednávku a zrazu ho vyhodí z kancelárie. Bude nešťastný, keď sa znova prihlási a zistí, že všetko bude treba urobiť znova.
Webová aplikácia je potrebná na to, aby podporovala veľké množstvo používateľov a nespomalila, aby mohli pohodlne pracovať. Ak je však odmietnutá, s každou ďalšou požiadavkou sa čas potrebný na komunikáciu s úložiskom relácie predĺži. To zvyšuje priemernú latenciu pre ostatných používateľov. Nechcú však čakať dlhšie, ako sú zvyknutí.
Tento problém je možné vyriešiť ako náš ďalší klient, veľký poskytovateľ PASS z USA. Na klastrovanie webových relácií používa In-Memory. Aby to urobil, neukladá ich lokálne, ale centrálne – v klastri In-Memory. V tomto prípade sú relácie dostupné oveľa rýchlejšie, pretože sú už v pamäti RAM.
Keď server zlyhá, balancer odošle požiadavky z havarovaného servera na iné servery, ako v klasickej architektúre. Ale je tu dôležitý rozdiel: relácie sú uložené v klastri In-Memory a servery majú prístup k reláciám padlého servera.
Táto architektúra zvyšuje odolnosť celého systému voči chybám. Okrem toho je možné úplne opustiť mechanizmus relácie palice.
Hybridné transakčné analytické spracovanie (HTAP)
Transakčné a analytické systémy sú zvyčajne oddelené. Keď sa oddelia, hlavná základňa je zaťažená. Pri analytickom spracovaní sa údaje skopírujú do repliky, aby analytické spracovanie nezasahovalo do transakčných procesov. Kopírovanie však prebieha s oneskorením – replikácia bez oneskorenia je nemožná. Ak to urobíme synchrónne, spomalí to aj hlavnú základňu a nezískame žiadnu výhru.
V HTAP všetko funguje inak – rovnaké úložisko údajov sa používa na transakčné načítanie z aplikácií a na analytické dotazy, ktorých dokončenie môže trvať dlho. Keď sú údaje v RAM, analytické dotazy sa vykonávajú rýchlejšie a server s databázou je menej zaťažený (v priemere).
Hybridný prístup búra bariéru medzi spracovaním transakcií a analýzou. Ak vykonávame analýzy na rovnakom úložisku, potom sa spustia analytické dotazy na údaje z pamäte RAM. Sú oveľa presnejšie, interpretovateľnejšie a adekvátnejšie.
Integrácia riešení In-Memory
(Pomerne) jednoduchý spôsob - rozvíjať všetko od nuly. Dáta uchovávame na disku a horúce dáta ukladáme do pamäte. To pomáha prežiť reštarty servera alebo výpadky.
Pri ukladaní údajov na disk tu fungujú dva hlavné scenáre. V prvom chceme prežiť pády alebo pravidelné reštarty klastra alebo častí – chceme ho použiť ako jednoduchú databázu. V druhom scenári, keď je príliš veľa údajov, časť z nich je v pamäti.
Ak nie je možné postaviť všetko od začiatku, je možné integrovať In-Memory do už existujúcej architektúry. Ale nie všetky riešenia In-Memory sú na to vhodné. Existujú tri povinné podmienky. Riešenie In-Memory musí podporovať:
- štandardný spôsob pripojenia k databáze, ktorá sa bude nachádzať pod ňou (napríklad MySQL);
- štandardný dopytovací jazyk, aby nedošlo k prepísaniu a zmene logiky interakcie s úložiskom;
- transakčné – zachovávajú sémantiku interakcie.
Ak sú splnené všetky tri podmienky, integrácia je možná. Medzi aplikáciu a databázu umiestnime In-Memory Data Grid. Teraz budú požiadavky na zápis delegované do základnej databázy a požiadavky na čítanie budú delegované do základnej databázy, ak údaje nie sú vo vyrovnávacej pamäti.
Ak je pre vás rýchly prístup k dátam a ich spracovanie dôležitý, napríklad pre obchodné analýzy, môžete porozmýšľať nad implementáciou In-Memory. A na implementáciu môžete použiť oba spôsoby pri návrhu novej architektúry.
Zdroj: hab.com