Uno dei segni della costante e rapida evoluzione tecnologica nel campo della gestione e dell'analisi dei dati è che i CIO e gli sviluppatori devono familiarizzare in fretta con termini sempre nuovi. Ultimamente si sta diffondendo l'uso di un termine - translytical - che fa riferimento a una evoluzione dei database non proprio nuovissima ma oggi di sempre maggiore attualità. Gli analisti hanno infatti cominciato già un paio di anni fa circa a parlare di database translytical e ci sono diverse piattaforme importanti che possono essere definite in tal modo, oggi il termine è stato nella pratica sostituito da "Big Data analytics" ma un po' impropriamente. Ci sono alcune peculiarità dei database "translitici" che vale la pena esaminare.

Come è facile intuire, translytical deriva dalla combinazione di transactional e analytical. Il termine fa quindi riferimento a un database che possa essere adatto sia per la gestione delle transazioni (il campo del buon vecchio OLTP) sia per l'esecuzione di analisi approfondite sui dati memorizzati. L'elemento chiave è queste analisi devono avvenire in tempo reale, non a posteriori come nelle applicazioni di analytics di impostazione classica, applicate o meno a Big Data. Da questa definizione di massima derivano tre importanti requisiti di un database translytical: è ottimizzato per le operazioni di scrittura dei dati (come i database OLTP), lo è anche per le operazioni di lettura (come i DB analitici) e in più deve essere davvero molto veloce (per eseguire analisi approfondite mentre la transazione si sta completando, non dopo).

L'esempio classico di applicazione dei database translytical è la gestione e valutazione in tempo reale delle operazioni finanziarie, anche di un semplice pagamento con carta di credito. Mentre il pagamento viene effettuato e memorizzato nel database, si eseguono anche diversi algoritmi complessi che devono valutare immediatamente se la transazione è corretta o fraudolenta. Chiaramente l'approccio "raccolta dati / analisi in tempo reale / reazione" è interessante anche per applicazioni meno tradizionali, come ad esempio quelle di edge computing in ambito IoT piuttosto che quelle legate a tutta la app economy del mondo mobile.



Tecnicamente un translytical database è inevitabilmente una piattaforma in-memory, perché solo questo approccio alla conservazione dei dati garantisce la velocità necessaria alle elaborazioni in tempo reale e soprattutto una latenza prevedibile nell'accesso alle informazioni. E' anche una piattaforma che fa uso intensivo di funzioni di compressione dei dati, per otimizzare l'occupazione della memoria, ed è multimodale, ossia in grado di gestire tipi di dati anche molto diversi fra loro. Di norma adotta logiche di data tiering, per spostare i dati su supporti diversi in funzione della necessità e della frequenza di accesso, e una architettura scale-out per poter offrire prestazioni proporzionali ai carichi di lavoro. L'architettura è di solito anche distribuita per garantire la disponibilità costante dei dati anche in caso di guasti per i singoli sistemi.

Non è detto che tutte le imprese debbano adottare database translytical per qualsiasi operazione di gestione e analisi delle informazioni. In molti casi la classica analisi ex-post è sufficiente, spiegano gli osservatori, e le imprese interessate a forme più evolute di analytics possono comunque approcciare il mondo translytical in maniera graduale. Si può ad esempio scegliere una piattaforma translytical per le applicazioni chiave (BI, ERP) e non per le altre, almeno all'inizio, oppure concentrarsi su classi di informazioni specifiche (finanziarie, di produzione...) e non su altre.