altre destinazioni

vedi anche

ultimi post

ultimi commenti

tag principali

categorie

archivi

powered by

  • WPFrontman + WP

friends

copyright

  • © 2004-2011
    Ludovico Magnocavallo
    tutti i diritti riservati

Yes, I am a data geek / 2

24 maggio 2010

9 commenti

tag

categorie

Mi ero ripromesso di raccontare un po’ delle esperienze tecniche fatte con Blogbabel, poi i mesi passano e non sembra mai essere il momento buono, così ho deciso di buttare giù qualche appunto sperando di trovare nei prossimi giorni le motivazioni per arricchirli ed espanderli.

Se dovessi scegliere una sola delle tante cose imparate in questi ultimi anni, non avrei molti dubbi nell’indicare la dimestichezza con le basi dati relazionali. Non solo perchè giocare con i dati mi diverte, ma anche perchè credo sia un aspetto spesso trascurato da chi sviluppa, e di importanza fondamentale per le prestazioni e la congruenza delle informazioni presentate.

Il mio percorso in questo senso con BlogBabel è stato forzato da due condizioni: le risorse hardware limitate (per un anno e mezzo BlogBabel ha convissuto su un vecchio Celeron 900 con poca RAM e dischi lenti insieme ad altre applicazioni), e la mole di dati che cresceva a ritmo esponenziale (quando ho passato a Liquida, il db era già maggiore di 50Gb).

Le ottimizzazioni fatte al db hanno quindi seguito fasi successive: completato un ciclo, si rendeva necessario dopo poco tempo passare a un livello di ottimizzazione superiore per non dover buttare altro hardware dentro al progetto. Semplificando, le fasi di ottimizzazione che ho attraversato sono state:

  • analisi delle query e ottimizzazione degli indici
  • denormalizzazione di alcuni campi e tabelle, per ottimizzare filtri e ordinamento nei join
  • calcolo periodico (batch) dei dati aggregati più importanti
  • creazione di trigger per l’alimentazione online di aggregati
  • spostamento dei trigger su una coda di eventi processata da programmi esterni
  • utilizzo di più livelli di aggregati ibridi batch e online

L’insegnamento principale che ho tratto da questo lungo e laborioso processo è che non tutti i dati devono essere sempre consistenti: molte informazioni (e spesso sono quelle più onerose da generare) possono avere fluttuazioni nella loro consistenza rispetto al resto dei dati, senza per questo avere un impatto significativo sull’usabilità o sull’esperienza utente; quello che importa è che siano “periodicamente consistenti”.

Da cui discende un altro aspetto fondamentale: anche se a prima vista elaborare alcuni tipi di dati o reagire a certi eventi direttamente all’interno del database, sembra l’operazione più semplice e lineare, è in realtà il modo migliore per incrementarne in maniera esponenziale la complessità e i rischi.

Nei prossimi giorni vedrò di trovare il tempo per entrare un po’ nei dettagli di questi argomenti, sempre che a qualcuno interessi.

9 commenti

  • xlthlx
    24 maggio 2010 #

    A me interesserebbe molto.

  • francesco
    24 maggio 2010 #

    A me interessa assai (e non è il mio pane ;-))

  • Taifu
    24 maggio 2010 #

    A me, a me :-)

  • theo
    25 maggio 2010 #

    "sempre che a qualcuno interessi"... LOL ;)

  • Enrica Garzilli
    26 maggio 2010 #

    e perché non dovrebbe interessare quello che scrive uno dei più bravi programmatori (del mondo)?

  • ludo
    26 maggio 2010 #

    No, guarda che bravi sono programmatori come antirez, io sono solo uno che smanetta.

  • theo
    26 maggio 2010 #

    eheh, ti voglio bene :D

  • Enrica Garzilli
    26 maggio 2010 #

    ludo, se il programmatore di Kalacanis ti ha chiamato per risolvere un loro problemuccio, anni fa, significa che solo smanettatore non sei, a mio parere.

    Poi non so.

  • Dario Salvelli
    26 maggio 2010 #

    Kalacanis?? Ma chi, quello che perse tutti i dati degli utenti????

    Scherzi a parte a me interessa molto.