In-memory архитектура за уеб услуги: основи на технологията и принципи

In-Memory — набор концепции за съхранение на данни, при които те се запазват в оперативната памет на приложението, а диска се използва за резервиране. В класическите подходи данните се съхраняват на диска, а паметта — в кеша. Например, уеб-приложение с бекенд за обработка на данни иска данни от хранилището: получава ги, трансформира ги, а през мрежата преминават много данни. В In-Memory изчисленията се отправят към данните — в хранилището, където се обработват и мрежата се натоварва по-малко.

Благодарение на своята архитектура, в In-Memory скоростта на достъп до данните е много по-бърза, понякога дори на порядъци. Например, аналитици от банка искат да видят отчет за отпуснатите кредити в динамика по дни за изминалата година в аналитичното приложение. Този процес в класическа СУБД ще отнеме минути, а с In-Memory ще се появи почти веднага. Всичко това, защото подходът позволява да се кешира много повече информация, която се съхранява в оперативната памет „под ръка“. Приложението не трябва да иска данни от твърдия диск, чиято наличност е ограничена от скоростта на мрежата и диска.

Какви още възможности предлага In-Memory и каква е този подход, ще обясни Владимир Плигин — инженер на компанията GridGain. Този обзорен материал ще бъде полезен за разработчиците на бекенд на уеб-приложения, които не са работили с In-Memory и искат да опитат, или се интересуват от съвременните тенденции в разработването на софтуерни решения и проектирането на архитектура.

Забележка. Статията е основана на разшифровка на доклада на Владимир на конференцията #GetIT Conf. Преди въвеждането на самоизолацията редовно провеждахме митапи и конференции за разработчици в Москва и Санкт-Петербург: обсъждахме тенденции, актуални въпроси по разработката, проблеми и техните решения. Сега конференции не могат да се проведат, но е време да споделим полезни материали от миналото.

Кой и как използва In-Memory

In-Memory се използва най-често там, където е необходимо бързо взаимодействие с потребителя или обработка на големи обеми данни.

• Банките използват In-Memory, например, за намаляване на закъсненията при използването на приложения от клиентите или за анализ на клиента преди отпускане на кредит.
• Финтех използва In-Memory, за да подобри производителността на услуги и приложения за банки, които прехвърлят обработка и анализ на данни на аутсорс. 
• Застрахователни компании: за оценка на рисковете, например, анализирайки данните на клиента през последните няколко години.
• Логистични компании. Те обработват много данни, например, за да изчислят оптималните маршрути за превоз на товари и пътници с хиляди параметри, проследявайки статуса на пратките.
• Търговия на дребно. In-Memory решенията помагат за по-бързо обслужване на клиентите и обработка на големи обеми информация: доставки, фактури, транзакции, наличности от хиляди стоки в складовете, изготвяне на аналитични отчети.
• В IoT In-Memory заменя традиционните бази данни.
• Фармацевтични компании използват In-Memory, например, за разглеждане на комбинации от съставки в лекарствата. 

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

In-Memory като основно хранилище

Един от нашите клиенти е голям доставчик на медицинско научно оборудване от САЩ. Те използват In-Memory решение като основно хранилище на данни. Всички данни се съхраняват на диск, а подмножество от данните, които се използват активно, се държат в оперативната памет. Методите за достъп до хранилището са стандартни - GDBC (Generic Database Connector) и език за заявки SQL.

Всичко това заедно се нарича In-Memory Database (IMDB) или Memory-Centric Storage. Този клас решения има много имена, не са единствени. 

Особености на IMDB:

• Данните, които се съхраняват в In-Memory и са достъпни чрез SQL, са същите, каквито са и в другите подходи. Те са синхронизирани, различава се само начинът на представяне и начинът, по който се обръщаме към тях. Между данните функционира транзакционност.

• IMDB е по-бързо от релационните бази данни, защото достъпването на информация от оперативната памет е по-бързо, отколкото от диска. 
• Вътрешните алгоритми за оптимизация имат по-малко инструкции.
• IMDB са подходящи за управление на данни, събития и транзакции в приложения.

IMDB частично поддържат ACID: атомарност, консистентност и изолираност. Но не поддържат 'дълговечност' - при изключване на захранването всички данни изчезват. За решаване на този проблем могат да се използват снепшоти - 'снимка' на базата данни, аналог на резервно копие на база данни на твърд диск, или записване на транзакции (логове), за да се възстановят данните след рестартиране.

