In-Memory è un insieme di concetti per l'archiviazione dei dati quando sono archiviati nella RAM dell'applicazione e il disco viene utilizzato per il backup. Negli approcci classici, i dati vengono archiviati su disco e la memoria viene archiviata nella cache. Ad esempio, un'applicazione web con un backend per l'elaborazione dei dati li richiede nello storage: li riceve, li trasforma e molti dati vengono trasferiti in rete. In In-Memory, i calcoli vengono inviati ai dati, allo spazio di archiviazione, dove vengono elaborati e la rete è meno caricata.
Quali altre possibilità sono disponibili con In-Memory e che tipo di approccio è questo? Vladimir Ppligin - ingegnere presso GridGain. Questo materiale di revisione sarà utile agli sviluppatori di backend di applicazioni Web che non hanno lavorato con In-Memory e desiderano provare o sono interessati alle tendenze moderne nello sviluppo di software e nella progettazione dell'architettura.
Nota. L’articolo si basa sulla trascrizione del rapporto di Vladimir alla #GetIT Conf. Prima dell’introduzione dell’autoisolamento, tenevamo regolarmente incontri e conferenze per sviluppatori a Mosca e San Pietroburgo: discutevamo di tendenze, attuali questioni di sviluppo, problemi e relative soluzioni. Non è possibile tenere una conferenza adesso, ma è tempo di condividere materiali utili di quelle passate.
Chi utilizza In-Memory e come
In-Memory viene spesso utilizzato laddove è richiesta un'interazione rapida dell'utente o l'elaborazione di grandi quantità di dati.
- Banche utilizzare In-Memory, ad esempio, per ridurre i ritardi quando i clienti utilizzano le applicazioni o per analizzare il cliente prima di concedere un prestito.
- Fintech utilizza In-Memory per migliorare le prestazioni di servizi e applicazioni per le banche che esternalizzano l'elaborazione e l'analisi dei dati.
- Compagnie di assicurazione: per calcolare i rischi, ad esempio, analizzando i dati dei clienti su diversi anni.
- Aziende di logistica. Elaborano molti dati, ad esempio, per calcolare percorsi ottimali per il trasporto di merci e passeggeri con migliaia di parametri e tenere traccia dello stato delle spedizioni.
- Vedere al dettaglio. Le soluzioni In-Memory aiutano a servire i clienti più velocemente ed elaborare grandi volumi di informazioni: spedizioni, fatture, transazioni, presenza di migliaia di merci nei magazzini e preparare report analitici.
- В IoT In-Memory sostituisce i database tradizionali.
- farmaceutico le aziende utilizzano In-Memory, ad esempio, per ordinare combinazioni di composizioni di farmaci.
Ti dirò alcuni esempi di come i nostri clienti utilizzano le soluzioni In-Memory e di come puoi implementarle tu stesso.
In memoria come memoria principale
Uno dei nostri clienti è un grande fornitore di apparecchiature medico-scientifiche dagli Stati Uniti. Utilizzano una soluzione in-memory come archivio dati principale. Tutti i dati vengono archiviati su disco e il sottoinsieme di dati utilizzato attivamente viene conservato nella RAM. I metodi di accesso allo storage sono standard: GDBC (Generic Database Connector) e linguaggio di query SQL.
Collettivamente questo è chiamato In-Memory Database (IMDB) o Memory-Centric Storage. Questa classe di soluzioni ha molti nomi, questi non sono gli unici.
Caratteristiche IMDB:
- I dati archiviati in In-Memory e a cui si accede tramite SQL sono gli stessi di altri approcci. Sono sincronizzati, solo il modo di presentarli, il modo di affrontarli è diverso. La transazionalità funziona tra i dati.
- IMDB è più veloce dei database relazionali perché è più veloce nel recuperare le informazioni dalla RAM che dal disco.
- Gli algoritmi di ottimizzazione interna hanno meno istruzioni.
- Gli IMDB sono adatti per la gestione di dati, eventi e transazioni nelle applicazioni.
Gli IMDB supportano parzialmente ACID: Atomicità, Coerenza e Isolamento. Ma non supportano la "durabilità": quando si spegne l'alimentazione, tutti i dati vanno persi. Per risolvere il problema, è possibile utilizzare le istantanee: una "istantanea" del database, analoga al backup del database su un disco rigido, oppure registrare le transazioni (registri) per ripristinare i dati dopo un riavvio.
Per creare applicazioni tolleranti agli errori
Immaginiamo l'architettura classica di un'applicazione web tollerante ai guasti. Funziona così: tutte le richieste vengono distribuite da un bilanciatore web tra i server. Questo sistema è stabile perché i server si duplicano a vicenda e eseguono il backup in caso di incidenti.
Il bilanciatore indirizza tutte le richieste da una sessione rigorosamente a un server. Questo è un meccanismo di stick session: ogni sessione è associata a un server dove viene archiviata ed elaborata localmente.
Cosa succede quando uno dei server fallisce?
Il servizio non verrà influenzato perché l'architettura è duplicata. Ma perderemo un sottoinsieme delle sessioni del server morto. E allo stesso tempo gli utenti legati a queste sessioni. Ad esempio, un cliente effettua un ordine e improvvisamente lo butta fuori dall'ufficio. Sarà infelice quando accederà di nuovo e scoprirà che tutto dovrà essere rifatto.
È necessaria un'applicazione Web per supportare un gran numero di utenti e non rallentare in modo che possano lavorare comodamente. Ma se viene rifiutato, ad ogni richiesta successiva aumenterà il tempo necessario per comunicare con il session store. Ciò aumenta la latenza media per gli altri utenti. Ma non vogliono aspettare più del solito.
Questo problema può essere risolto come l'altro nostro cliente, un grande fornitore di PASS dagli Stati Uniti. Utilizza In-Memory per raggruppare le sessioni Web. Per fare ciò, non li memorizza localmente, ma centralmente, in un cluster In-Memory. In questo caso le sessioni sono disponibili molto più velocemente perché sono già nella RAM.
Quando un server va in crash, il bilanciatore invia richieste dal server in crash ad altri server, come nell'architettura classica. Ma c’è una differenza importante: le sessioni vengono archiviate in un cluster in memoria e i server hanno accesso alle sessioni del server caduto.
Questa architettura aumenta la tolleranza agli errori dell'intero sistema. Inoltre, è possibile abbandonare del tutto il meccanismo della stick session.
Elaborazione analitica transazionale ibrida (HTAP)
In genere, i sistemi transazionali e analitici sono mantenuti separati. Quando si separano, la base principale viene caricata. Per l'elaborazione analitica, i dati vengono copiati in una replica in modo che l'elaborazione analitica non interferisca con i processi transazionali. Ma la copia avviene con un ritardo: è impossibile replicarsi senza un ritardo. Se lo facciamo in modo sincrono, rallenteremo anche la base principale e non otterremo alcuna vincita.
In HTAP tutto funziona in modo diverso: 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 si trovano nella RAM, le query analitiche vengono eseguite più velocemente e il server con il database viene caricato meno (in media).
Un approccio ibrido abbatte il muro tra l’elaborazione delle transazioni e l’analisi. Se eseguiamo analisi sullo stesso spazio di archiviazione, le query analitiche vengono avviate sui dati dalla RAM. Sono molto più accurati, più interpretabili e adeguati.
Integrazione di soluzioni In-Memory
Un modo (relativamente) semplice - sviluppare tutto da zero. Conserviamo i dati su disco e archiviamo i dati importanti in memoria. Ciò aiuta a sopravvivere ai riavvii o alle interruzioni del server.
Ci sono due scenari principali all'opera qui quando i dati vengono archiviati su disco. Nel primo, vogliamo sopravvivere agli arresti anomali o ai riavvii regolari del cluster o di parti: vogliamo usarlo come un semplice database. Nel secondo scenario, quando ci sono troppi dati, alcuni di essi sono in memoria.
Se non è possibile costruire tutto da zero, è possibile integrare In-Memory in uno già esistente architettura esistente. Ma non tutte le soluzioni In-Memory sono adatte a questo. Ci sono tre condizioni obbligatorie. La soluzione in memoria deve supportare:
- modo standard per connettersi al database che si troverà sotto di esso (ad esempio, MySQL);
- un linguaggio di interrogazione standard, per non riscrivere e cambiare la logica di interazione con lo storage;
- transazionale: preserva la semantica dell'interazione.
Se tutte e tre le condizioni sono soddisfatte l’integrazione è possibile. Inseriamo la griglia dei dati in memoria tra l'applicazione e il database. Ora le richieste di scrittura verranno delegate al database sottostante e le richieste di lettura verranno delegate al database sottostante se i dati non sono nella cache.
Se per te è importante un accesso rapido ai dati e alla loro elaborazione, ad esempio per l'analisi aziendale, puoi pensare all'implementazione di In-Memory. E per l'implementazione, puoi utilizzare entrambi i metodi quando progetti una nuova architettura.
Fonte: habr.com