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: атомарност, последователност и изолация. Но не поддържат „дълготрайност“ — при загуба на захранване, всички данни изчезват. За решаване на проблема могат да се използват снимки — „снимка“ на базата данни, аналог на резервно копие на базата данни на твърд диск, или записване на транзакции (логове), за да се възстановят данните след рестартиране.

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

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

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

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

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

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

Тази проблема може да бъде решена, както и от наш друг клиент - голям 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