In-memory database: ar­chi­via­zio­ne di Big Data

La co­mu­ni­ca­zio­ne digitale genera quantità sempre maggiori di dati (parola chiave: Big Data. Questa è una grande op­por­tu­ni­tà per le aziende che lavorano con dati di questo tipo. Tuttavia, maggiore è la mole di dati a di­spo­si­zio­ne di un'a­zien­da, più grande è la sfida di filtrare, in­ter­re­la­zio­na­re, mo­del­liz­za­re e va­lo­riz­za­re questi dati. Per sup­por­ta­re le aziende nel­l'e­la­bo­ra­zio­ne del flusso di in­for­ma­zio­ni sono necessari soluzioni e sistemi in­for­ma­ti­ci appositi. L'analisi dei dati mediante database tra­di­zio­na­li non è più suf­fi­cien­te per ar­chi­via­re, con­sul­ta­re ed elaborare grandi raccolte di dati. Gli in-memory database entrano in scena proprio quando i database classici rag­giun­go­no i loro limiti.

Un in-memory database (IMDB) si basa su un sistema di gestione di database che archivia le raccolte di dati di­ret­ta­men­te nella memoria centrale di uno o più computer. L'uso della memoria centrale ha un vantaggio decisivo, perché consente agli in-memory DB di rag­giun­ge­re velocità di accesso si­gni­fi­ca­ti­va­men­te più elevate e quindi di fornire i dati ar­chi­via­ti molto più ra­pi­da­men­te.

Gli in-memory database me­mo­riz­za­no enormi quantità di dati e for­ni­sco­no una serie di risultati di analisi. Ma come funziona esat­ta­men­te l'ar­chi­via­zio­ne dei Big Data e quali sono le tec­no­lo­gie ne­ces­sa­rie?

Nel­l'ar­chi­via­zio­ne dei dati con un in-memory database si distingue tra ar­chi­via­zio­ne basata su colonne e su righe (alcuni sistemi di database adottano entrambi i modelli). Le banche dati che sfruttano un modello a righe or­ga­niz­za­no i record di dati raccolti in una sola riga. Se, ad esempio, vengono salvati i valori nome, città e paese, i dati saranno disposti come segue: nome 1, luogo 1, paese 1, nome 2, luogo 2, paese 2. Se invece viene adottato un modello di ar­chi­via­zio­ne a colonne, i ri­spet­ti­vi dati vengono assegnati alle categorie cor­ri­spon­den­ti: nome 1, nome 2, luogo 1, luogo 2, paese 1, paese 2.

Il formato di ar­chi­via­zio­ne dei dati in colonna viene definito co­lumn­sto­re. Rag­grup­pa­re i dati con valori identici consente al sistema di ridurre al minimo la quantità dei dati esistenti di­mi­nuen­do, di con­se­guen­za, lo spazio di ar­chi­via­zio­ne richiesto e i tempi di tra­smis­sio­ne. Questo favorisce inoltre le pre­sta­zio­ni di analisi, poiché non è ne­ces­sa­rio ana­liz­za­re tutte le colonne, ma solo quelle rilevanti. Questa forma di va­lu­ta­zio­ne dei dati è chiamata Columnar Pro­jec­tion.

Il concetto di in-memory database non è nuovo. I fon­da­men­ti delle tec­no­lo­gie dei database sono stati svi­lup­pa­ti già a metà degli anni '80, ma a causa del­l'i­na­de­gua­tez­za delle in­fra­strut­tu­re in­for­ma­ti­che non è stato possibile attuarle con successo. Le moderne ar­chi­tet­tu­re in­for­ma­ti­che, come i data warehouse, la tec­no­lo­gia a 64 bit e i pro­ces­so­ri multi core, hanno infine permesso di im­ple­men­ta­re il concetto in modo più concreto, anche grazie alla di­spo­ni­bi­li­tà di memorie centrali sempre più eco­no­mi­che, che ne ha favorito ul­te­rior­men­te la dif­fu­sio­ne.

• Nella maggior parte dei casi gli in-memory database ap­par­ten­go­no a un data warehouse. Questi sistemi di database rac­col­go­no e com­pri­mo­no dati pro­ve­nien­ti da varie fonti, li ar­chi­via­no a lungo termine e li preparano per la suc­ces­si­va analisi.
• La tec­no­lo­gia a 64 bit consente di aumentare la capacità della memoria centrale, che può rag­giun­ge­re di­men­sio­ni fino a diversi terabyte. Gli in-memory DB sono quindi al­l'al­tez­za di grandi quantità di dati.
• I pro­ces­so­ri multi core sono composti da più core che lavorano in un unico chip, con con­se­guen­te mi­glio­ra­men­to della potenza di calcolo e una maggiore velocità di tra­smis­sio­ne dei dati. Il flusso di dati indica la quantità netta di dati tra­sfe­ri­ti per volta.

L'e­se­cu­zio­ne pratica degli in-memory database prevede alcuni processi ri­cor­ren­ti e identici. Un in-memory database esegue i seguenti passaggi per ar­chi­via­re dati:

1. Avvio del database: all'avvio del database il sistema carica l'intero set di dati dal disco rigido nella memoria centrale. Questo evita di dover caricare altri dati durante l'e­se­cu­zio­ne del database.
2. Sin­cro­niz­za­zio­ne dei dati mo­di­fi­ca­ti: qualora i dati venissero mo­di­fi­ca­ti, il database li sin­cro­niz­za a in­ter­val­li regolari.
3. Backup nei log delle tran­sa­zio­ni: le modifiche ef­fet­tua­te vengono salvate nei co­sid­det­ti tran­sac­tion log. Se si verifica un errore, il database può essere ri­pri­sti­na­to al momento pre­ce­den­te la comparsa dell’errore. Questo processo viene definito "roll-forward".
4. Ela­bo­ra­zio­ne dei dati: come per le banche dati tra­di­zio­na­li, i dati vengono elaborati secondo il principio ACID (Atomicità, Con­si­sten­za, Isolamento e Durabilità), che descrive le proprietà de­si­de­ra­te dei processi nei sistemi di gestione dei database.
5. Re­pli­ca­zio­ne del database: a scopo di backup il processo copia con­ti­nua­men­te i dati dal database su un computer o server.

Come già accennato, gli in-memory database sono in grado di rag­giun­ge­re velocità di accesso si­gni­fi­ca­ti­va­men­te più elevate ar­chi­vian­do i dati nella memoria centrale. Il vantaggio degli in-memory database è allo stesso tempo la causa del loro maggiore svan­tag­gio, perché la memoria centrale non consente un'ar­chi­via­zio­ne per­ma­nen­te dei dati. Quali sono gli altri vantaggi e svantaggi?

Il più grande vantaggio del­l'u­ti­liz­zo degli in-memory database è la velocità di accesso si­gni­fi­ca­ti­va­men­te più elevata, resa possibile grazie all'uso della memoria centrale. Questo ga­ran­ti­sce anche un'a­na­li­si più rapida dei dati e un calcolo preciso del tempo della query. L'ac­ce­le­ra­zio­ne, tuttavia, non è l'unico elemento che con­tri­bui­sce a ot­ti­miz­za­re l'analisi dei dati. Gli in-memory DB con­sen­to­no di elaborare sia dati strut­tu­ra­ti che non strut­tu­ra­ti pro­ve­nien­ti da qualsiasi sistema. Finora, l'ar­chi­via­zio­ne e l'e­la­bo­ra­zio­ne di una grande mole di dati non strut­tu­ra­ti, come testi, immagini, file audio e video, rap­pre­sen­ta­va­no processi piuttosto com­pli­ca­ti per aziende e soluzioni software.

L'utilizzo di in­fra­strut­tu­re di­stri­bui­te consente invece di ar­chi­via­re dati non strut­tu­ra­ti in un in-memory DB grazie alla col­la­bo­ra­zio­ne in parallelo di più unità di calcolo (computer, pro­ces­so­ri, ecc.) che lavorano su un compito comune (pa­ral­le­li­smo) e di­stri­bui­sco­no i dati a diversi cluster di server. In questo modo vengono garantite una maggiore capacità di ar­chi­via­zio­ne e una più elevata velocità di ela­bo­ra­zio­ne e tra­smis­sio­ne di dati non strut­tu­ra­ti.

Da un lato l'u­ti­liz­zo della memoria centrale ga­ran­ti­sce una maggiore velocità di accesso, ma dal­l'al­tro comporta anche uno svan­tag­gio con­si­de­re­vo­le, perché consente soltanto un'ar­chi­via­zio­ne a breve termine dei dati. In caso di crash del sistema tutti i dati volatili an­dreb­be­ro persi. Sono stati elaborati i seguenti metodi per evitare la perdita di dati:

• Snapshot del database: in de­ter­mi­na­ti momenti, ad esempio a in­ter­val­li pre­sta­bi­li­ti o prima del­l'ar­re­sto, viene me­mo­riz­za­ta la versione corrente del database. Tuttavia, il punto debole di questa misura è che tutti i file che vengono aggiunti dopo l'ultimo snapshot non vengono me­mo­riz­za­ti.
• Backup nei log delle tran­sa­zio­ni: un metodo di backup integrato nel processo è il sal­va­tag­gio delle modifiche nei tran­sac­tion log. Questi, combinati con snapshot regolari, con­sen­to­no di ri­pri­sti­na­re l'ultima versione del database in caso di crash.
• Re­pli­ca­zio­ne: la maggior parte degli in-memory database dispone già della funzione per ar­chi­via­re una copia esatta del database su un disco rigido tra­di­zio­na­le. In questo modo in caso di guasto è possibile ri­pri­sti­na­re il database ar­chi­via­to.
• Memoria RAM non volatile: una memoria RAM, se combinata con un di­spo­si­ti­vo di accumulo di energia, è in grado di re­cu­pe­ra­re i file anche dopo il riavvio del sistema.

L'uso della memoria centrale comporta anche un altro svan­tag­gio, perché la RAM che rimane a di­spo­si­zio­ne del computer stesso si riduce. Il grid computing in rete può essere una soluzione per con­tra­sta­re questa li­mi­ta­zio­ne. Nel grid computing molti computer diversi si collegano tra loro. Per par­te­ci­pa­re a questa rete è ne­ces­sa­rio in­stal­la­re un software apposito sul computer. Com­bi­nan­do le capacità inu­ti­liz­za­te viene creato un computer virtuale ad alte pre­sta­zio­ni.

Una banca dati è ge­ne­ral­men­te intesa come una raccolta di in­for­ma­zio­ni so­li­ta­men­te di­spo­ni­bi­le in formato elet­tro­ni­co. I database tra­di­zio­na­li ar­chi­via­no uni­ca­men­te dati strut­tu­ra­ti. Si parla di dati strut­tu­ra­ti quando campi di dati univoci vengono or­ga­niz­za­ti in record di dati concreti. I record di dati vengono disposti in tabelle, dove ogni campo rap­pre­sen­ta un attributo diverso, con una relativa de­no­mi­na­zio­ne. Il movimento Big Data ha spinto il modello ai suoi limiti, evi­den­zian­do­ne i punti deboli nel­l'ar­chi­via­zio­ne e nel­l'e­la­bo­ra­zio­ne di grandi quantità di dati. Un'altra sfida è la ridotta adat­ta­bi­li­tà del database. Dati non strut­tu­ra­ti, come immagini e documenti in lin­guag­gio naturale, non possono essere ar­chi­via­ti ed elaborati.

Dopo aver pre­sen­ta­to i vantaggi e gli svantaggi degli in-memory database e averli con­fron­ta­ti di­ret­ta­men­te con i database tra­di­zio­na­li, dovreste avere già un'idea di quale sistema di gestione di database (DBMS) è più adatto alle vostre esigenze. Se lavorate con una mole di dati molto grande non avete altra opzione che scegliere un in-memory DB. Il database nella memoria centrale potrebbe tuttavia essere la scelta giusta anche in altri scenari.

Un in-memory database è il DBMS più adatto per voi, se:

• di­spo­nen­te di un'ampia raccolta di dati;
• ne­ces­si­ta­te di un accesso rapido e frequente ai vostri dati;
• i vostri sistemi o server di gestione dei database esistenti sono so­vrac­ca­ri­chi;
• la per­si­sten­za dei vostri dati non ha la massima priorità;
• potete tollerare il rischio di una possibile perdita dei vostri dati.

Tra i più noti in-memory database ri­cor­dia­mo SAP HANA e Oracle TimesTen. Per aziende alla ricerca di software aziendale con ricche fun­zio­na­li­tà le soluzioni SAP e Oracle sono le più popolari. Entrambi i sistemi di gestione dei database rag­giun­go­no le massime pre­sta­zio­ni possibili. Cosa li distingue e qual è il loro uso pratico in azienda?

L'in-memory database SAP HANA (High Per­for­man­ce Analytic Appliance) è una com­bi­na­zio­ne di hardware e software. Il software è stato svi­lup­pa­to di­ret­ta­men­te da SAP, mentre l'hard­ware (server) proviene da 10 pro­dut­to­ri diversi. A dif­fe­ren­za di altri in-memory database, SAP HANA non archivia i dati tem­po­ra­nea­men­te, ma per­ma­nen­te­men­te nella memoria centrale e salva i dati uti­liz­zan­do i log delle tran­sa­zio­ni.

L'e­la­bo­ra­zio­ne di tran­sa­zio­ni e analisi in una banca dati comune consente di elaborare le in­for­ma­zio­ni in tempo reale. SAP HANA può essere uti­liz­za­to sia sul server aziendale che nel cloud, al­leg­ge­ren­do così le strutture in­for­ma­ti­che del­l'a­zien­da. I costi dei metodi di gestione dati finora uti­liz­za­ti vengono inoltre ridotti al minimo e i re­spon­sa­bi­li de­ci­sio­na­li ricevono nuove e accurate pre­vi­sio­ni.

Il database di Oracle e quello di SAP hanno molto in comune. Anche in questo caso l'e­la­bo­ra­zio­ne dei dati avviene in tempo reale e l'ap­pli­ca­zio­ne può essere uti­liz­za­ta sia sul server che nel cloud. A dif­fe­ren­za del database di SAP, il software e l'hard­ware di Oracle TimesTen vengono entrambi svi­lup­pa­ti da Oracle stessa.

Si tratta dunque di un'ap­pli­ca­zio­ne Oracle pura. Il vantaggio che ne deriva per l'utente è che in caso di errore si può agire in­ter­na­men­te e l'azienda non dipende da diverse società hardware e software. Oracle non archivia i dati raccolti esclu­si­va­men­te nella memoria centrale: i dati che non ne­ces­si­ta­no di pre­sta­zio­ni elevate possono, infatti, essere ar­chi­via­ti sul disco rigido o su un disco flash.

Le funzioni di SAP HANA e Oracle TimesTen sono so­stan­zial­men­te identiche. Questo significa che anche i vantaggi prin­ci­pa­li che le due soluzioni possono offrire alla vostra azienda sono identici:

• Ela­bo­ra­zio­ne più rapida dei dati
• Rio­rien­ta­men­to del­l'a­zien­da grazie ad ap­pli­ca­zio­ni in­no­va­ti­ve
• Maggiore agilità in termini di fles­si­bi­li­tà, attività e adat­ta­bi­li­tà

La seguente tabella riassume le dif­fe­ren­ze e le si­mi­li­tu­di­ni tra i due in-memory database:

Con l'a­van­za­re della di­gi­ta­liz­za­zio­ne le già ingenti quantità di dati con­ti­nue­ran­no a crescere. Il costante sviluppo dei sistemi esistenti è quindi un aspetto cruciale per gli svi­lup­pa­to­ri di in-memory database. Questo sviluppo deve con­cen­trar­si sui seguenti aspetti:

• Ac­qui­si­zio­ne di dati da un numero crescente di fonti
• Sem­pli­fi­ca­zio­ne ulteriore delle strutture in­for­ma­ti­che, riduzione dei tempi di risposta e in­cre­men­to delle velocità di analisi
• Ottenere maggiori in­for­ma­zio­ni dal­l'a­na­li­si dei dati e sostenere le aziende nei processi de­ci­sio­na­li
• Sviluppo di ap­pli­ca­zio­ni ancora più orientate alle sfide del cam­bia­men­to digitale

Gli in-memory database si sono affermati come una tec­no­lo­gia di successo per l'ar­chi­via­zio­ne e l'e­la­bo­ra­zio­ne dei dati nella memoria centrale. Con­sen­to­no per la prima volta alle aziende che devono gestire grandi quantità di dati di ana­liz­za­re i Big Data il più ra­pi­da­men­te possibile e di accedervi in qualunque momento. Un uso efficace degli in-memory database è tuttavia possibile solo se il luogo di ar­chi­via­zio­ne dei dati non si limita esclu­si­va­men­te a un in-memory database e se nei processi vengono integrati anche sistemi stan­dar­diz­za­ti per il backup dei dati.