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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

(Сравнително) прост начин - развийте всичко от нулата. Ние съхраняваме данни на диск и съхраняваме горещи данни в паметта. Това помага да се оцелее при рестартиране или прекъсване на сървъра.

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

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

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

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

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

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