Contesto

I database classici vengono implementati partendo da uno schema entità/relazione. Ogni entità e associazione ’molti a molti’ corrisponde ad una tabella, mentre le relazioni vengono mappate con l’utilizzo di chiavi esterne e id univoci corrispondenti. Questo porta alla descrizione di una struttura leggibile e facilmente gestibile per quanto riguarda la modifica e l’inserimento dei dati, ma purtroppo anche ad un ritardo nelle risposte delle query dovuto al numero di join effettuati tra le tabelle, operazione molto costosa in termini di tempo. Il database relazionali non riesce, quindi, ad essere scalabile nel caso di grosse base dati, come quelle relative ai portali web di e-commerce o ai social network essendo composte da miliardi di dati: le prestazioni offerte in termini di tempo di risposta non diventano soddisfacenti. Inoltre, nel caso di utilizzo di cloud, la memorizzazione di dei dati diventa ancora più complicata nella sua gestione essendo posta su supporti di massa composti da migliaia di nodi.

Database non relazionali

I database non relazionali non memorizzano i dati in tabelle distinte collegate secondo le associazioni definite. Idealmente ogni entry contiene tutti gli attributi associati. Questa caratteristica porta alla necessità di definire una base di dati totalmente denormalizzata con i vantaggi legati alla ricerca e all‘estrazione di informazioni, ma producendo anche il difficile controllo dell‘integrità e della consistenza.
Tuttavia, è possibile specificare relazioni tra le entità definite, anche se la loro gestione avviene ad alto livello: non vengono assolutamente effettuate operazioni di join da parte del dbms potendo così gestire la struttura delle base dati in tempo reale nel caricamento dell‘applicazione.
Google app Engine utilizza la BigTable che è un sistema di storage non relazionale distribuito e progettato appunto, per la memorizzazione di grandi quantità di dati. La sua caratteristica principale è la scalabilità offerta che consente il salvataggio di petabyte di dati raccolti in centinaia di server. Molte applicazioni create da Google utilizzano questo sistema come dbms, incluso il motore di ricerca, Google Earth e Google Finance avendo esigenze particolari riguardo l‘utilizzo del dbms sia in termini di contenuto(URL, pagine web, immagini satellitari) e sia di latenza massima (risposte real–time o asincrone).
Per quanto riguarda la struttura il modello di dati BigTable è una mappa multidimensionale distribuita e ordinata. L‘indice della mappa è dato da una chiave di riga, una chiave di colonna e un timestamp. Ogni valore contenuto in ogni cella è un array di byte non interpretato.
Per queste caratteristiche BigTable fa parte della classe di database non relazionali key–value, ovvero ogni elemento è univocamente definito da una chiave e le associazioni vengono specificate come chiavi contenute negli attributi. Inoltre, la memorizzazione di ogni entità avviene nella stessa struttura definita.
Questa mappa, una volta raggiunte dimensioni prefissate, viene distribuita nel cloud suddividendone le righe. Le chiavi di riga sono stringhe arbitrarie. Ogni operazione di lettura o scrittura compiuta utilizzando una chiave di riga è atomica, qualsiasi sia il numero di attributi o colonne presenti.
BigTable mantiene i dati ordinati in ordine lessicografico per chiave di riga. Per la distribuzione e la partizione tra i server viene stabilito un numero di righe che costituisca l‘unità di caricamento della base di dati, il tablet. Mentre il modello logico viene mappato nel database fisico e replicato in ogni data center del cloud in modo tale possano essere riconosciute e gestite le righe del tablet. Le chiavi di colonna vengono raggruppate in insiemi chiamati famiglie. Esse formano l‘unità di base per il controllo d‘accesso. Le famiglie contengono dati omogenei e devono essere dichiarate prima che qualsiasi dato venga memorizzato utilizzando una qualsiasi chiave di colonna appartenente. L‘idea base è di mantenere basso il numero di famiglie presenti consentendo comunque un numero illimitato di colonne: ogni cella in BigTable può contenere versioni multiple dello stesso dato venendo indicizzate da un timestamp rappresentato da un intero a 64 bit. Il riferimento temporale può essere assegnato automaticamente dal dbms al momento dell‘inserimento del dato nella cella o assegnato dall‘utente. In questo modo vengono evitate le collisioni. Versioni differenti vengono salvate, infatti, con timestamp decrescenti in modo tale il dato più recente sia il primo ottenuto. Inoltre attraverso l‘indicazione dell‘istante di inserimento è possibile ricavare informazioni sui dati obsoleti presenti. BigTable a tal proposito consente all‘utente di definire le versioni da mantenere e quelle da passare al garbage collector. La creazione dei cluster BigTable è iniziata nel 2005, l‘anno successivo sessanta progetti utilizzavano questo dbms. In particolare, le prestazioni e l‘affidabilità fornite da questo servizio, unite alla capacità di aumentare la quantità di dati inseriti, semplicemente aggiungendo nuove risorse hardware al sistema, hanno portato questa infrastruttura al centro dell‘attenzione di molti progetti di ricerca e sviluppo attualmente ancora in corso.