In-memory na arkitektura para sa mga serbisyo sa web: mga pangunahing kaalaman at prinsipyo ng teknolohiya

Ang In-Memory ay isang hanay ng mga konsepto para sa pag-iimbak ng data kapag ito ay naka-imbak sa RAM ng application, at ang disk ay ginagamit para sa backup. Sa mga klasikal na diskarte, ang data ay nakaimbak sa disk at ang memorya ay nakaimbak sa cache. Halimbawa, hinihiling ito ng isang web application na may backend para sa pagproseso ng data sa storage: tinatanggap ito, binabago ito, at maraming data ang inililipat sa network. Sa In-Memory, ipinapadala ang mga kalkulasyon sa data - sa imbakan, kung saan pinoproseso ang mga ito at hindi gaanong na-load ang network.

Salamat sa arkitektura nito, ang In-Memory ay nagpapabilis ng pag-access ng data nang ilang beses, at kung minsan kahit na mga order ng magnitude, mas mabilis. Halimbawa, gustong makita ng mga analyst ng bangko sa isang analytical na application ang isang ulat sa mga ibinigay na loan sa dynamics ayon sa araw para sa nakaraang taon. Ang prosesong ito ay tatagal ng ilang minuto sa isang klasikong DBMS, ngunit sa In-Memory ito ay lilitaw kaagad. Ito ay dahil ang diskarte ay nagpapahintulot sa iyo na mag-cache ng higit pang impormasyon at ito ay naka-imbak sa RAM "sa kamay". Ang application ay hindi kailangang humiling ng data mula sa hard drive, ang pagkakaroon nito ay limitado sa bilis ng network at disk.

Anong iba pang mga posibilidad ang magagamit sa In-Memory at anong uri ng diskarte ito? Vladimir Pligin - engineer sa GridGain. Ang materyal sa pagsusuri na ito ay magiging kapaki-pakinabang sa mga developer ng backend ng web application na hindi nagtrabaho sa In-Memory at gustong subukan, o interesado sa mga modernong uso sa pagbuo ng software at disenyo ng arkitektura.

Nota. Ang artikulo ay batay sa transcript ng ulat ni Vladimir sa #GetIT Conf. Bago ang pagpapakilala ng self-isolation, regular kaming nagdaraos ng mga pagpupulong at kumperensya para sa mga developer sa Moscow at St. Petersburg: tinalakay namin ang mga uso, kasalukuyang isyu sa pag-unlad, mga problema at mga solusyon sa mga ito. Hindi posibleng magdaos ng kumperensya ngayon, ngunit oras na para magbahagi ng mga kapaki-pakinabang na materyales mula sa mga nakaraan.

Sino ang gumagamit ng In-Memory at kung paano

Ang In-Memory ay kadalasang ginagamit kung saan kinakailangan ang mabilis na pakikipag-ugnayan ng user o pagproseso ng malaking halaga ng data.

• Bangko gumamit ng In-Memory, halimbawa, upang mabawasan ang mga pagkaantala kapag gumagamit ng mga aplikasyon ang mga kliyente o upang pag-aralan ang kliyente bago mag-isyu ng pautang.
• Fintech gumagamit ng In-Memory upang mapabuti ang pagganap ng mga serbisyo at aplikasyon para sa mga bangko na nag-outsource sa pagproseso at pagsusuri ng data. 
• Mga kumpanya ng seguro: upang kalkulahin ang mga panganib, halimbawa, sa pamamagitan ng pagsusuri sa data ng customer sa loob ng ilang taon.
• Mga kumpanya ng logistik. Pinoproseso nila ang maraming data, halimbawa, upang kalkulahin ang pinakamainam na mga ruta para sa transportasyon ng kargamento at pasahero na may libu-libong mga parameter, at subaybayan ang katayuan ng mga pagpapadala.
• Tingi. Ang mga solusyon sa In-Memory ay nakakatulong na maglingkod sa mga customer nang mas mabilis at maproseso ang malalaking volume ng impormasyon: mga pagpapadala, mga invoice, mga transaksyon, ang pagkakaroon ng libu-libong mga produkto sa mga bodega, at maghanda ng mga analytical na ulat.
• В IoT Pinapalitan ng In-Memory ang mga tradisyonal na database.
• Parmasyutiko ang mga kumpanya ay gumagamit ng In-Memory, halimbawa, upang pagbukud-bukurin ang mga kumbinasyon ng mga komposisyon ng gamot. 

