Da MongoDB a Elastic Search: conoscere i database ad alte prestazioni

Database – O se preferite, banca dati, come certa stampa generalista tende a riferirli. Ma come si sono evoluti fino ad oggi? Considerando la velocità con cui CPU, RAM ed elettronica sono migliorate anno dopo anno, ci sarebbe da stupirsi se la tecnologia delle banche dati non avesse seguito lo stesso ritmo. In effetti è stato proprio così, e ciò – cosa che molti non sanno – è avvenuto spesso migliorando non soltanto il supporto hardware e software ma anche, per non dire soprattutto, la struttura (detta in gergo schema) alla base dei dati stessi.

Bisogna però inquadrare correttamente la questione, e lo faremo passando in rassegna 4 possibili tecnologie di database che non tutti hanno presente, e che rendono l’idea dello stato dell’arte attuale. Se si pensa alla tecnologia dei database, infatti, è facile immaginarla come un foglio Excel o Microsoft Access, almeno a livello semplificato e molto divulgativo.

Tale approssimazione, per quanto non del tutto inesatta, rischia di essere parziale, inesatta e addirittura fuorviante se si prendono in considerazione le tecnologie a supporto dei database che sono state sviluppate ad oggi. Molte delle quali, come vedremo, hanno concepito schema e tecniche di accesso ai dati sempre più veloci, efficienti e agevoli da usare.

MySQL in-memory

Siamo abituati a pensare al database MySQL come a una struttura che memorizza informazioni in modo veloce, efficiente – ma soprattutto permanente. Quello che salvo al suo interno, in altri termini, posso recuperarlo e modificarlo “al volo” in qualsiasi momento; ciò mi permette di gestire dati strutturati di vario genere con grande varietà di linguaggi, API e pattern di programmazione. Se userò MySQL per memorizzare il contenuto delle pagine web di WordPress, ad esempio, è chiaro che mi aspetterò di ritrovare quei dati in futuro, sia qualora un utente visualizzerà quel contenuto (modalità sola lettura) che quando vorrà modificarla (modalità lettura e scrittura).

Un esempio di database relazionale potrebbe essere il seguente, nel quale in gergo la prima colonna serve a identificare una riga specifica – che viene detta chiave primaria:

L’approccio noto come MySQL In-memory va oltre questo concetto, sfruttando un motore di database specifico detto MEMORY (oppure Heap). Esso è in grado di creare tabelle a uso specifico, le quali vengono memorizzate nella RAM. Tale accorgimento rende l’applicazione utile a gestire grandi quantità di dati, per contesti software di ogni genere, minimizzando i tempi di accesso in lettura e scrittura.

Chiaramente, l’uso di una tecnologia del genere massimizza, in media, la RAM necessaria per compiere le operazioni, che potrebbe arrivare a diversi GB (Giga Byte), a differenza della RAM a uso classico, per così dire, che viene sfruttata da altre tipologie di app e che è dell’ordine dei Mega Byte.

MongoDB

MySQL non è l’unica alternativa possibile; anzi, al contrario, per alcuni tipi di applicazione non risulta essere troppo adatto. Se dobbiamo gestire un insieme di tabelle con molte righe e poche colonne, ad esempio, non risulta per forza il modo migliore; ed è così che si è pensato di fare uso di una più generica accezione di schema, che diventa in questo caso un document (con paradigma contrapposto al precedente, ovvero NoSQL). A differenza delle tabelle, i document NoSQL sono contenitori di dati strutturati, dotati di un potere espressivo differente e più snelli, se vogliamo, di una tabella.

L’approccio di Mongo DB è stato pertanto sviluppato con tecnologia NoSQL (orientata ai documenti), che si limita a memorizzare i dati che servono in formato JSON (JavaScript Object Notation). Per un informatico “tradizionalista” – o per chi ha lavorato solo su database relazionali – può sembrare quasi un controsenso (a cominciare dal nome), ma di fatto è proprio così: la tecnologia NoSQL permette, nel caso di MongoDB, di memorizzare dati sfruttando un format strutturato.

Il vantaggio principale si ha nel momento in cui mi servono tantissimi accessi rapidi a coppie di chiave/valore, dove la chiave è l’elemento identificativo (in una rubrica telefonica, potrebbe essere il nome e cognome di una persona) mentre il valore rappresenta il campo informativo associato alla chiave (nella rubrica, il numero di telefono). In questo caso, pertanto, i dati potrebbero essere memorizzati come segue, giusto per fare un esempio concreto (e facile da capire):

