In-Memory is een reeks concepten voor het opslaan van gegevens wanneer deze zijn opgeslagen in het RAM van de toepassing en de schijf wordt gebruikt voor back-up. Bij klassieke benaderingen worden gegevens op schijf opgeslagen en wordt geheugen in cache opgeslagen. Een webapplicatie met een backend voor het verwerken van gegevens vraagt deze bijvoorbeeld op voor opslag: zij ontvangt deze, transformeert deze en er worden veel gegevens over het netwerk overgedragen. In In-Memory worden berekeningen naar de data gestuurd – naar opslag, waar ze worden verwerkt en het netwerk minder belast wordt.
Welke andere mogelijkheden zijn er met In-Memory en wat voor aanpak is dit? Vladimir Pligin - ingenieur bij GridGain. Dit beoordelingsmateriaal is nuttig voor backend-ontwikkelaars van webapplicaties die nog niet met In-Memory hebben gewerkt en het willen proberen, of geïnteresseerd zijn in moderne trends in softwareontwikkeling en architectuurontwerp.
Noot. Het artikel is gebaseerd op de transcriptie van Vladimirs rapport op de #GetIT Conf. Vóór de introductie van zelfisolatie hielden we regelmatig bijeenkomsten en conferenties voor ontwikkelaars in Moskou en Sint-Petersburg: we bespraken trends, actuele ontwikkelingsvraagstukken, problemen en hun oplossingen. Het is nu niet mogelijk om een conferentie te houden, maar het is tijd om nuttig materiaal van eerdere conferenties te delen.
Wie gebruikt In-Memory en hoe
In-Memory wordt meestal gebruikt waar snelle gebruikersinteractie of verwerking van grote hoeveelheden gegevens vereist is.
- Banken gebruik In-Memory bijvoorbeeld om vertragingen te verminderen bij het gebruik van applicaties door klanten of om de klant te analyseren voordat hij een lening verstrekt.
- Fintech gebruikt In-Memory om de prestaties van diensten en applicaties te verbeteren voor banken die gegevensverwerking en -analyse uitbesteden.
- Verzekeringsmaatschappijen: risico's berekenen, bijvoorbeeld door klantgegevens over meerdere jaren te analyseren.
- Logistieke bedrijven. Ze verwerken veel gegevens om bijvoorbeeld met duizenden parameters optimale routes voor vracht- en personenvervoer te berekenen en de status van zendingen te volgen.
- Detailhandel. In-Memory-oplossingen helpen klanten sneller te bedienen en grote hoeveelheden informatie te verwerken: zendingen, facturen, transacties, de aanwezigheid van duizenden goederen in magazijnen, en analytische rapporten op te stellen.
- В IoT In-Memory vervangt traditionele databases.
- Farmaceutisch Bedrijven gebruiken In-Memory bijvoorbeeld om combinaties van medicijnsamenstellingen te doorzoeken.
Ik vertel je een paar voorbeelden van hoe onze klanten In-Memory oplossingen gebruiken en hoe je deze zelf kunt implementeren.
In-Memory als primaire opslag
Eén van onze opdrachtgevers is een grote leverancier van medisch-wetenschappelijke apparatuur uit de USA. Ze gebruiken een In-Memory-oplossing als hun belangrijkste gegevensopslag. Alle gegevens worden op schijf opgeslagen en de subset van gegevens die actief wordt gebruikt, wordt in het RAM bewaard. De methoden voor opslagtoegang zijn standaard: GDBC (Generic Database Connector) en SQL-querytaal.
Gezamenlijk wordt dit In-Memory Database (IMDB) of Memory-Centric Storage genoemd. Deze klasse van oplossingen heeft veel namen, dit zijn niet de enige.
IMDB-functies:
- De gegevens die zijn opgeslagen in In-Memory en toegankelijk zijn via SQL zijn dezelfde als bij andere benaderingen. Ze zijn gesynchroniseerd, alleen de manier van presenteren, de manier van aanspreken is anders. Transactionaliteit werkt tussen data.
- IMDB is sneller dan relationele databases omdat het sneller is om informatie uit het RAM op te halen dan van schijf.
- Interne optimalisatiealgoritmen hebben minder instructies.
- IMDB's zijn geschikt voor het beheren van gegevens, gebeurtenissen en transacties in applicaties.
IMDB's ondersteunen gedeeltelijk ACID: Atomicity, Consistentie en Isolatie. Maar ze ondersteunen geen "duurzaamheid" - wanneer de stroom wordt uitgeschakeld, gaan alle gegevens verloren. Om het probleem op te lossen, kunt u snapshots gebruiken - een "momentopname" van de database, analoog aan een databaseback-up op een harde schijf, of transacties (logboeken) vastleggen om gegevens te herstellen na een herstart.
Om fouttolerante applicaties te creëren
Laten we ons de klassieke architectuur van een fouttolerante webapplicatie voorstellen. Het werkt als volgt: alle verzoeken worden door een webbalancer tussen servers verdeeld. Dit systeem is stabiel omdat de servers elkaar dupliceren en een back-up maken in geval van incidenten.
De balancer stuurt alle verzoeken van één sessie strikt naar één server. Dit is een sticksessiemechanisme: elke sessie is gekoppeld aan een server waar deze lokaal wordt opgeslagen en verwerkt.
Wat gebeurt er als een van de servers uitvalt?
De service wordt niet beïnvloed omdat de architectuur wordt gedupliceerd. Maar we zullen een subset van de sessies van de dode server verliezen. En tegelijkertijd de gebruikers die aan deze sessies gebonden zijn. Een klant plaatst bijvoorbeeld een bestelling en gooit hem plotseling het kantoor uit. Hij zal ongelukkig zijn als hij weer inlogt en merkt dat alles opnieuw moet.
Een webapplicatie is nodig om een groot aantal gebruikers te ondersteunen en niet te vertragen zodat zij comfortabel kunnen werken. Maar als het wordt geweigerd, zal bij elk volgend verzoek de tijd die nodig is om met het sessiearchief te communiceren toenemen. Dit verhoogt de gemiddelde latentie voor andere gebruikers. Maar ze willen niet langer wachten dan ze gewend zijn.
Dit probleem kan net als onze andere klant, een grote PASS-aanbieder uit de VS, worden opgelost. Het maakt gebruik van In-Memory om websessies te clusteren. Om dit te doen, worden ze niet lokaal, maar centraal opgeslagen in een In-Memory-cluster. In dit geval zijn sessies veel sneller beschikbaar omdat ze zich al in het RAM-geheugen bevinden.
Wanneer een server crasht, stuurt de balancer verzoeken van de gecrashte server naar andere servers, zoals in de klassieke architectuur. Maar er is een belangrijk verschil: sessies worden opgeslagen in een In-Memory-cluster en de servers hebben toegang tot de sessies van de gevallen server.
Deze architectuur verhoogt de fouttolerantie van het hele systeem. Bovendien is het mogelijk om het sticksessiemechanisme helemaal achterwege te laten.
Hybride transactionele analytische verwerking (HTAP)
Doorgaans worden transactionele en analytische systemen gescheiden gehouden. Wanneer ze uit elkaar gaan, wordt de hoofdbasis belast. Voor analytische verwerking worden gegevens naar een replica gekopieerd, zodat analytische verwerking de transactionele processen niet verstoort. Maar kopiëren gebeurt met een vertraging; het is onmogelijk om zonder vertraging te repliceren. Als we dit synchroon doen, vertraagt het ook de hoofdbasis en behalen we geen winst.
In HTAP werkt alles anders: dezelfde gegevensopslag wordt gebruikt voor het transactioneel laden van applicaties en voor analytische queries die veel tijd in beslag kunnen nemen. Wanneer de data in het RAM staan, worden analytische queries sneller uitgevoerd en wordt de server met de database (gemiddeld) minder belast.
Een hybride aanpak doorbreekt de muur tussen transactieverwerking en analyse. Als we analyses uitvoeren op dezelfde opslag, worden analytische zoekopdrachten gestart op gegevens uit RAM. Ze zijn veel nauwkeuriger, beter interpreteerbaar en adequater.
Integratie van In-Memory-oplossingen
Een (relatief) eenvoudige manier - alles vanaf nul ontwikkelen. We bewaren gegevens op schijf en slaan actuele gegevens op in het geheugen. Dit helpt bij het overleven van serverherstarts of -uitval.
Er zijn hier twee hoofdscenario's aan het werk wanneer gegevens op schijf worden opgeslagen. In het eerste geval willen we crashes of regelmatige herstarts van het cluster of onderdelen ervan overleven - we willen het gebruiken als een eenvoudige database. In het tweede scenario, wanneer er te veel gegevens zijn, bevindt een deel ervan zich in het geheugen.
Als het niet mogelijk is om alles vanaf nul op te bouwen, is het mogelijk om In-Memory te integreren in een bestaand bestand bestaande architectuur. Maar niet alle In-Memory oplossingen zijn hiervoor geschikt. Er zijn drie verplichte voorwaarden. De In-Memory-oplossing moet het volgende ondersteunen:
- standaardmanier om verbinding te maken met de database die zich eronder bevindt (bijvoorbeeld MySQL);
- een standaard zoektaal, om de logica van interactie met de opslag niet te herschrijven en te veranderen;
- transactioneel - behoud de semantiek van interactie.
Als aan alle drie de voorwaarden is voldaan, is integratie mogelijk. We plaatsen het In-Memory Data Grid tussen de applicatie en de database. Schrijfverzoeken worden nu gedelegeerd aan de onderliggende database, en leesverzoeken worden gedelegeerd aan de onderliggende database als de gegevens zich niet in de cache bevinden.
Als snelle toegang tot gegevens en de verwerking ervan voor u belangrijk is, bijvoorbeeld voor bedrijfsanalyses, kunt u nadenken over de implementatie van In-Memory. En voor de implementatie kun je beide methoden gebruiken bij het ontwerpen van een nieuwe architectuur.
Bron: www.habr.com