Архитектура во меморијата за веб-услуги: технолошки основи и принципи

In-Memory е збир на концепти за складирање податоци кога се складирани во RAM меморијата на апликацијата, а дискот се користи за резервна копија. Во класичните пристапи, податоците се складираат на дискот, а меморијата се складира во кешот. На пример, веб-апликација со заднина за обработка на податоци ги бара во складиште: ги прима, ги трансформира и многу податоци се пренесуваат преку мрежата. Во In-Memory, пресметките се испраќаат до податоците - до складирање, каде што се обработуваат и мрежата е помалку вчитана.

Благодарение на својата архитектура, In-Memory го забрзува пристапот до податоци за неколку пати, а понекогаш дури и побргу. На пример, банкарските аналитичари сакаат да видат во аналитичка апликација извештај за кредитите издадени во текот на изминатата година во динамика по ден. Овој процес ќе трае неколку минути на класичен DBMS, но со In-Memory ќе се појави речиси веднаш. Тоа е затоа што пристапот ви овозможува да кеширате многу повеќе информации и тие се складираат во RAM меморија „при рака“. Апликацијата не треба да бара податоци од тврдиот диск, чија достапност е ограничена со брзината на мрежата и дискот.

Кои други можности се достапни со In-Memory и каков вид на пристап е ова? Владимир Плигин - инженер во GridGain. Овој материјал за преглед ќе биде корисен за развивачите на веб-апликации кои не работеле со In-Memory и сакаат да се обидат или се заинтересирани за современите трендови во развојот на софтвер и дизајнот на архитектурата.

Имајте на ум. Написот се заснова на транскриптот од извештајот на Владимир на #GetIT Conf. Пред воведувањето на самоизолацијата, редовно одржувавме состаноци и конференции за програмерите во Москва и Санкт Петербург: разговаравме за трендовите, тековните развојни прашања, проблемите и нивните решенија. Не е можно да се одржи конференција сега, но време е да споделите корисни материјали од минатите.

Кој и како користи In-Memory

In-Memory најчесто се користи онаму каде што е потребна брза корисничка интеракција или обработка на големи количини на податоци.

• Банки користете In-Memory, на пример, за да ги намалите одложувањата кога клиентите користат апликации или да го анализирате клиентот пред да дадат заем.
• Fintech користи In-Memory за да ги подобри перформансите на услугите и апликациите за банките кои вршат аутсорсинг за обработка и анализа на податоци. 
• Осигурителни компании: да се пресметаат ризиците, на пример, со анализа на податоците за клиентите во текот на неколку години.
• Логистички компании. Тие обработуваат многу податоци, на пример, за да пресметаат оптимални рути за превоз на товар и патници со илјадници параметри и да го следат статусот на пратките.
• Малопродажба. Решенијата во меморијата помагаат да се услужат клиентите побрзо и да се обработат големи количини на информации: пратки, фактури, трансакции, присуство на илјадници стоки во магацини и подготовка на аналитички извештаи.
• В IoT In-Memory ги заменува традиционалните бази на податоци.
• Фармацевтски компаниите користат In-Memory, на пример, за сортирање преку комбинации на состави на лекови. 

Ќе ви кажам неколку примери за тоа како нашите клиенти ги користат решенијата In-Memory и како можете сами да ги имплементирате.

Во меморијата како примарна меморија

Еден од нашите клиенти е голем снабдувач на медицинска научна опрема од САД. Тие користат решение во меморијата како нивно главно складирање на податоци. Сите податоци се зачувуваат на дискот, а подмножеството податоци што активно се користи се чува во RAM меморијата. Методите за пристап до складирање се стандардни - GDBC (Generic Database Connector) и SQL јазик за пребарување.

Збирно ова се нарекува База на податоци во меморија (IMDB) или Мемориско-центрично складирање. Оваа класа на решенија има многу имиња, ова не се единствените. 

Карактеристики на IMDB:

• Податоците што се складирани во In-Memory и до кои се пристапува преку SQL се исти како и кај другите пристапи. Тие се синхронизирани, само начинот на презентација, начинот на адресирање е различен. Трансакционалноста функционира помеѓу податоците.

• IMDB е побрз од релационите бази на податоци бидејќи побрзо се преземаат информации од RAM-от отколку од дискот. 
• Внатрешните алгоритми за оптимизација имаат помалку инструкции.
• IMDB се погодни за управување со податоци, настани и трансакции во апликации.

IMDB делумно поддржуваат ACID: Atomicity, Consistency и Isolation. Но, тие не поддржуваат „издржливост“ - кога напојувањето е исклучено, сите податоци се губат. За да го решите проблемот, можете да користите снимки - „слика“ од базата на податоци, аналогно на резервна копија на базата на податоци на хард диск или да снимате трансакции (логови) за да ги вратите податоците по рестартирање.

