In-Memory és un conjunt de conceptes per emmagatzemar dades quan s'emmagatzemen a la memòria RAM de l'aplicació i el disc s'utilitza per a la còpia de seguretat. En els enfocaments clàssics, les dades s'emmagatzemen al disc i la memòria s'emmagatzema a la memòria cau. Per exemple, una aplicació web amb un backend per processar dades les sol·licita a l'emmagatzematge: la rep, la transforma i es transfereixen moltes dades per la xarxa. A In-Memory, els càlculs s'envien a les dades, a l'emmagatzematge, on es processen i la xarxa està menys carregada.
Quines altres possibilitats hi ha disponibles amb In-Memory i quin tipus d'enfocament és aquest? Vladimir Pligin - Enginyer a GridGain. Aquest material de revisió serà útil per als desenvolupadors de backend d'aplicacions web que no hagin treballat amb In-Memory i vulguin provar-ho o estiguin interessats en les tendències modernes en desenvolupament de programari i disseny d'arquitectura.
Nota. L'article es basa en la transcripció de l'informe de Vladimir a la #GetIT Conf. Abans de la introducció de l'autoaïllament, teníem regularment reunions i conferències per a desenvolupadors a Moscou i Sant Petersburg: vam parlar de tendències, problemes actuals de desenvolupament, problemes i les seves solucions. No és possible fer una conferència ara, però és hora de compartir materials útils de les anteriors.
Qui utilitza In-Memory i com
In-Memory s'utilitza amb més freqüència quan es requereix una interacció ràpida de l'usuari o el processament de grans quantitats de dades.
- Bancs utilitzar In-Memory, per exemple, per reduir els retards quan els clients utilitzen aplicacions o per analitzar el client abans d'emetre un préstec.
- Fintech utilitza In-Memory per millorar el rendiment dels serveis i aplicacions dels bancs que externalitzen el processament i l'anàlisi de dades.
- Companyies d'assegurances: per calcular els riscos, per exemple, analitzant les dades dels clients durant diversos anys.
- Empreses de logística. Tracten moltes dades, per exemple, per calcular rutes òptimes per al transport de mercaderies i passatgers amb milers de paràmetres i fer un seguiment de l'estat dels enviaments.
- Venda al detall. Les solucions In-Memory ajuden a atendre els clients més ràpidament i processar grans volums d'informació: enviaments, factures, transaccions, presència de milers de mercaderies als magatzems i elaborar informes analítics.
- В IO In-Memory substitueix les bases de dades tradicionals.
- Farmacèutica Les empreses utilitzen In-Memory, per exemple, per ordenar combinacions de composicions de fàrmacs.
Us explicaré alguns exemples de com els nostres clients utilitzen les solucions In-Memory i com podeu implementar-les vosaltres mateixos.
A la memòria com a emmagatzematge principal
Un dels nostres clients és un gran proveïdor d'equips científics mèdics dels EUA. Utilitzen una solució In-Memory com a principal emmagatzematge de dades. Totes les dades s'emmagatzemen al disc i el subconjunt de dades que s'utilitza activament es manté a la memòria RAM. Els mètodes d'accés a l'emmagatzematge són estàndard: GDBC (Connector de base de dades genèric) i llenguatge de consulta SQL.
En conjunt, això s'anomena base de dades a la memòria (IMDB) o emmagatzematge centrat en la memòria. Aquesta classe de solucions té molts noms, aquests no són els únics.
Característiques IMDB:
- Les dades que s'emmagatzemen a In-Memory i s'hi accedeix mitjançant SQL són les mateixes que en altres enfocaments. Estan sincronitzats, només la forma de presentació, la manera d'abordar-los és diferent. La transaccionalitat funciona entre dades.
- IMDB és més ràpid que les bases de dades relacionals perquè és més ràpid recuperar informació de la memòria RAM que del disc.
- Els algorismes d'optimització interns tenen menys instruccions.
- Els IMDB són adequats per gestionar dades, esdeveniments i transaccions en aplicacions.
Els IMDB admeten parcialment ACID: atomicitat, consistència i aïllament. Però no admeten la "durabilitat": quan s'apaga l'alimentació, es perden totes les dades. Per resoldre el problema, podeu utilitzar instantànies: una "instantània" de la base de dades, anàloga a una còpia de seguretat de la base de dades en un disc dur, o registrar transaccions (registres) per restaurar les dades després d'un reinici.
Per crear aplicacions tolerants a errors
Imaginem l'arquitectura clàssica d'una aplicació web tolerant a errors. Funciona així: totes les sol·licituds es distribueixen per un equilibrador web entre servidors. Aquest sistema és estable perquè els servidors es dupliquen entre si i fan una còpia de seguretat en cas d'incidències.
L'equilibrador dirigeix totes les sol·licituds d'una sessió estrictament a un servidor. Aquest és un mecanisme de sessió stick: cada sessió s'associa a un servidor on s'emmagatzema i es processa localment.
Què passa quan un dels servidors falla?
El servei no es veurà afectat perquè l'arquitectura està duplicada. Però perdrem un subconjunt de sessions del servidor mort. I al mateix temps, els usuaris que estan lligats a aquestes sessions. Per exemple, un client fa una comanda i de sobte el llença de l'oficina. Serà infeliç quan torni a iniciar sessió i trobi que tot s'haurà de fer de nou.
Es requereix una aplicació web per donar suport a un gran nombre d'usuaris i no frenar perquè puguin treballar còmodament. Però si es rebutja, amb cada sol·licitud posterior augmentarà el temps que triga a comunicar-se amb la botiga de sessions. Això augmenta la latència mitjana per a altres usuaris. Però no volen esperar més del que estan acostumats.
Aquest problema es pot resoldre com el nostre altre client, un gran proveïdor de PASS dels EUA. Utilitza In-Memory per agrupar sessions web. Per fer-ho, no els emmagatzema localment, sinó centralment, en un clúster a la memòria. En aquest cas, les sessions estan disponibles molt més ràpid perquè ja estan a la memòria RAM.
Quan un servidor falla, l'equilibrador envia peticions des del servidor bloquejat a altres servidors, com en l'arquitectura clàssica. Però hi ha una diferència important: les sessions s'emmagatzemen en un clúster a la memòria i els servidors tenen accés a les sessions del servidor caigut.
Aquesta arquitectura augmenta la tolerància a fallades de tot el sistema. A més, és possible abandonar completament el mecanisme de sessió de stick.
Processament analític transaccional híbrid (HTAP)
Normalment, els sistemes transaccionals i analítics es mantenen separats. Quan es separen, la base principal queda sota càrrega. Per al processament analític, les dades es copien a una rèplica perquè el processament analític no interfereixi amb els processos transaccionals. Però la còpia es produeix amb un retard; és impossible replicar sense retard. Si ho fem de manera sincrònica, també alentirà la base principal i no obtindrem cap guany.
A HTAP, tot funciona de manera diferent: el mateix magatzem de dades s'utilitza per a la càrrega transaccional de les aplicacions i per a consultes analítiques que poden trigar molt a completar-se. Quan les dades es troben a la memòria RAM, les consultes analítiques s'executen més ràpidament i el servidor amb la base de dades està menys carregat (de mitjana).
Un enfocament híbrid trenca el mur entre el processament de transaccions i l'anàlisi. Si realitzem analítiques al mateix emmagatzematge, aleshores s'inicien consultes analítiques a les dades de la memòria RAM. Són molt més exactes, més interpretables i adequades.
Integració de solucions In-Memory
Una manera (relativament) senzilla - desenvolupar-ho tot des de zero. Guardem les dades al disc i emmagatzemem les dades calentes a la memòria. Això ajuda a sobreviure als reinicis o interrupcions del servidor.
Hi ha dos escenaris principals que funcionen aquí quan les dades s'emmagatzemen al disc. En el primer, volem sobreviure als bloquejos o als reinicis regulars del clúster o de les parts; volem utilitzar-lo com a base de dades simple. En el segon escenari, quan hi ha massa dades, algunes es troben a la memòria.
Si no és possible construir-ho tot des de zero, és possible integrar In-Memory en un arquitectura existent. Però no totes les solucions In-Memory són adequades per a això. Hi ha tres condicions obligatòries. La solució In-Memory ha de suportar:
- manera estàndard de connectar-se a la base de dades que s'ubicarà a sota (per exemple, MySQL);
- un llenguatge de consulta estàndard, per no reescriure i canviar la lògica d'interacció amb l'emmagatzematge;
- transaccional: preservar la semàntica de la interacció.
Si es compleixen les tres condicions, la integració és possible. Col·loquem la graella de dades a la memòria entre l'aplicació i la base de dades. Ara les sol·licituds d'escriptura es delegaran a la base de dades subjacent i les sol·licituds de lectura es delegaran a la base de dades subjacent si les dades no es troben a la memòria cau.
Si l'accés ràpid a les dades i el seu processament és important per a vostè, per exemple, per a l'anàlisi empresarial, podeu pensar en implementar In-Memory. I per a la implementació, podeu utilitzar els dos mètodes quan dissenyeu una nova arquitectura.
Font: www.habr.com