In-Memory — un insieme di concetti per lo storage dei dati, quando questi vengono conservati nella memoria volatile dell'applicazione, mentre il disco viene utilizzato per il backup. Nei metodi tradizionali, i dati sono memorizzati su disco e la memoria è utilizzata come cache. Ad esempio, un'applicazione web con backend per l'elaborazione dei dati richiede questi ultimi dallo storage: li riceve, li trasforma e trasferisce molti dati sulla rete. In In-Memory, i calcoli vengono eseguiti vicino ai dati — nello storage, dove vengono elaborati e il carico sulla rete è ridotto.
Quali ulteriori opportunità offre In-Memory e che tipo di approccio è, ce lo dirà Vladimir Pligin — ingegnere dell'azienda GridGain. Questo materiale informativo sarà utile per gli sviluppatori di backend di applicazioni web che non hanno mai lavorato con In-Memory e vogliono provarlo, o sono interessati ai trend attuali nello sviluppo di soluzioni software e progettazione di architetture.
Nota. L'articolo si basa sulla trascrizione della relazione di Vladimir alla conferenza #GetIT Conf. Prima dell'introduzione dell'auto-isolamento, abbiamo regolarmente tenuto meet-up e conferenze per sviluppatori a Mosca e San Pietroburgo: abbiamo discusso tendenze, questioni rilevanti di sviluppo, problemi e soluzioni. Ora non è possibile tenere conferenze, ma è il momento perfetto per condividere materiali utili dal passato.
Chi e come utilizza In-Memory
In-Memory è più spesso utilizzato là dove è necessaria un'interazione rapida con l'utente o l'elaborazione di grandi volumi di dati.
- Banche utilizzano In-Memory, ad esempio, per ridurre i ritardi nell'uso delle applicazioni da parte dei clienti o per analizzare i clienti prima dell'erogazione di prestiti.
- Fintech usa In-Memory per migliorare le prestazioni dei servizi e delle applicazioni per banche, che delegano l'elaborazione e l'analisi dei dati a terzi.
- Compagnie assicurative: per calcolare i rischi, ad esempio analizzando i dati del cliente per diversi anni.
- Aziende logistiche. Gestiscono grandi quantità di dati, ad esempio per calcolare i percorsi ottimali per il trasporto di merci e passeggeri con migliaia di parametri, monitorando lo stato delle spedizioni.
- Retail. Le soluzioni In-Memory aiutano a servire i clienti più rapidamente e a gestire grandi volumi di informazioni: spedizioni, fatture, transazioni, disponibilità di migliaia di prodotti nei magazzini, preparare report analitici.
- In IoT In-Memory sostituisce i database tradizionali.
- Le aziende farmaceutiche utilizzano In-Memory, ad esempio, per esplorare combinazioni di formulazioni di farmaci.
Vi mostrerò alcuni esempi di come i nostri clienti utilizzano le soluzioni In-Memory e come potete implementarle nel vostro azienda.
In-Memory come principale archivio
Uno dei nostri clienti è un grande fornitore di apparecchiature scientifiche mediche negli Stati Uniti. Utilizzano una soluzione In-Memory come principale archivio dati. Tutti i dati sono memorizzati su disco, mentre un sottoinsieme di dati, che viene utilizzato attivamente, è mantenuto nella memoria RAM. I metodi di accesso all'archivio sono standard: GDBC (Generic Database Connector) e linguaggio di query SQL.
Tutto questo è chiamato In-Memory Database (IMDB) o Memory-Centric Storage. Questa classe di soluzioni ha molti nomi, non è l'unica.
Caratteristiche dell'IMDB:
- I dati memorizzati in In-Memory e accessibili tramite SQL sono gli stessi di altri approcci. Sono sincronizzati, a differenziarsi è solo il modo di presentarli e di accedervi. Tra i dati opera la transazionalità.
- L'IMDB è più veloce rispetto ai database relazionali, perché ottenere informazioni dalla memoria è più rapido che dal disco.
- Gli algoritmi interni di ottimizzazione hanno meno istruzioni.
- L'IMDB è adatto per la gestione di dati, eventi e transazioni nelle applicazioni.
L'IMDB supporta parzialmente ACID: atomicità, coerenza e isolamento. Ma non supporta la 'durabilità': quando l'alimentazione viene interrotta, tutti i dati vengono persi. Per risolvere questo problema, è possibile utilizzare snapshot — una 'foto' del database, simile a un backup del DB su disco rigido, o registrare le transazioni (log) per ripristinare i dati dopo un riavvio.
Per creare applicazioni tolleranti ai guasti
Immaginiamo un'architettura classica di un'applicazione web resiliente. Funziona in questo modo: un bilanciatore di carico distribuisce tutte le richieste tra i server. Questo sistema è resiliente, perché i server si duplicano a vicenda e si supportano in caso di incidenti.
Il bilanciatore indirizza tutte le richieste di una sessione a un unico server. Questo è il meccanismo delle sticky session: ogni sessione è legata a server, in cui è memorizzata e elaborata localmente.
Cosa succede quando uno dei server?
server fallisce? Il servizio non ne risentirà, perché l'architettura è ridondante. Tuttavia, perderemo un sottoinsieme di sessioni dal server inattivo. E anche gli utenti collegati a queste sessioni. Ad esempio, un cliente effettua un ordine e viene improvvisamente disconnesso dal proprio account. Sarà scontento quando dovrà effettuare nuovamente l'accesso e scoprire che deve rifare completamente l'ordine.
All'applicazione web è richiesto di supportare un gran numero di utenti e di non "ristagnare", affinché sia comodo lavorare. Ma in caso di fallimento, con ogni nuova richiesta, il tempo di comunicazione con il deposito delle sessioni aumenterà. Questo incrementa la latenza per gli altri utenti. Ma loro non vogliono aspettare più a lungo di quanto siano abituati.
Questo problema può essere risolto, come ha fatto un altro nostro cliente, un grande fornitore di PASS negli Stati Uniti. Utilizza l'In-Memory per clusterizzare le sessioni web. A tal fine, le memorizza non localmente, ma centralmente, in un cluster In-Memory. In questo caso, le sessioni sono disponibili molto più rapidamente, perché già risiedono nella memoria RAM.
Quando un server cade, il bilanciatore invia le richieste dell'unità guasta ad altri server, proprio come nell'architettura classica. Ma c'è una differenza importante: le sessioni sono memorizzate nel cluster In-Memory e i server possono accedere alle sessioni del server guasto.
Questa architettura aumenta la resilienza dell'intero sistema. Inoltre, è possibile rinunciare completamente al meccanismo delle sticky session.
Elaborazione ibrida transazionale-analitica (HTAP)
Di solito, i sistemi transazionali e analitici sono tenuti separati. Quando sono separati, il carico ricade sulla base dati principale. Per l'elaborazione analitica, i dati vengono copiati in una replica in modo che l'analisi non interferisca con i processi transazionali. Ma la copia avviene con un certo ritardo: senza ritardo, la replicazione non è possibile. Se facciamo tutto in modo sincrono, questo rallenterà anche la base principale e non otterremo alcun beneficio.
In HTAP, tutto funziona diversamente: lo stesso archivio dati viene utilizzato per il carico transazionale delle applicazioni e per le query analitiche, che possono richiedere molto tempo per essere completate. Quando i dati sono in memoria operativa, le query analitiche vengono eseguite più rapidamente e il server del database è meno caricato (in media).
L'approccio ibrido «rompe il muro» tra l'elaborazione delle transazioni e l'analisi. Se eseguiamo analisi sullo stesso archivio, le query analitiche vengono attivate sui dati della memoria operativa. Sono molto più precise, più interpretabili e adeguate.
Integrazione delle soluzioni In-Memory
Un modo (relativamente) semplice è sviluppare tutto da zero.. Manteniamo i dati su disco, mentre quelli attivi sono memorizzati in memoria. Questo aiuta a superare i riavvii dei server o le interruzioni.
Qui vengono attivati due scenari principali, quando i dati sono memorizzati su disco. Nel primo, vogliamo affrontare i guasti o i riavvii programmati del cluster o delle sue parti: vogliamo utilizzarli come un semplice database. Nel secondo scenario, quando i dati sono troppi, una parte di essi si trova in memoria.
Se non è possibile costruire tutto da zero, è possibile integrare In-Memory in un architettura esistente.. Ma non tutte le soluzioni In-Memory sono adatte a questo scopo. Ci sono tre requisiti fondamentali. La soluzione In-Memory deve supportare:
- un modo standard di connettersi al database sottostante (ad esempio, MySQL);
- un linguaggio di query standard, per non dover riscrivere e modificare la logica di interazione con l'archivio;
- la transazionalità: mantenere la semantica dell'interazione.
Se tutti e tre i requisiti sono soddisfatti, l'integrazione è possibile. Posizioniamo l'In-Memory Data Grid tra l'applicazione e il database. Ora le richieste di scrittura saranno delegate al database sottostante, mentre le richieste di lettura andranno al database, se i dati non sono già presenti nella cache.
Se hai bisogno di un accesso rapido ai dati e della loro elaborazione, ad esempio per l'analisi aziendale, potresti considerare l'implementazione dell'In-Memory. Per la realizzazione, puoi utilizzare entrambi i metodi durante la progettazione di una nuova architettura.
Fonte: habr.com
