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