Google BigTable Project
Il progetto “BigTable” è partito nel 2004. Nel 2005 erano operative 100 celle utilizzate nella quotidiana attività di numerosi servizi on-line: Google Print, My Search History, Orkut, Google Maps, Google Earth, Blogger… e naturalmente nel crawling e nell’indicizzazione delle pagine web. La più grande di queste celle era in grado di gestire 200 terabyte di dati ottenuti dall’interazione asincrona di migliaia di server.
Jeffrey Dean (Jeff Dean), Google Fellow nel Systems Infrastructure Group dei GoogleLabs, apre le porte al dietro le quinte del progetto BigTable mettendo a nudo le possibilità del Google content storage system.
Quando? Era l’autunno del 2005.
L’occasione? La sua relazione all’Università di Washington.
Si parte da qui: Google utilizza un database commerciale ottimizzato per lo storage e il backup dei dati? Certo che no! Perché?
- La quantità dei dati da gestire è troppa, anche per il migliore dei database commerciali;
- Si punta all’ottimizzazione delle risorse, in primo luogo economiche: i costi elevati per ottimizzare un’applicazione commerciale sono incompatibili sia con la politica del “low incremental cost” dell’azienda, che con i risultati ottenibili dall’ “upgrade” del prodotto.
Allora qual’è l’approccio di Google alla BigTable?
Intanto occorre capire le esigenze dell’azienda. Google ha bisogno di un sistema che:
- permetta di accedere in modo asicrono ai dati in qualsiasi momento.
- offra garanzie di updating continuato.
- possa gestire milioni di operazioni al secondo.
- garantisca un’ottima performance per interazioni di dati one-to-one e one-to-many.
- sia in grado di gestire le informazioni sui contenuti di una pagina web, ottenute dall’azione di più crawl.
Detto questo, Jeff Dean passa ad illustrare le caratteristiche della BigTable:
- generare mappe multi-livello;
- persistenza e tolleranza degli errori;
- scalabilità nella gestione di migliaia di server, dei terabyte di dati, dei petabyte (questa non l’avevo mai sentita!) necessari per l’immagazzinamento dei dati, di un efficente scanning (per secondo) di milioni di letture/scritture;
- gestione dei server dinamica e automatizzata;
- adattabilità dei server in situazioni sbilanciate.
Fin qui i primi dieci minuti della relazione. Dura un’ora e la vale tutta! Postata su Google Video dallo stesso Jeff Dean… il 18 Ottobre 2005.
Vi ripropongo il link: BigTable: A Distribuded Structured Storage System.
Un anno dopo, sempre dai Googlelabs
Jeff Dean torna a parlare di BigTable nel Novembre 2006. Ai servizi on-line che utilizzano le celle si aggiunge Google Finance, assente nell’elenco 2005 fornito dal Google Fellow. Nel PDF della relazione si prende ad esempio CNN.com per spiegare in che modo Google si lavora il contenuto di una pagina web. Si parla di API, Table Location, implementazioni, Table Assigment, Table Serving, compattazione dei dati, caching, compressioni, filtri etc.
Oltre a Jeff Dean, le altre menti del BigTable Project, così come elencate nel paper del 2006: Fay Chang, Sanjay Ghemawat, Wilson C. Hsieh, Deborah A. Wallach, Mike Burrows, Tushar Chandra, Andrew Fikes, and Robert E. Gruber.
Congetture e leggende metropolitane
Nessuno può dare risposte ad un progetto che da solo rappresenta il core business di un’azienda, se non in base a quanto letto e riportato dai comunicati e le relazioni ufficiali dell’azienda stessa. Così mi immedesimo nella parte del “congetturologo” e del “legendhunter“, un pò per gioco e un pò per curiosità e tiro giù le mie opinioni a riguardo.
Nessuno potrà mai convincermi che Jeff Dean e compagni abbiano messo davvero a nudo la BigTable. Ne hanno fornito una lettura generalistica ad uso e consumo delle Pr. Interessante chiedersi verso chi fossero rivolte: azionisti (forse, no…), investitori (probabile che si), web agency, clienti, webmaster in generale (nemmeno la considero come possibilità), enti governativi e associazioni in difesa di… (forse…)? Ma si uscirebbe fuori dal contesto. Così, salto di palo in frasca e ritorno alla “congetturologia su BigTable“.
La BigTable è un’unica grande tabella di dati? Così l’avevano pensata Jeff Dean e “Fellow associati” ma, dati e fatti alla mano sembra più un insieme di gruppi di celle ognuna con le proprie priorità e funzionalità.
Nella BigTable i dati sono archiviati tutti allo stesso modo? Si parte da una pagina web, si prende il contenuto, si etichetta e si assegna alle tabelle… così per il timestamps delle foto… così per una cella o singoli gruppi di celle. Non per tutte le celle.
La BigTable è strutturata in modo tale da tener conto di tutti i brevetti Google creati per l’indicizzazione di contenuti web? La BigTable è Il DataBase Ufficiale e Non Commerciale di Google. Le celle sono settate per caricare dati dai server secondo specifiche utilità. Se si pensa ad una cella come ad un singolo database, va da sé considerare che singole celle o gruppi di celle sono organizzate per rispondere a priorità diverse e per lavorare insieme ad un fine comune.
Anche la BigTable ha un limite? A leggere quello che disse Eric Schmidt nell’Aprile 2006 pare di si. Ma si riferiva alla BigTable o all’hardware su cui poggiava la Grande Tavola? Ma il probelma c’era davvero? Strano che un CEO allerti il Mercato dicendo che se continua così “crolleranno baracca e burattini“. Che differenza c’è tra rumors e dichiarazione ufficiale? Tra frasi come “afferma il CEO di…” e “ho dichiarato che…“?
Basta! La “congetturologia” è troppo complicata!
C’era una volta MySQL
Torno ad un fatto e chiudo il post: A Googly MySQL Cluster Talk – 28 Aprile 2006, postato da Google engEDU. Maggiori informazioni sulla definizione di Cluster? Ce n’è per tutti i gusti!
Di Alessandro Mirri per Storage-Backup.com