За да креирате апликации толерантни за грешки

Ајде да ја замислиме класичната архитектура на веб-апликација толерантна за грешки. Работи вака: сите барања се дистрибуираат од веб-балансер помеѓу серверите. Овој систем е стабилен бидејќи серверите се дуплираат едни со други и прават резервни копии во случај на инциденти.

Балансерот ги насочува сите барања од една сесија строго на еден сервер. Ова е механизам за сесија со стик: секоја сесија е поврзана со сервер каде што е локално складирана и обработена. 

Што се случува кога еден од серверите не успее?

Услугата нема да биде засегната бидејќи архитектурата е дупликат. Но, ќе изгубиме подмножество од сесиите на мртвиот сервер. И во исто време, корисниците кои се врзани за овие сесии. На пример, клиентот дава нарачка и одеднаш го исфрла од канцеларијата. Тој ќе биде несреќен кога повторно ќе се најави и ќе открие дека сè ќе мора повторно да се направи.

Потребна е веб-апликација за да поддржува голем број корисници и да не забавува за да можат да работат удобно. Но, ако биде одбиено, со секое следно барање времето потребно за комуникација со продавницата за сесии ќе се зголемува. Ова ја зголемува просечната латентност за другите корисници. Но, тие не сакаат да чекаат повеќе отколку што се навикнати.

Овој проблем може да се реши како и другиот наш клиент, голем провајдер PASS од САД. Таа користи In-Memory за групирање на веб-сесии. За да го направите ова, ги складира не локално, туку централно - во кластер во меморија. Во овој случај, сесиите се достапни многу побрзо бидејќи се веќе во RAM меморијата.

Кога серверот паѓа, балансерот испраќа барања од паднатиот сервер до други сервери, како во класичната архитектура. Но, постои важна разлика: сесиите се зачувани во кластер во меморија и серверите имаат пристап до сесиите на паднатиот сервер.

Оваа архитектура ја зголемува толеранцијата на грешки на целиот систем. Покрај тоа, можно е целосно да се напушти механизмот за сесија на стапчиња.

Хибридна трансакциска аналитичка обработка (HTAP)

Вообичаено, трансакциските и аналитичките системи се чуваат одвоени. Кога ќе се разделат, главната основа доаѓа под оптоварување. За аналитичка обработка, податоците се копираат во реплика, така што аналитичката обработка не се меша во трансакциските процеси. Но, копирањето се случува со задоцнување - невозможно е да се повтори без задоцнување. Ако го направиме ова синхроно, исто така ќе ја забави главната база и нема да добиеме никакви добивки.

Во HTAP, сè работи поинаку - истата продавница за податоци се користи за трансакциско оптоварување од апликациите и за аналитички прашања за кои може да потрае долго време за да се завршат. Кога податоците се во RAM меморија, аналитичките барања се извршуваат побрзо, а серверот со базата на податоци е помалку вчитан (во просек).

Хибриден пристап го руши ѕидот помеѓу обработката на трансакциите и аналитиката. Ако вршиме аналитика на истото складирање, тогаш аналитичките барања се стартуваат на податоците од RAM меморијата. Тие се многу поточни, поинтерпретабилни и поадекватни.

Интеграција на решенија во меморијата

(релативно) едноставен начин - развијте сè од нула. Ги чуваме податоците на дискот и складираме топли податоци во меморијата. Ова помага да се преживее рестартирањето или прекините на серверот.

Постојат две главни сценарија кои работат овде кога податоците се складираат на дискот. Во првиот, сакаме да преживееме падови или редовно рестартирање на кластерот или делови - сакаме да го користиме како едноставна база на податоци. Во второто сценарио, кога има премногу податоци, дел од нив се во меморија.

Ако не е можно да се изгради сè од нула, можно е да се интегрира In-Memory во веќе постоечка архитектура. Но, не сите решенија во меморијата се погодни за ова. Постојат три задолжителни услови. Решението во меморијата мора да поддржува:

• стандарден начин за поврзување со базата на податоци што ќе се наоѓа под неа (на пример, MySQL);
• стандарден јазик за пребарување, за да не се препишува и менува логиката на интеракција со складиштето;
• трансакциско - зачувување на семантиката на интеракцијата.

Доколку се исполнети сите три услови, тогаш е можна интеграција. Ја поставуваме мрежата на податоци во меморијата помеѓу апликацијата и базата на податоци. Сега барањата за пишување ќе бидат делегирани во основната база на податоци, а барањата за читање ќе бидат делегирани во основната база на податоци ако податоците не се во кешот.

Ако ви е важен брзиот пристап до податоците и нивната обработка, на пример, за деловна аналитика, можете да размислите за имплементирање на In-Memory. И за имплементација, можете да ги користите двата методи при дизајнирање нова архитектура.

Извор: www.habr.com