Film = {“Titolo”: “2001 Odissea nello spazio”}

Si tratta di un formato strutturato con un solo record, come possiamo vedere, sul modello chiave/valore e una sintassi in cui i due punti (:) servono a delimitare i campi. Per inserire dati nel database db, tabella film, con un comando che sfrutti la dot notation (notazione con il punto, tipica dei linguaggi di programmazione) e le stringhe JSON, potrei a questo punto digitare un semplice comando NoSQL come:

db.film.insert({“Titolo”: “2001 Odissea nello spazio”})

SAP HANA

Il format imposto da NoSQL è efficace per superare i limiti dei database relazionali, ma nella composizione di query complesse può diventare difficile da gestire. Il modello basato su SAP HANA (high-performance Analytic Appliance, di proprietà della multinazionale tedesca SAP SE) propone uno schema che sfrutta sempre la tecnologia in-memory, ma si basa sulle colonne anziché sulle righe.

Un database relazionale classico, per capirci, rappresenterebbe le informazioni in un formato “tipo Excel”, per intenderci:

Mediante un procedimento noto come serializzazione, i dati in formato colonna per SAP HANA avrebbero una notazione (e un formato conseguente) differente, in cui esiste una maggiore ridondanza nella rappresentazione dei dati ma, al tempo stesso, non mi serve avere più una colonna chiave primaria (che in questo caso era ID_Riga). Questa su larga scala ha vantaggi enormi, venendo incontro a eventuali esigenze adattative e di ridimensionamento dei dati.

Ed ecco come la tabella di sopra sarebbe “convertita” in colonne, a questo punto:

10:001,12:002,11:003,22:004;
Jack:001,Domenica:002,Stefania:003,Salvatore:004;
Capellupo:001,Commerci:002,Abili:003,Reitera:004;
60.000:001,80.000:002,94.000:003,55.000:004;

Anche se può sembrare contro-intuitivo per i non addetti ai lavori, i database per colonne si adattano all’analisi predittiva, all’analisi e alla ricerca nei testi, allo studio del flusso dei grafi e via dicendo.

Elasticsearch

Ciò che offre questa ultima tecnologia di database va anch’essa oltre MySQL: nello specifico, sfrutta il formato JSON che abbiamo già visto in precedenza, ed è basata stavolta sulla “storica” API di Lucene. Elasticsearch viene sfruttato primariamente per realizzare motori di ricerca (enterprise search engine) di vario genere, ad esempio interni ad archivi di un’azienda. E non solo: il suo utilizzo all’interno del web è consolidato da anni, tanto da costituire parte integrante di siti web famosi come, ad esempio, i motori di ricerca interni di Wikipedia e Netflix.

Elasticsearch viene utilizzata per gestire e rendere ricercabili enormi quantità di dati, seguendo gli schema più diversi, oltre che nei contesti più diversificati; il tutto anche – e forse soprattutto – grazie al modo in cui è stata progettata. Essa infatti presenta un’interfaccia API unica basata su HTTPS, e può funzionare con client Java, .NET, PHP, Python ed altri.

Come fare funzionare queste tecnologie

La carrellata di opportunità che abbiamo visto sarebbe parziale, di fatto, se ci limitassimo a elencarla e snocciolarne esempi d’uso: una volta chiarita la differenza negli use-case e a livello implementativo, come facciamo a metterla a disposizione del reparto IT delle nostre aziende? La risposta sta nel rivolgersi a un servizio che sia in grado di erogare, ad esempio a quote mensili, il servizio hardware e software di cui abbiamo bisogno.

Quasi certamente ci servirà un supporto tecnologico guidato e pronto  (o quasi) all’uso, sfruttando soluzioni specifiche come l’offerta High memory di Seeweb, che sembra essere adeguata al supporto delle tecnologie specificate. I database ad alte prestazioni, così facendo, non saranno più un’esclusiva degli attori più consolidati sul mercato, ma si potranno utilizzare anche nell’ambito di startup informatiche, pubbliche amministrazioni, realtà che vogliano innovare nel proprio ambito e PMI.

Photo by fabio on Unsplash

leultime.info

Leultime.info è un blog collaborativo che ispira armonia. Sul nostro blog, promuoviamo un approccio sostanziale alla comunicazione, incoraggiando a condividere opinioni in modo costruttivo e rispettoso. Gli articoli non riflettono necessariamente la visione del proprietario del progetto.