I database ai tempi del Big Data e dell'IoT

Oggi esistono più di 20 miliardi di device smart connessi alla Rete che analizzano, raccolgono e condividono dati. Per catalogare ed elaborare in tempi brevi tali informazioni servono nuovi paradigmi per i database. In pratica un buon database deve offrire prestazioni ottimali, sicurezza ed integrità dei dati trattati nonché efficienza sul lungo termine dato che la mole di dati trattati aumenta esponenzialmente anno dopo anno.

Il modo migliore per determinare quale tipo di database serve per il nostro progetto è domandarsi "quale sarà il task principale da eseguire? E quali saranno le principali difficoltà da affrontare?" Una volta ottenuta la risposta a tale domanda è possibile iniziare ad orientarsi. Ma andiamo con ordine ed esaminiamo le principali difficoltà che si attraversano attualmente nella realizzazione e nella gestione di un database:

Sicurezza dei dati

Si stima che negli ultimi due anni ben 100 mila database siano stati violati, questo perché completamente esposti alla Rete. Oggi i principali database dispongono di regole di sicurezza facili da implementare ed attivare, sono disponibili anche tool e servizi integrati in grado di segnalare malfunzionamenti o rischi per la sicurezza. Non tenere conto della sicurezza è quindi deleterio, le misure di sicurezza vanno invece prese in considerazione fin da subito, magari sfruttando database che le implementano nativamente.

Performance

I database hanno sempre avuto criteri di performance severi, la quantità dei dati che si acquisiscono si può espandere senza preavviso e soddisfare le query degli utenti richiede che il database sia costruito in modo da adattarsi al numero di dati e alle interrogazioni senza generare latenze. Ottenere delle buone performance richieste costante attenzione e il lavoro di ottimizzazione non è mai definitivo. Ad esempio, se si vogliono testare le performance del proprio database è possibile usare una board ARM Rasbperry Pi come banco di prova. Se il database manifesta buone performance con essa probabilmente è già ben ottimizzato.

Integrità dei dati

I dati devono essere elaborati in modo da garantire che nulla vada perso. Che si tratti di un database non relazionale o di un cluster distribuito, deve essere implementato un sistema ACID (Atomicity, Consistency, Isolation, Durability). Infatti affinché le transazioni operino in modo corretto è necessario che i meccanismi che le implementano rispettino tali proprietà:

• atomicità: la transazione è indivisibile nella sua esecuzione quest'ultima deve essere o totale o nulla, non è possibile avere esecuzioni parziali;
• consistenza: quando inizia una transazione il database si trova in uno stato definito "coerente", quando essa termina il database deve essere in un altro stato coerente, quindi è possibile violare eventuali vincoli di integrità cosi che non possano verificarsi incoerenze tra i dati archiviati nel database;
• isolamento: ogni transazione deve essere eseguita in modo isolato e indipendente dalle altre, in caso di fallimento di una transazione essa non dovrà in alcun modo interferire con le altre;
• durabilità: quando la transazione richiede un commit work, ovvero una modifica al database, tale cambiamento non dovrà essere dimenticato o perso. Quindi per evitare perdite di dati i database moderni hanno a dispostone dei registi di log di tutte le operazioni.

Utilizzo delle risorse

In passato si presupponeva che i database potessero dare il meglio solo sull'hardware più performante. Tuttavia grazie all'arrivo dei container e al deploy su macchine virtuali questo paradigma è parzialmente caduto. Quindi per mantenere alte le prestazioni con una potenza di calcolo limitata e gestire una quantità maggiore e più complessa di dati un database deve spremere il 100% delle risorse dal sistema in cui sta lavorando per ogni nanosecondo in cui rimane in esecuzione.

Sempre disponibile

In un singolo database server, se il server si arresta, tutto smette di funzionare. Un cluster costituito da più server che lavorano insieme offre più livelli di backup. Un database distribuito ha anche un failover delle assegnazioni, quindi quando un nodo che esegue un'attività specifica va in crash o si spegne quell'attività viene automaticamente trasferita su un altro nodo funzionante.

Un buon database va progettato prendendo in considerazione soluzioni innovative per garantire sempre la disponibilità del servizio e non solo per mantenere buone prestazioni.

Via Oren Eini