Dopo gli “Opening Remarks” in cui Bill Graziano ha annunciato le prossime date e location della conferenza Europea e del prossimo PASS Summit:
- European PASS Summit 2010: 21 – 23 Aprile – Neuss (Dusserldorf)
- PASS Summit 2010: 8 – 11 Novembre 2010 – Seattle
E’ poi il turno di una pallosissima sessione dello sponsor, che vi risparmio volentieri.
Bene, passata questa parte è ora di David DeWitt, Techinal Fellow di Microsoft. La keynote sarà molto molto tecnica, bene. David è un ricercatore nel campo del parallelismo, e gestisce i Jim May System Labs in Madison. La sua keynote sarà tutta incentrata sulle ricerche in campo di scalabilità dei database.
Il problema più grosso di questi anni è che la tecnologia è migliorata parecchio, aumentando di molto le performance di cpu e memoria…ma non di altrettanto le performance dei dischi. E proprio le performance dei dischi sono oggi il collo di bottiglia maggiore. Per poter sfruttarre appieno la potenza dei processori è necessario avere tantissimi dischi molto piccoli (o semivuoti) per poter parallelizzarne l’accesso e quindi sostenere la velocità di elaborazione delle moderne CPU.
David sta snoccilando una serie di dati che dimostrano in modo evidente come velocità di accesso e banda disponibile, siano oggi i punti dolenti delle soluzioni di storage.
Si passa ora a parlare di CPU. L’accesso alla memoria oggi è molto più lento (dovuto alla complessità maggiore dei sistemi) e quindi da qui la necessità di avere ampie cache L1 ed L2, che sono quelle che fanno la differenza e devono quindi essere prese in grande considerazione al momento dell’acquisto di una CPU.
Ci sono cmq problemi anche con l’accesso alla cache L1 ed L2. Tali problemi sono la maggior sorgenti di tempi morti in cui la CPU non può fare nulla se non aspettare che i dati vengano letti dalla cache.
I motivi di questi problemi (cache-misses) sono dovuti anche a come le applicazioni – in particolare i database – lavorano. Questo comporta che se i dati non sono nella cache L2, ci possono volere fino a 200 cicli di cpu per recuperare i dati dalla memoria.
L’idea, per i database, è quella di non memorizzare più in dati riga per riga (con quindi tutti i valori di tutte le colonne per ogni riga), ma di passare ad un “column store”. In pratica i valori di tutte le righe di una colonna vengono memorizzate in un unico file.
La tabelle vengono quindi memorizzate non più riga per riga, ma colonna per colonna. Ovviamente questo è un cambiamento dello storage, e pertanto non cambia nulla per l’utilizzatore finale, dato che per il principio della Physical data independence, il modo in cui sono memorizzati i dati non tocca per nulla il modo in cui gli stessi sono utilizzati. Continueremo ad avere tabelle, ed a utilizzare SQL, nessuna nuova “diavoleria” da imparare :-)
Questo nuovo approcio è da solo in grado di migliorare di 7 volte le performance di un RDBMS. Il tutto in modo completamente trasparente per l’utente finale, senza dover cambiare H/W, “semplicemente” ottimizzandone l’utilizzo.
Se a questa possibilità di aggiunge anche la possibilità di comprimere di dati, il miglioramente arriva anche a 30 volte!
Tutto questo, per funzionare correttamente, ha solo bisogno di una cosa: che non si usi mai SELECT * FROM …? Il beneficio, infatti, deriva dal leggere solamente le colonne che servono, quindi se si prendono sempre tutte le colonne, non c’è alcun aumento di performance. Un motivo in più per non usare mai SELECT * FROM, ma prendere solamente le colonne che servono.
Ci sono ovviamente anche dei contro. Le modifiche ai dati sono molto più lente. Tale tecnologia è quindi particolarmente per Datawarehouse, Decision Support System ed in generale tutte quelle necessità di lettura molto veloce in cui ci sono solamente un numero limitato di scritture (o non ci sono proprio).
David ci parla ora delle possibili implementazioni fisiche del Column Storage. Attulmente ce ne sono tre: DSM, Dense B-Tree, Positional Representation.
I dati memorizzati in questo modo si prestano molto bene ad essere compressi. Questo, unitamente al fatto che i dischi sono molto capienti, permette di memorizzati i dati in diverse copie, ordinati però in modo diversi, in modo da poter soddisfare diverse esigenze fornendo sempre le massime performance.
Interessante vedere come gli studi fatti hanno già traovato applicazioni nelle realtà: ad esempio le tecniche di compressione usate in SQL Server 2008 arrivano da qui. Sempre da queste ricercare arriva la tecnologia VertiPaq, alla base di PowerPivot.
La discussione ora passa sulle strategie di ottimizzazione delle query: nel caso di column-storage le problematiche sono opposte a quelle della memorizzazione tradizionale per righe, quindi c’è la necessità di introdurre nuovi operatori come quello di materializzazione, che lavora in modo opposto a quello di proiezione.
Keynote finita. Bellissima! Ho anche avuto la possibilità di scambiare quattro chiacchere con David circa la moda “NoSql”. Quando gli ho esposto la situazione, di cui lui non era a conoscenza, ha sgranato gli occhi dicendomi “Are they really saying that?!?!?!?”. Ha poi anche acconsentito a farmi avere le slide cosi da poterle usare al prossimo evento UGISS cosi di cui parlerò tra poco.