Mälu arhitektuur veebiteenustele: tehnoloogia ja põhiprintsiibid

In-Memory — andmete salvestamise kontseptsioonide kogum, kus andmed salvestatakse rakenduse mällu, samas kui ketast kasutatakse varukohana. Klassikalistes lähenemistes salvestatakse andmed kettale ja mälu kasutatakse vahemäluna. Näiteks veebirakendus, millel on andmete töötlemiseks tagapülg, küsib andmeid salvestuspunktist: saab, muundab ja edastab palju andmeid võrgus. In-Memory korral saadetakse arvutused andmetele — salvestuses, kus need töödeldakse ja võrgu koormus väheneb.

Tänu oma arhitektuurile on In-Memory andmete juurde pääsemise kiirus kordades, mõnikord isegi kordades kiirem. Näiteks tahavad panga analüütikud vaadata analüütilisest rakendusest eelmise aasta päeva kaupa väljastatud laenude aruannet. See protsess klassikalises andmebaasis võtab minuteid, samas kui In-Memory puhul ilmub see peaaegu kohe. See on tingitud sellest, et lähenemine võimaldab vahemäluda palju rohkem teavet ja see hoitakse mälus 'käepärast'. Rakendusel ei ole vaja küsida andmeid kõvakettalt, mille kätte saamine on piiratud võrgu ja ketta kiirusest.

Millised veel võimalused on saadaval In-Memoryga ja mis see lähenemine endast kujutab, räägib Vladimir Pligin — GridGain'i insener. See ülevaateosa on kasulik veebirakenduste tagapinna arendajatele, kes ei ole In-Memoryga töötanud ja tahavad proovida, või huvituvad kaasaegsetest tarkvaraarenduse ja arhitektuuri projekteerimise trendidest.

Märkus. Artikkel põhineb Vladimiri ettekande tõlgendusel #GetIT Conf. Enne isoleerimise kehtestamist korraldasime regulaarselt koosolekuid ja konverentse arendajatele Moskvas ja Peterburis: arutasime trende, aktuaalseid arendusprobleeme ja nende lahendusi. Praegu ei saa konverentse pidada, kuid on ideaalne aeg jagada varasemaid väärtuslikke materjale.

Kes ja kuidas kasutab In-Memory'd

In-Memory'd kasutatakse kõige sagedamini seal, kus on vajalik kiire kasutajaga suhtlemine või suurte andmemahtude töötlemine.

• Pangad kasutavad In-Memory't näiteks, et vähendada kliendi rakenduste kasutamisel tekkivaid viivitusi või klientide analüüsimiseks laenu väljastamise eel.
• Fintech kasutab In-Memory't, et parandada pankade teenuste ja rakenduste jõudlust, mis usaldavad andmete töötlemise ja analüüsi outsource'imisele. 
• Kindlustusettevõtted: risk calculation, for example, by analyzing customer data over several years.
• Logistics companies. They process a lot of data, for instance, to calculate optimal routes for cargo and passenger transport with thousands of parameters, tracking the status of shipments.
• Retail. In-Memory solutions help serve customers faster and process large volumes of information: shipments, invoices, transactions, availability of thousands of products in warehouses, preparing analytical reports.
• Uues IoT In-Memory replaces traditional databases.
• Pharmaceutical companies use In-Memory, for example, to test combinations of drug formulations. 

I will share several examples of how our clients use In-Memory solutions and how you can implement them yourself.

In-Memory as a primary storage

One of our clients is a large supplier of medical scientific equipment from the USA. They use an In-Memory solution as their primary data storage. All data is stored on disk, while the subset of data that is actively used is kept in RAM. The methods of accessing the storage are standard - GDBC (Generic Database Connector) and SQL query language.

All together this is called In-Memory Database (IMDB) or Memory-Centric Storage. This class of solutions has many names, and these are not the only ones. 

Features of IMDB:

• The data stored in In-Memory and accessed via SQL is the same as in other approaches. They are synchronized, differing only in the method of representation and access. Transactionality operates between the data.

• IMDB is faster than relational databases because retrieving information from RAM is faster than from disk. 
• Internal optimization algorithms have fewer instructions.
• IMDB is suitable for managing data, events, and transactions in applications.

IMDB partially supports ACID: atomicity, consistency, and isolation. But they do not support 'durability' - all data is lost when power is turned off. To solve this issue, snapshots can be used - a 'snapshot' of the database, similar to a database backup to a hard drive, or transactions (logs) can be recorded to restore data after a reboot.

For creating fault-tolerant applications

Kujutame ette klassikalise talitluspüsiva veebirakenduse arhitektuuri. See töötab niimoodi: kõik päringud jaotab veebibalancer serverite vahel. See süsteem on vastupidav, sest serverid dubleerivad üksteist ja kaitsevad üksteist intsidentide korral.

