In-Memory — un insieme di concetti di archiviazione dei dati in cui vengono mantenuti nella memoria volatile dell'applicazione, mentre il disco viene utilizzato per il backup. Nei metodi tradizionali, i dati vengono memorizzati su disco e la memoria funge da cache. Ad esempio, un'applicazione web con un backend per l'elaborazione dei dati richiede di ottenere, trasformare e trasferire grandi quantità di dati attraverso la rete. Con l'In-Memory, i calcoli vengono eseguiti direttamente sui dati — nel sistema di archiviazione, dove vengono elaborati, riducendo così il carico sulla rete.
Quali altre opportunità offre l'In-Memory e di cosa si tratta, sarà spiegato Vladimir Pligin — ingegnere di GridGain. Questo materiale introduttivo sarà utile per gli sviluppatori del backend di applicazioni web che non hanno mai lavorato con l'In-Memory e vogliono provare, o che sono interessati alle attuali tendenze nello sviluppo di soluzioni software e nella progettazione architettonica.
Nota. L'articolo si basa sulla trascrizione della presentazione di Vladimir alla conferenza #GetIT Conf. Prima dell'introduzione dell'auto-isolamento, organizzavamo regolarmente meet-up e conferenze per sviluppatori a Mosca e San Pietroburgo: discutevamo delle tendenze, delle questioni attuali dello sviluppo, dei problemi e delle loro soluzioni. Ora non possiamo tenere conferenze, ma è il momento migliore per condividere materiali utili dal passato.
Chi e come utilizza l'In-Memory
L'In-Memory è utilizzato più frequentemente dove è necessaria una rapida interazione con l'utente o l'elaborazione di grandi volumi di dati.
- Le banche utilizzano l'In-Memory, ad esempio, per ridurre i ritardi durante l'uso delle applicazioni da parte dei clienti o per analizzare il cliente prima di concedere un prestito.
- Il fintech utilizza l'In-Memory per migliorare le prestazioni dei servizi e delle applicazioni bancarie che esternalizzano l'elaborazione e l'analisi dei dati.
- Le compagnie assicurative: per calcolare i rischi, ad esempio, analizzando i dati del cliente negli ultimi anni.
- Le compagnie di logistica. Elaborano grandi quantità di dati, ad esempio, per calcolare i percorsi ottimali per il trasporto di merci e passeggeri, considerando migliaia di parametri e monitorando lo stato delle spedizioni.
- Il retail. Le soluzioni In-Memory aiutano a servire i clienti più velocemente e a gestire grandi volumi di informazioni: spedizioni, fatture, transazioni, disponibilità di migliaia di prodotti in magazzino, e a creare report analitici.
- In IoT L'In-Memory sostituisce i tradizionali database.
- Le aziende farmaceutiche utilizzano l'In-Memory, ad esempio, per esaminare combinazioni di ingredienti per farmaci.
Racconterò alcuni esempi di come i nostri clienti utilizzano le soluzioni In-Memory e come possono implementarle nella loro attività.
In-Memory come archiviazione principale
Uno dei nostri clienti è un grande fornitore di attrezzature scientifiche mediche negli Stati Uniti. Utilizzano una soluzione In-Memory come archiviazione principale dei dati. Tutti i dati vengono memorizzati su disco, mentre un sottoinsieme di dati utilizzati attivamente è conservato nella memoria. I metodi di accesso all'archiviazione sono standard — GDBC (Generic Database Connector) e linguaggio di query SQL.
Tutto questo si chiama In-Memory Database (IMDB) o Memory-Centric Storage. Questa classe di soluzioni ha molti nomi, non è l'unico.
Caratteristiche dell'IMDB:
- I dati archiviati nell'In-Memory e accessibili tramite SQL sono gli stessi di altri approcci. Sono sincronizzati, differendo solo nel modo di presentarli e nel metodo di accesso. Tra i dati è presente la transazionalità.
- L'IMDB è più veloce dei database relazionali, perché è più rapido accedere alle informazioni dalla memoria volatile rispetto 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. Tuttavia, non supporta la "durabilità" — con l'interruzione dell'alimentazione si perdono tutti i dati. Per risolvere il problema, è possibile utilizzare snapshot — una "fotografia" del database, simile a un backup su disco rigido, o registrare le transazioni (log) per recuperare i dati dopo il riavvio.
Per creare applicazioni a prova di guasto
Immaginiamo l'architettura classica di un'applicazione web resiliente. Funziona così: un bilanciatore di carico distribuisce tutte le richieste tra i server. Questo sistema è resistente, perché i server si duplicano e si supportano a vicenda in caso di incidenti.
Il bilanciatore dirige tutte le richieste da una sessione a un singolo server. Questo è il meccanismo delle sticky session: ogni sessione è legata a server, dove è memorizzata e trattata localmente.
Cosa succede quando uno dei server?
server si guasta? Il servizio non subisce danni, perché l'architettura è ridondante. Ma perderemo un sottoinsieme delle sessioni del server guasto. E anche gli utenti legati a queste sessioni. Ad esempio, un cliente effettua un ordine e improvvisamente viene disconnesso dal proprio account. Sarà scontento quando, una volta ri-autenticato, scoprirà che deve ripetere l'intero ordine.
L'applicazione web deve gestire un gran numero di utenti senza "tremare" per rendere l'esperienza confortevole. Ma, in caso di guasto, con ogni successiva richiesta il tempo di comunicazione con il repository delle sessioni aumenterà. Questo aumenta la latenza media per gli altri utenti. Ma 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 In-Memory per clusterizzare le sessioni web. In questo modo le memorizza non localmente, ma centralmente, in un cluster In-Memory. In questo caso, le sessioni sono accessibili molto più rapidamente, poiché già si trovano in memoria.
Quando un server si guasta, il bilanciatore inoltra le richieste perse ad altri server, come nell'architettura classica. Ma c'è una differenza importante: le sessioni sono memorizzate nel cluster In-Memory e i server hanno accesso 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 mantenuti separati. Quando vengono separati, il database principale è sottoposto a carico. Per l'elaborazione analitica, i dati sono copiati in una replica, in modo che l'elaborazione analitica non interferisca con i processi transazionali. Ma la copia avviene con un ritardo: è impossibile replicare senza ritardo. Se facciamo questo in modo sincrono, ciò rallenta anche il database principale senza ottenere vantaggi.
Nell'HTAP tutto funziona diversamente: lo stesso repository di dati è utilizzato per il carico transazionale delle applicazioni e per le richieste analitiche, che possono richiedere tempo. Quando i dati risiedono in memoria, le richieste analitiche vengono eseguite più rapidamente, e il server del database è caricato di meno (in media).
L'approccio ibrido "rompe il muro" tra l'elaborazione delle transazioni e l'analitica. Se eseguiamo l'analisi sullo stesso repository, le richieste analitiche vengono eseguite sui dati che risiedono in memoria. Sono molto più precise, più interpretabili e adeguate.
Integrazione delle soluzioni In-Memory
Un modo relativamente semplice è sviluppare tutto da zero. Conserviamo i dati su disco, mentre quelli caldi li teniamo in memoria. Questo aiuta a sopportare i riavvii dei server o le disconnessioni.
Qui ci sono due scenari principali, quando i dati sono archiviati su disco. Nel primo vogliamo resistere a guasti o riavvii pianificati del cluster o di parti di esso — vogliamo utilizzarlo come un semplice database. Nel secondo scenario, quando ci sono troppi dati, una parte di essi verrà tenuta in memoria.
Se non è possibile costruire tutto da zero, è possibile integrare In-Memory in un'architettura già 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 che sarà sottostante (ad esempio, MySQL);
- un linguaggio di query standard, per non dover riscrivere e modificare la logica di interazione con il repository;
- la transazionalità — mantenere la semantica dell'interazione.
Se tutte e tre le condizioni sono soddisfatte, l'integrazione è possibile. Posizioniamo un 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 verranno inoltrate al database se i dati non sono presenti nella cache.
Se è importante per te avere accesso rapido ai dati e elaborali, ad esempio, per l'analisi aziendale — potresti considerare l'implementazione di In-Memory. E per la realizzazione, puoi utilizzare entrambi i metodi durante la progettazione di una nuova architettura.
Fonte: habr.com
