In-Memory Data Grid

L’avvento di sistemi cloud, social media e IoT (Internet of Things) ha creato la necessità di applicazioni estremamente veloci e in grado di elaborare milioni di transazioni al secondo. Per incrementare la velocità nell’elaborazione dati sono nate i sistemi IMDG (In Memory Data Grid)

IMDG è una struttura dati che risiede interamente nella RAM (memoria ad accesso casuale) ed è distribuita tra più server.

IMDG è un archivio di oggetti distribuiti, gli oggetti si memorizzano con le chiavi. A differenza dei sistemi tradizionali in cui le chiavi e i valori sono spesso limitati a matrici o stringhe di byte, con IMDG è possibile utilizzare qualsiasi oggetto dominio come valore o chiave. Ciò offre un’enorme flessibilità consentendo di mantenere esattamente lo stesso oggetto nella griglia, senza il passaggio supplementare del marshaling e del de-marshalling che le tecnologie tradizionali richiederebbero. Semplifica inoltre che nella maggior parte dei casi l’interfacciamento con l’archivio dati distribuito avviene con una semplice mappa hash. Essere in grado di lavorare direttamente con gli oggetti di dominio è una delle principali differenze tra IMDG e Database In-Memory (IMDB). Con quest’ultimo, gli utenti devono comunque eseguire il mapping Object-to-Relational, che in genere aggiunge un significativo overhead delle prestazioni.

Esistono anche altre funzionalità in IMDG che le distinguono da altri prodotti, come database NoSql, IMDB o database NewSql. Una delle principali differenze sarebbe il partizionamento dei dati veramente scalabile su cluster. Essenzialmente gli IMDG nella loro forma più pura possono essere visualizzati come mappe hash distribuite con ogni chiave memorizzata in cache su un particolare nodo del cluster: più grande è il cluster, maggiore è il numero di dati che è possibile memorizzare nella cache. Il trucco per questa architettura è assicurarsi di collocare l’elaborazione con i nodi del cluster in cui i dati vengono memorizzati nella cache per assicurarsi che tutte le operazioni della cache diventino locali e che non vi sia (o minimo) spostamento di dati all’interno del cluster. In effetti, quando si utilizzano IMDG ben progettati, non dovrebbe esserci assolutamente alcun movimento di dati su topologie stabili – l’unico momento in cui alcuni dei dati vengono spostati è quando i nuovi nodi si uniscono o alcuni nodi esistenti lasciano, quindi provocano il partizionamento dei dati all’interno del cluster .

L’immagine qui sotto mostra un IMDG classico con una serie di chiavi {k1, k2, k3} in cui ogni chiave appartiene a un nodo diverso. Il componente del database esterno è facoltativo. Se presente, quindi IMDG di solito legge automaticamente i dati dal database o scrive i dati su di esso.

In-memory Datagrid graphic

Un’altra caratteristica distintiva degli IMDG è il supporto ACID transazionale. Generalmente viene utilizzato un protocollo di commit a 2 fasi (2PC) per garantire la coerenza dei dati all’interno del cluster. I diversi IMDG avranno diversi meccanismi di blocco sottostanti, ma di solito implementazioni più avanzate forniranno meccanismi di blocco simultanei (come MVCC – controllo di concorrenza multi-versione) e ridurranno al minimo la network chattiness, garantendo così la coerenza ACID transazionale con prestazioni molto elevate.

La coerenza dei dati è una delle principali differenze tra i database IMDG e NoSQL. I database NoSQL sono in genere progettati in base all’approccio di coerenza finale (EC) in cui i dati possono essere incoerenti per un periodo di tempo purché diventino coerenti. In generale, le scritture sui sistemi basati su EC sono piuttosto veloci, ma le letture sono lente (o per essere più precisi, tanto quanto le scritture). Gli IMDG più recenti con un 2PC ottimizzato, sono paragonabili ai sistemi basati su EC nelle scritture e sono significativamente più veloci nelle letture. È interessante notare che l’industria ha fatto un giro completo passando da un approccio 2PC allora lento all’approccio CE, e ora dalla CE a un 2PC ottimizzato che spesso è significativamente più veloce.

Prodotti diversi offrono diverse ottimizzazioni 2PC, ma generalmente lo scopo di tutte le ottimizzazioni è aumentare la concorrenza, ridurre al minimo l’overhead di rete e ridurre il numero di blocchi necessari per completare una transazione. Ad esempio, il database globale distribuito di Google, Spanner, si basa su un approccio transazionale 2PC semplicemente perché 2PC ha fornito un modo più rapido e diretto per garantire la coerenza dei dati e un elevato throughput rispetto a MapReduce o EC.

Sebbene gli IMDG di solito condividano alcune funzionalità di base comuni, ci sono molte caratteristiche e dettagli di implementazione che differiscono tra i fornitori. Quando si valuta un prodotto IMDG, serve prestare attenzione alle eviction policies, alle tecniche (pre)loading, al concurrent repartitioning, memory overhead, etc. Serve prestare attenzione anche alla capacità di interrogare i dati in fase di esecuzione. Alcuni IMDG, come ad esempio GridGain, consentono agli utenti di eseguire query sui dati in memoria utilizzando SQL standard, incluso il supporto per i join distribuiti, il che è piuttosto raro.

L’uso tipico per IMDG è di partizionare i dati attraverso il cluster e quindi inviare collocated computations ai nodi in cui si trovano i dati. Poiché i calcoli di solito fanno parte delle Compute Grids e devono essere correttamente distribuiti, bilanciati in base al carico, failover o pianificati, l’integrazione tra Compute Grids e IMDG è molto importante. È particolarmente utile che sia In-Memory Compute che Data Grids utilizzino le stesse API così da rimuovere necessità di integrazione e rendere i sistemi più performanti e affidabili.

In-Memory Computing graphic

Gli IMDG (insieme alle reti di calcolo) sono utilizzati in una vasta gamma di settori in applicazioni diverse come Analisi del rischio, Sistemi di trading, Bioinformatica, e-commerce o giochi online. In sostanza ogni progetto che lotta con la scalabilità e le prestazioni può trarre vantaggio dall’elaborazione in memoria e dall’architettura IMDG.