Balansseerija suunab kõik päringud ühe seansi kohta rangelt ühele serverile. See on kleebilise seanssi mehhanism: iga seanss on seotud serveri, kus seda salvestatakse ja töödeldakse kohapealselt. 

Mis juhtub, kui üks neist serveritest tõrkub? serverid?

Teenusele see ei mõju, sest arhitektuur on dubleeritud. Kuid me kaotame osa surnud serveri seanssidest. Ja koos nendega ka kasutajad, kes on nende seanssidega seotud. Näiteks, kui klient tellib ja järsku visatakse ta väljas. Ta on pettunud, kui peab uuesti logima ja avastab, et peab kogu protsessi uuesti läbima.

Veebirakenduse peab suutma toetada suurt hulka kasutajaid ja mitte „lasksu” töödelda, et neil oleks mugav töötada. Kuid juhul, kui server tõrkub, siis iga järgmise päringu puhul suureneb aeg seansi salvestuspaigaga suhtlemiseks. See suurendab keskmist latentsust ülejäänud kasutajate seas. Kuid nad ei soovi oodata kauem, kui nad on harjunud.

Seda probleemi saab lahendada, nagu teised meie kliendid — suur PASS-teenuse pakkuja USA-st. Nad kasutavad In-Memory rakendust, et klastriffida veebiseansse. Selleks ei salvestata neid kohapeal, vaid keskelt — In-Memory klastris. Sel juhul on seansid oluliselt kiiremini kättesaadavad, kuna need on juba mälus.

Kui server kukub, suunab balanseerija kukkunud päringud teistele serveritele, nagu klassikalises arhitektuuris. Kuid siin on oluline erinevus: seansid on salvestatud In-Memory klastrisse ja serveritel on juurdepääs kukkunud serveri seanssidele.

Selline arhitektuur suurendab kogu süsteemi talitlusvõimet. Veelgi enam, on võimalik üldse loobuda kleebis seanssi mehhanismist.

Hübriidne tehingu- ja analüütiline töötlemine (HTAP)

Tavaliselt hoitakse tehingu- ja analüüsisüsteeme eraldi. Kui need eraldatakse, koormatakse peamine andmebaas. Analüütilise töötlemise jaoks kopeeritakse andmed koopia, et analüütiline töötlus ei segaks tehinguprotsesse. Kuid kopeerimine toimub viivitusega — ilma viivitusteta ei ole replikatsioon võimalik. Kui teeme seda sünkroonselt, aeglustaks see samuti peamist andmebaasi ja kasu ei saavuta.

HTAP-s töötab kõik teisiti — sama andmete ladustamise süsteemi kasutatakse rakenduste tehingukoormuseks ja analüütilisteks päringuteks, mis võivad kaua aega võtta. Kui andmed asuvad mälus, täidetakse analüütilised päringud kiiremini ja andmebaasiserver koormatakse vähem (keskmiselt).

Hübriidne lähenemine 'murdab seina' tehingute töötlemise ja analüütika vahel. Kui teeme analüüsi samas andmehoidlas, siis käivitatakse analüütilised päringud otse mälus olevate andmete põhjal. Need on palju täpsemad, paremini tõlgendatavad ja adekvaatsemad.

In-Memory lahenduste integreerimine

Lihtne (suhteliselt) viis — arendada kõik nullist. Me hoiame andmed kettal, samas kui kuumad hoiame mälus. See aitab taluda serverite taaskäivitusi või väljalülitamisi.

Siin on kaks peamist stsenaariumi, kui andmed on kettal. Esimeses soovime taluda tõuse või regulaarseid serveri taaskäivitusi — soovime kasutada seda nagu lihtsat andmebaasi. Teises stsenaariumis, kui andmeid on liiga palju, on osa neist mälus.

Kui ei ole võimalik kõike nullist ehitada, on võimalik integreerida In-Memory juba olevasse arhitektuuri. Kuid mitte kõik In-Memory lahendused ei sobi selleks. On kolm kohustuslikku tingimust. In-Memory lahendus peab toetama:

• standardset ühendusviisi andmebaasiga, mis asub selle all (näiteks MySQL);
• standardkeelt päringute tegemiseks, et mitte ümber kirjutada ja muuta ladustamisega suhtlemise loogikat;
• tehinguandmeid — säilitama interaktsiooni semantika.

Kui kõik kolm tingimust on täidetud, siis on integreerimine võimalik. Paneme In-Memory Data Grid'i rakenduse ja andmebaasi vahele. Nüüd kirjutamisjärgud delegatakse alumisse andmebaasi, ja lugemispäringud lähevad andmebaasi, kui andmeid pole vahemälus.

Kui kiire andmete juurdepääs ja töötlemine, näiteks ärianalüüsiks, on teile oluline, võiks mõelda In-Memory rakendamisele. Uue arhitektuuri projekteerimisel võite kasutada mõlemat meetodit.

Allikas: habr.com