Sasabihin ko sa iyo ang ilang halimbawa kung paano ginagamit ng aming mga kliyente ang mga In-Memory na solusyon at kung paano mo maipapatupad ang mga ito sa iyong sarili.

In-Memory bilang pangunahing imbakan

Ang isa sa aming mga kliyente ay isang malaking supplier ng mga medikal na pang-agham na kagamitan mula sa USA. Gumagamit sila ng isang In-Memory na solusyon bilang kanilang pangunahing imbakan ng data. Ang lahat ng data ay naka-imbak sa disk, at ang subset ng data na aktibong ginagamit ay pinananatili sa RAM. Ang mga paraan ng pag-access sa imbakan ay karaniwan - GDBC (Generic Database Connector) at SQL query language.

Sa pangkalahatan ito ay tinatawag na In-Memory Database (IMDB) o Memory-Centric Storage. Ang klase ng mga solusyon na ito ay maraming pangalan, hindi lamang ito ang mga ito. 

Mga Tampok ng IMDB:

• Ang data na naka-imbak sa In-Memory at na-access sa pamamagitan ng SQL ay kapareho ng sa iba pang mga diskarte. Synchronized sila, iba lang yung way of presentation, the way of addressing them. Gumagana ang transaksyon sa pagitan ng data.

• Ang IMDB ay mas mabilis kaysa sa mga relational database dahil mas mabilis itong kumuha ng impormasyon mula sa RAM kaysa sa disk. 
• Ang mga panloob na algorithm ng pag-optimize ay may mas kaunting mga tagubilin.
• Ang mga IMDB ay angkop para sa pamamahala ng data, mga kaganapan at mga transaksyon sa mga application.

Ang mga IMDB ay bahagyang sumusuporta sa ACID: Atomicity, Consistency, at Isolation. Ngunit hindi nila sinusuportahan ang "tibay" - kapag ang kapangyarihan ay naka-off, ang lahat ng data ay nawala. Upang malutas ang problema, maaari kang gumamit ng mga snapshot - isang "snapshot" ng database, katulad ng isang backup ng database sa isang hard drive, o mag-record ng mga transaksyon (mga log) upang maibalik ang data pagkatapos ng pag-reboot.

Upang lumikha ng mga fault-tolerant na application

Isipin natin ang klasikong arkitektura ng isang fault-tolerant na web application. Ito ay gumagana tulad nito: lahat ng mga kahilingan ay ipinamamahagi ng isang web balancer sa pagitan ng mga server. Ang sistemang ito ay matatag dahil ang mga server ay duplicate ang isa't isa at nagba-back up sa kaso ng mga insidente.

Ang balancer ay nagdidirekta sa lahat ng mga kahilingan mula sa isang session nang mahigpit sa isang server. Ito ay isang stick session na mekanismo: ang bawat session ay nauugnay sa isang server kung saan ito ay lokal na iniimbak at pinoproseso. 

Ano ang mangyayari kapag nabigo ang isa sa mga server?

Hindi maaapektuhan ang serbisyo dahil nadoble ang arkitektura. Ngunit mawawalan tayo ng subset ng mga session ng patay na server. At kasabay nito, ang mga user na nakatali sa mga session na ito. Halimbawa, nag-order ang isang kliyente at bigla siyang pinaalis sa opisina. Hindi siya magiging masaya kapag nag-log in siyang muli at nalaman na ang lahat ay kailangang gawin muli.

Ang isang web application ay kinakailangan upang suportahan ang isang malaking bilang ng mga gumagamit at hindi pabagalin upang sila ay gumana nang kumportable. Ngunit kung ito ay tinanggihan, sa bawat kasunod na kahilingan ay tataas ang oras na kinakailangan upang makipag-usap sa tindahan ng session. Pinapataas nito ang average na latency para sa ibang mga user. Ngunit ayaw nilang maghintay ng mas matagal kaysa sa nakasanayan nila.

Ang problemang ito ay malulutas tulad ng aming isa pang kliyente, isang malaking provider ng PASS mula sa USA. Gumagamit ito ng In-Memory para i-cluster ang mga web session. Upang gawin ito, iniimbak nito ang mga ito hindi lokal, ngunit sa gitna - sa isang In-Memory cluster. Sa kasong ito, mas mabilis na available ang mga session dahil nasa RAM na ang mga ito.