За създаване на отказоустойчиви приложения

Представяме класическа архитектура на отказоустойчиво уеб приложение. То работи по следния начин: всички заявки се разпределят от уеб балансировчика между сървърите. Тази система е устойчива, защото сървърите дублират един друг и осигуряват защита при инциденти.

Балансировчикът насочва всички заявки от една сесия строго към един сървър. Това е механизмът на стики-сесии: всяка сесия е свързана с сървър, в който тя локално се съхранява и обработва. 

Какво ще се случи, когато един от сървъри?

Сервизът няма да пострада, защото архитектурата е дублирана. Но ние ще загубим подмножество от сесиите на умрелия сървър. А заедно с тях и потребителите, които са свързани с тези сесии. Например, клиентът прави поръчка и внезапно е изхвърлен от кабинета. Той ще бъде недоволен, когато се авторизира отново и открие, че всичко трябва да се прави отново.

От уеб приложението се изисква да поддържа голям брой потребители и да не „забавя“ работата им. Но при отказ, с всяка следваща заявка времето за комуникация с хранилището на сесиите ще нараства. Това увеличава средната латентност за останалите потребители. Но те не искат да чакат повече, отколкото са свикнали.

Тази проблема може да бъде решена от друг наш клиент — голям PASS провайдър от САЩ. Той използва In-Memory, за да клъстеризира уеб сесиите. За целта ги съхранява не локално, а централизирано — в In-Memory клъстер. В този случай сесиите са достъпни много по-бързо, защото вече са в оперативната памет.

Когато сървърът падне, балансировчикът изпраща заявките на падналия сървър към други сървъри, както в класическата архитектура. Но има важно различие: сесиите се съхраняват в In-Memory клъстер и сървърите имат достъп до сесиите на падналия сървър.

Такава архитектура повишава отказоустойчивостта на цялата система. Освен това, е възможно изцяло да се откаже от механизма на стики-сесии.

Гибридна транзакционно-аналитична обработка (HTAP)

Обикновено транзакционните и аналитичните системи се съхраняват отделно. Когато те са разделени, основната база е под натоварване. За аналитична обработка данните се копират в реплика, за да не пречат на транзакционните процеси. Но копирането става с забавяне — без забавяне репликацията е невъзможна. Ако го правим синхронно, това ще забави основната база и няма да постигнем печалба.

В HTAP всичко работи различно — същото хранилище за данни се използва както за транзакционен товар от приложенията, така и за аналитични запитвания, които могат да отнемат много време. Когато данните са в оперативната памет, аналитичните запитвания се изпълняват по-бързо, а сървърът с БД е натоварен по-малко (в средно).

Хибридният подход "чупи стената" между транзакционната обработка и анализа. Ако извършваме анализа в същото хранилище, то аналитичните запитвания се стартират на данните от оперативната памет. Те са много по-точни, по-интерпретируеми и адекватни.

Интеграция на In-Memory решения

Прост (относително) начин — да разработим всичко от нулата. Държим данните на диска, а горещите съхраняваме в паметта. Това помага да оцеляваме при рестартиране на сървъри или изключвания.

Тук работят два основни сценария, когато данните се съхраняват на диска. В първия искаме да оцеляваме падения или стандартни рестартирания на клъстера или части — искаме да го използваме като проста база данни. Във втория сценарий, когато данните са твърде много, част от тях е в паметта.

Ако няма възможност всичко да бъде построено от нулата, може да интегрирате In-Memory в вече съществуваща архитектура. Но не всички In-Memory решения са подходящи за това. Има три задължителни условия. In-Memory решението трябва да поддържа:

• стандартен начин за свързване с базата, която ще бъде под него (например, MySQL);
• стандартен език за запитвания, за да не се налага да преписваме и променяме логиката на взаимодействията с хранилището;
• транзакционност — да запазва семантиката на взаимодействието.

Ако всички три условия са изпълнени, то интеграцията е възможна. Поставяме In-Memory Data Grid между приложението и базата. Сега запитванията за запис ще се делегират към долната база, а запитванията за четене — към базата, ако данните не са в кеша.

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

Източник: habr.com