In-Memory is 'n stel konsepte vir die stoor van data wanneer dit in die toepassing se RAM gestoor word, en die skyf word vir rugsteun gebruik. In klassieke benaderings word data op skyf gestoor en geheue word in kas gestoor. Byvoorbeeld, 'n webtoepassing met 'n agterkant vir die verwerking van data versoek dit in berging: dit ontvang dit, transformeer dit en baie data word oor die netwerk oorgedra. In In-Memory word berekeninge na die data gestuur – stoor toe, waar dit verwerk word en die netwerk minder gelaai is.
Watter ander moontlikhede is beskikbaar met In-Memory en watter soort benadering is dit? Vladimir Pligin - ingenieur by GridGain. Hierdie hersieningsmateriaal sal nuttig wees vir webtoepassings-agtergrondontwikkelaars wat nie met In-Memory gewerk het nie en wil probeer, of belangstel in moderne neigings in sagteware-ontwikkeling en argitektuurontwerp.
Let daarop. Die artikel is gebaseer op die transkripsie van Vladimir se verslag by die #GetIT Conf. Voor die bekendstelling van selfisolasie het ons gereeld ontmoetings en konferensies vir ontwikkelaars in Moskou en St. Petersburg gehou: ons het tendense, huidige ontwikkelingskwessies, probleme en hul oplossings bespreek. Dit is nie moontlik om nou 'n konferensie te hou nie, maar dit is tyd om nuttige materiaal van voriges te deel.
Wie gebruik In-Memory en hoe
In-Geheue word meestal gebruik waar vinnige gebruikersinteraksie of verwerking van groot hoeveelhede data vereis word.
- Banke gebruik In-Memory, byvoorbeeld, om vertragings te verminder wanneer kliënte toepassings gebruik of om die kliënt te ontleed voordat 'n lening uitgereik word.
- Fintech gebruik In-Memory om die werkverrigting van dienste en toepassings te verbeter vir banke wat dataverwerking en -analise uitkontrakteer.
- Versekeringsmaatskappye: om risiko's te bereken, byvoorbeeld deur klantdata oor verskeie jare te ontleed.
- Logistieke maatskappye. Hulle verwerk baie data, byvoorbeeld om optimale roetes vir vrag- en passasiersvervoer met duisende parameters te bereken, en die status van verskepings na te spoor.
- Kleinhandel. In-Geheue-oplossings help om kliënte vinniger te bedien en groot volumes inligting te verwerk: verskepings, fakture, transaksies, die teenwoordigheid van duisende goedere in pakhuise, en berei analitiese verslae voor.
- В IOT In-Memory vervang tradisionele databasisse.
- Farmaseutiese maatskappye gebruik In-Memory, byvoorbeeld, om kombinasies van dwelmsamestellings te sorteer.
Ek sal jou 'n paar voorbeelde vertel van hoe ons kliënte In-Memory-oplossings gebruik en hoe jy dit self kan implementeer.
In-geheue as primêre berging
Een van ons kliënte is 'n groot verskaffer van mediese wetenskaplike toerusting uit die VSA. Hulle gebruik 'n In-Memory-oplossing as hul hoofdataberging. Alle data word op skyf gestoor, en die subset van data wat aktief gebruik word, word in RAM gehou. Die bergingtoegangsmetodes is standaard - GDBC (Generic Database Connector) en SQL-navraagtaal.
Gesamentlik word dit In-Memory Database (IMDB) of Memory-Centric Storage genoem. Hierdie klas oplossings het baie name, dit is nie die enigste nie.
IMDB kenmerke:
- Die data wat in In-Memory gestoor word en deur SQL verkry word, is dieselfde as in ander benaderings. Hulle is gesinchroniseer, net die manier van aanbieding, die manier om hulle aan te spreek is anders. Transaksionaliteit werk tussen data.
- IMDB is vinniger as relasionele databasisse omdat dit vinniger is om inligting van RAM af te haal as vanaf skyf.
- Interne optimaliseringsalgoritmes het minder instruksies.
- IMDB's is geskik vir die bestuur van data, gebeure en transaksies in toepassings.
IMDB's ondersteun gedeeltelik ACID: Atomisiteit, Konsekwentheid en Isolasie. Maar hulle ondersteun nie "duursaamheid" nie - wanneer die krag afgeskakel word, gaan alle data verlore. Om die probleem op te los, kan jy kiekies gebruik - 'n "kiekie" van die databasis, analoog aan 'n databasisrugsteun op 'n hardeskyf, of transaksies (logs) opneem om data te herstel na 'n herlaai.
Om foutverdraagsame toepassings te skep
Kom ons stel ons die klassieke argitektuur van 'n foutverdraagsame webtoepassing voor. Dit werk so: alle versoeke word deur 'n webbalanseerder tussen bedieners versprei. Hierdie stelsel is stabiel omdat die bedieners mekaar dupliseer en rugsteun in geval van voorvalle.
Die balanseerder rig alle versoeke van een sessie streng na een bediener. Dit is 'n stoksessiemeganisme: elke sessie word geassosieer met 'n bediener waar dit plaaslik gestoor en verwerk word.
Wat gebeur as een van die bedieners misluk?
Die diens sal nie geraak word nie, want die argitektuur is gedupliseer. Maar ons sal 'n subset van die dooie bediener se sessies verloor. En terselfdertyd die gebruikers wat aan hierdie sessies gekoppel is. Byvoorbeeld, 'n kliënt plaas 'n bestelling en gooi hom skielik uit die kantoor. Hy sal ongelukkig wees wanneer hy weer aanmeld en vind alles sal weer gedoen moet word.
'n Webtoepassing word vereis om 'n groot aantal gebruikers te ondersteun en nie stadiger te maak sodat hulle gemaklik kan werk nie. Maar as dit geweier word, sal die tyd wat dit neem om met die sessiewinkel te kommunikeer met elke daaropvolgende versoek toeneem. Dit verhoog die gemiddelde latency vir ander gebruikers. Maar hulle wil nie langer wag as waaraan hulle gewoond is nie.
Hierdie probleem kan opgelos word soos ons ander kliënt, 'n groot PASS-verskaffer van die VSA. Dit gebruik In-Memory om websessies te groepeer. Om dit te doen, stoor dit hulle nie plaaslik nie, maar sentraal - in 'n In-Geheue-kluster. In hierdie geval is sessies baie vinniger beskikbaar omdat hulle reeds in RAM is.
Wanneer 'n bediener ineenstort, stuur die balanseerder versoeke vanaf die bediener wat neergestort het na ander bedieners, soos in die klassieke argitektuur. Maar daar is 'n belangrike verskil: sessies word in 'n In-Geheue-kluster gestoor en die bedieners het toegang tot die sessies van die gevalle bediener.
Hierdie argitektuur verhoog die fouttoleransie van die hele stelsel. Boonop is dit moontlik om die stoksessiemeganisme heeltemal te laat vaar.
Hibriede Transaksionele Analitiese Verwerking (HTAP)
Tipies word transaksionele en analitiese stelsels apart gehou. Wanneer hulle skei, kom die hoofbasis onder las. Vir analitiese verwerking word data na 'n replika gekopieer sodat analitiese verwerking nie met transaksionele prosesse inmeng nie. Maar kopiëring vind plaas met 'n vertraging - dit is onmoontlik om sonder 'n vertraging te herhaal. As ons dit sinchronies doen, sal dit ook die hoofbasis vertraag en ons sal geen winste kry nie.
In HTAP werk alles anders – dieselfde datastoor word gebruik vir transaksielading vanaf toepassings, en vir analitiese navrae wat lank kan neem om te voltooi. Wanneer die data in RAM is, word analitiese navrae vinniger uitgevoer, en die bediener met die databasis is minder gelaai (gemiddeld).
’n Hibriede benadering breek die muur tussen transaksieverwerking en ontleding af. As ons ontledings op dieselfde berging uitvoer, word analitiese navrae op data vanaf RAM geloods. Hulle is baie meer akkuraat, meer interpreteerbaar en voldoende.
Integrasie van In-Memory-oplossings
'n (relatief) eenvoudige manier - ontwikkel alles van nuuts af. Ons stoor data op skyf en stoor warm data in die geheue. Dit help om bedienerherlaai of onderbrekings te oorleef.
Daar is twee hoofscenario's wat hier werk wanneer data op skyf gestoor word. In die eerste wil ons ineenstortings of gereelde herlaai van die groepie of dele oorleef - ons wil dit as 'n eenvoudige databasis gebruik. In die tweede scenario, wanneer daar te veel data is, is sommige daarvan in die geheue.
As dit nie moontlik is om alles van nuuts af te bou nie, is dit moontlik om In-Memory te integreer in 'n reeds bestaande argitektuur. Maar nie alle In-Memory-oplossings is hiervoor geskik nie. Daar is drie verpligte voorwaardes. Die In-Geheue-oplossing moet die volgende ondersteun:
- standaard manier om te koppel aan die databasis wat daaronder geleë sal wees (byvoorbeeld MySQL);
- 'n standaard navraagtaal, om nie die logika van interaksie met die berging te herskryf en te verander nie;
- transaksioneel - bewaar die semantiek van interaksie.
As aan al drie voorwaardes voldoen word, is integrasie moontlik. Ons plaas die In-Memory Data Grid tussen die toepassing en die databasis. Skryfversoeke sal nou na die onderliggende databasis gedelegeer word, en leesversoeke sal na die onderliggende databasis gedelegeer word as die data nie in die kas is nie.
As vinnige toegang tot data en die verwerking daarvan vir jou belangrik is, byvoorbeeld vir besigheidsanalise, kan jy daaraan dink om In-Memory te implementeer. En vir implementering kan jy albei metodes gebruik wanneer jy 'n nuwe argitektuur ontwerp.
Bron: will.com