In-Memory är en uppsättning koncept för att lagra data när den lagras i programmets RAM och disken används för säkerhetskopiering. I klassiska metoder lagras data på disk och minne lagras i cache. Till exempel, en webbapplikation med en backend för bearbetning av data begär den till lagring: den tar emot den, omvandlar den och mycket data överförs över nätverket. I In-Memory skickas beräkningar till data - till lagring, där de bearbetas och nätverket belastas mindre.
Vilka andra möjligheter finns med In-Memory och vilken typ av tillvägagångssätt är detta? Vladimir Pligin - ingenjör på GridGain. Detta granskningsmaterial kommer att vara användbart för webbapplikationsutvecklare som inte har arbetat med In-Memory och vill prova, eller är intresserade av moderna trender inom mjukvaruutveckling och arkitekturdesign.
Notera. Artikeln är baserad på utskriften av Vladimirs rapport på #GetIT Conf. Innan introduktionen av självisolering höll vi regelbundet möten och konferenser för utvecklare i Moskva och St. Petersburg: vi diskuterade trender, aktuella utvecklingsfrågor, problem och deras lösningar. Det är inte möjligt att hålla en konferens nu, men det är dags att dela med sig av användbart material från tidigare.
Vem använder In-Memory och hur
In-Memory används oftast där snabb användarinteraktion eller bearbetning av stora datamängder krävs.
- Banker Använd till exempel In-Memory för att minska förseningar när kunder använder applikationer eller för att analysera kunden innan de utfärdar ett lån.
- Fintech använder In-Memory för att förbättra prestanda för tjänster och applikationer för banker som lägger ut databehandling och analys.
- Försäkringsbolag: för att beräkna risker, till exempel genom att analysera kunddata över flera år.
- Logistikföretag. De bearbetar mycket data, till exempel för att beräkna optimala rutter för gods- och passagerartransporter med tusentals parametrar, och spåra status för försändelser.
- Detaljhandeln. In-Memory-lösningar hjälper till att betjäna kunder snabbare och bearbeta stora mängder information: försändelser, fakturor, transaktioner, närvaron av tusentals varor i lager och förbereda analytiska rapporter.
- В IoT In-Memory ersätter traditionella databaser.
- Farmaceutisk företag använder till exempel In-Memory för att sortera bland kombinationer av läkemedelssammansättningar.
Jag ska berätta några exempel på hur våra kunder använder In-Memory-lösningar och hur du kan implementera dem själv.
In-Memory som primär lagring
En av våra kunder är en stor leverantör av medicinsk vetenskaplig utrustning från USA. De använder en In-Memory-lösning som sin huvudsakliga datalagring. All data lagras på disk, och den delmängd av data som används aktivt hålls i RAM. Lagringsåtkomstmetoderna är standard - GDBC (Generic Database Connector) och SQL frågespråk.
Tillsammans kallas detta In-Memory Database (IMDB) eller Memory-Centric Storage. Denna klass av lösningar har många namn, dessa är inte de enda.
IMDB-funktioner:
- Datan som lagras i In-Memory och nås via SQL är densamma som i andra metoder. De är synkroniserade, bara sättet att presentera, sättet att ta itu med dem är annorlunda. Transaktionalitet fungerar mellan data.
- IMDB är snabbare än relationsdatabaser eftersom det är snabbare att hämta information från RAM än från disk.
- Interna optimeringsalgoritmer har färre instruktioner.
- IMDB är lämpliga för att hantera data, händelser och transaktioner i applikationer.
IMDB stöder delvis ACID: Atomicity, Consistency och Isolation. Men de stöder inte "hållbarhet" - när strömmen stängs av går all data förlorad. För att lösa problemet kan du använda ögonblicksbilder - en "snapshot" av databasen, analogt med en databassäkerhetskopiering på en hårddisk, eller registrera transaktioner (loggar) för att återställa data efter en omstart.
För att skapa feltoleranta applikationer
Låt oss föreställa oss den klassiska arkitekturen för en feltolerant webbapplikation. Det fungerar så här: alla förfrågningar distribueras av en webbbalanserare mellan servrar. Detta system är stabilt eftersom servrarna duplicerar varandra och säkerhetskopierar vid incidenter.
Balanseraren riktar alla förfrågningar från en session strikt till en server. Detta är en sticksessionsmekanism: varje session är associerad med en server där den lagras och bearbetas lokalt.
Vad händer när en av servrarna misslyckas?
Tjänsten kommer inte att påverkas eftersom arkitekturen är duplicerad. Men vi kommer att förlora en delmängd av den döda serverns sessioner. Och samtidigt användarna som är knutna till dessa sessioner. Till exempel lägger en kund en beställning och kastar ut honom plötsligt från kontoret. Han kommer att vara olycklig när han loggar in igen och upptäcker att allt måste göras igen.
En webbapplikation krävs för att stödja ett stort antal användare och inte sakta ner så att de kan arbeta bekvämt. Men om det avvisas kommer tiden det tar att kommunicera med sessionsbutiken att öka med varje efterföljande begäran. Detta ökar den genomsnittliga latensen för andra användare. Men de vill inte vänta längre än de är vana vid.
Detta problem kan lösas som vår andra kund, en stor PASS-leverantör från USA. Den använder In-Memory för att gruppera webbsessioner. För att göra detta lagrar den dem inte lokalt utan centralt - i ett In-Memory-kluster. I det här fallet är sessioner tillgängliga mycket snabbare eftersom de redan finns i RAM.
När en server kraschar skickar balansören förfrågningar från den kraschade servern till andra servrar, som i den klassiska arkitekturen. Men det finns en viktig skillnad: sessioner lagras i ett In-Memory-kluster och servrarna har tillgång till sessionerna för den fallna servern.
Denna arkitektur ökar feltoleransen för hela systemet. Dessutom är det möjligt att överge sticksessionsmekanismen helt och hållet.
Hybrid Transactional Analytical Processing (HTAP)
Vanligtvis hålls transaktions- och analytiska system åtskilda. När de separeras belastas huvudbasen. För analytisk bearbetning kopieras data till en replika så att analytisk bearbetning inte stör transaktionsprocesser. Men kopiering sker med fördröjning - det är omöjligt att replikera utan fördröjning. Om vi gör detta synkront kommer det också att sakta ner huvudbasen och vi kommer inte att få några vinster.
I HTAP fungerar allt annorlunda - samma datalager används för transaktionsladdning från applikationer och för analytiska frågor som kan ta lång tid att slutföra. När data finns i RAM, exekveras analytiska frågor snabbare och servern med databasen är mindre belastad (i genomsnitt).
En hybrid metod bryter ner muren mellan transaktionsbearbetning och analys. Om vi utför analyser på samma lagring, så startas analytiska frågor på data från RAM. De är mycket mer exakta, mer tolkbara och adekvata.
Integration av In-Memory-lösningar
Ett (relativt) enkelt sätt - utveckla allt från grunden. Vi lagrar data på disken och lagrar heta data i minnet. Detta hjälper till att överleva serverns omstarter eller avbrott.
Det finns två huvudscenarier som fungerar här när data lagras på disk. I den första vill vi överleva krascher eller regelbundna omstarter av klustret eller delarna - vi vill använda det som en enkel databas. I det andra scenariot, när det finns för mycket data, finns en del av dem i minnet.
Om det inte går att bygga allt från grunden går det att integrera In-Memory i ett redan befintlig arkitektur. Men inte alla In-Memory-lösningar är lämpliga för detta. Det finns tre obligatoriska villkor. In-Memory-lösningen måste stödja:
- standardsätt att ansluta till databasen som kommer att finnas under den (till exempel MySQL);
- ett standardfrågespråk, för att inte skriva om och ändra logiken för interaktion med lagringen;
- transaktionell - bevara interaktionens semantik.
Om alla tre villkoren är uppfyllda är integration möjlig. Vi placerar In-Memory Data Grid mellan applikationen och databasen. Nu kommer skrivbegäranden att delegeras till den underliggande databasen, och läsbegäranden kommer att delegeras till den underliggande databasen om data inte finns i cachen.
Om snabb åtkomst till data och dess bearbetning är viktigt för dig, till exempel för affärsanalys, kan du tänka på att implementera In-Memory. Och för implementering kan du använda båda metoderna när du designar en ny arkitektur.
Källa: will.com