Kapag nag-crash ang isang server, nagpapadala ang balancer ng mga kahilingan mula sa na-crash na server sa ibang mga server, tulad ng sa klasikal na arkitektura. Ngunit mayroong isang mahalagang pagkakaiba: ang mga session ay iniimbak sa isang In-Memory cluster at ang mga server ay may access sa mga session ng nahulog na server.

Ang arkitektura na ito ay nagpapataas ng fault tolerance ng buong system. Bukod dito, posible na iwanan ang mekanismo ng stick session sa kabuuan.

Hybrid Transactional Analytical Processing (HTAP)

Karaniwan, ang mga transactional at analytical system ay pinananatiling hiwalay. Kapag sila ay naghiwalay, ang pangunahing base ay nasa ilalim ng pagkarga. Para sa analytical processing, ang data ay kinokopya sa isang replica upang ang analytical processing ay hindi makagambala sa mga transactional na proseso. Ngunit ang pagkopya ay nangyayari nang may lag—imposibleng magtiklop nang walang lag. Kung gagawin natin ito ng sabay-sabay, ito ay magpapabagal din sa pangunahing base at hindi tayo makakakuha ng anumang panalo.

Sa HTAP, lahat ay gumagana nang iba - ang parehong data store ay ginagamit para sa transactional load mula sa mga application, at para sa mga analytical na query na maaaring tumagal ng mahabang panahon upang makumpleto. Kapag ang data ay nasa RAM, ang mga analytical na query ay isinasagawa nang mas mabilis, at ang server na may database ay hindi gaanong na-load (sa karaniwan).

Ang isang hybrid na diskarte ay sumisira sa pader sa pagitan ng pagproseso ng transaksyon at analytics. Kung magsasagawa kami ng analytics sa parehong storage, ang mga analytical na query ay ilulunsad sa data mula sa RAM. Ang mga ito ay mas tumpak, mas madaling bigyang-kahulugan at sapat.

Pagsasama ng mga In-Memory na solusyon

Isang (medyo) simpleng paraan - bumuo ng lahat mula sa simula. Pinapanatili namin ang data sa disk at nag-iimbak ng mainit na data sa memorya. Nakakatulong ito na makaligtas sa mga pag-reboot o pagkawala ng server.

Mayroong dalawang pangunahing mga sitwasyon sa trabaho dito kapag ang data ay naka-imbak sa disk. Sa una, gusto naming makaligtas sa mga pag-crash o regular na pag-reboot ng cluster o mga bahagi - gusto naming gamitin ito bilang isang simpleng database. Sa pangalawang senaryo, kapag mayroong masyadong maraming data, ang ilan sa mga ito ay nasa memorya.

Kung hindi posible na buuin ang lahat mula sa simula, posibleng isama ang In-Memory sa isang na umiiral na arkitektura. Ngunit hindi lahat ng In-Memory na solusyon ay angkop para dito. Mayroong tatlong ipinag-uutos na kondisyon. Ang In-Memory na solusyon ay dapat na sumusuporta sa:

• karaniwang paraan upang kumonekta sa database na matatagpuan sa ilalim nito (halimbawa, MySQL);
• isang karaniwang wika ng query, upang hindi muling isulat at baguhin ang lohika ng pakikipag-ugnayan sa imbakan;
• transactional - panatilihin ang semantika ng pakikipag-ugnayan.

Kung matugunan ang lahat ng tatlong kundisyon, posible ang pagsasama. Inilalagay namin ang In-Memory Data Grid sa pagitan ng application at ng database. Ngayon, ang mga kahilingan sa pagsulat ay idelegado sa pinagbabatayan na database, at ang mga kahilingan sa pagbabasa ay idelegado sa pinagbabatayan na database kung ang data ay wala sa cache.

Kung ang mabilis na pag-access sa data at ang pagproseso nito ay mahalaga sa iyo, halimbawa, para sa analytics ng negosyo, maaari mong isipin ang tungkol sa pagpapatupad ng In-Memory. At para sa pagpapatupad, maaari mong gamitin ang parehong mga pamamaraan kapag nagdidisenyo ng isang bagong arkitektura.

Pinagmulan: www.habr.com