Decadimento radioattivo, backup e argomenti caldi
Le sostanze radioattive sono instabili e hanno la tendenza a trasformarsi in altri elementi. Nella trasformazione emettono radiazioni ionizzanti, capaci di interferire con l'ambiente circostante in vario modo. Tra l'altro, possono introdurre errori nella fase di riproduzione cellulare, aumentando la probabilità di tumori, quindi la prossima volta che vi offrono una barretta di uranio caramellata pensateci due volte prima di accettare. E se viene paventata la costruzione di una centrale nucleare dietro casa vostra, con Scajola che gestisce gli appalti e la Camorra che si occupa dello smaltimento delle scorie, cominciate a informarvi sulle opportunità di lavoro in un altro paese.
La tendenza alla trasformazione degli atomi instabili segue regole quantitative semplici, che si possono esemplificare così:
- si parte da un chilo di sostanza radioattiva (chiamiamola Developio), che per decadimento si trasforma in altro (diciamo Consultonio). Facciamo partire il cronometro;
- quando mezzo chilo si è trasformato, annotate il parziale T, tenete il mezzo chilo di Developio e buttate il Consultonio (che è inerte e servirebbe al più come fermacarte);
- dopo che sarà passato un altro intervallo T, saranno rimasti solo 250g di Developio;
- dopo altro T, ne avrete solo 125g
La quantità di Developio rimasto segue una legge esponenziale (1/2, 1/4, 1/8, 1/16 etc.) e il tempo T si chiama tempo di dimezzamento. Più instabile è l'elemento, minore è il tempo di dimezzamento e più veloce sarà la sua trasformazione.
Nota: è costante il tempo di dimezzamento, ma anche quello di riduzione di una qualsiasi altra proporzione. Ad esempio il tempo di riduzione a 1/4 è 2 T e il tempo di riduzione del 10% è circa 0,152 T.
Se da esseri umani le questioni fisiche con risvolti ambientali e energetici ci stanno a cuore (e a quorum), lo sviluppatore che è in noi riesce a usare l'idea del decadimento per risolvere alcuni problemi in maniera semplice.
Decadimento dei backup
Un semplice sistema di backup può essere implementato copiando periodicamente i dati. Così facendo avremo:
copia-2011-01-01 copia-2011-01-02 ... copia-2011-01-31 copia-2011-02-01 ...e così via.
L'implementazione è banale (un cron job con un tar) e possiamo risalire alla versione dei dati di qualsiasi giorno da quando abbiamo cominciato il backup. Lo svantaggio è che l'uso di spazio cresce nel tempo ed è destinato a superare lo spazio disponibile.
Un trucco per tenere costante lo spazio utilizzato, privilegiando i backup recenti ma tenendone anche di vecchi, è far decadere i backup con un certo tempo di dimezzamento. A intervalli regolari, si cancella una proporzione fissa dei backup (ad esempio 1 su 10). In questo modo, backup più vecchi avranno più probabilità di essere stati cancellati, avendo subito più fasi di decimazione.
E' anche possibile calcolare il numero totale di backup a regime. Se ne viene fatto uno al giorno e ne vengono cancellati 1 su N ogni T giorni, si avrà all'incirca tot/N = T ossia il numero di backup a regime sarà di circa N * T. Ad esempio, cancellandone un decimo ogni settimana, si conserveranno in tutto una settantina di backup.
Una simulazione eseguita su 1 anno con decimazione settimanale dà l'età seguente per i backup (in giorni):
281 213 201 189 185 174 159 131 129 124 123 118 111 107 103 92 89 88 86 78 77 74 71 70 64 60 58 57 55 52 51 49 47 43 41 40 38 36 35 33 32 30 28 26 25 23 22 21 20 18 17 14 13 12 11 10 9 7 6 5 3 2 1 0Il più vecchio è di quasi 10 mesi e per le ultime due settimane si hanno quasi tutti i backup giornalieri.
La situazione non cambia di molto allungando il tempo della simulazione a 100 anni:
278 230 186 176 170 153 147 137 135 119 115 111 108 107 98 95 92 81 80 79 78 77 74 67 65 62 61 60 55 53 52 51 48 45 42 41 40 39 38 36 35 31 30 29 28 27 25 24 23 22 19 18 17 16 15 14 13 12 11 9 8 7 6 5 4 3 2 1 0In appendice è riportato il programmino perl usato per la simulazione, in cui si possono provare diversi parametri.
Argomenti caldi
Un servizio interessante per un sito di attualità è la visualizzazione della lista delle pagine che riscuotono più interesse.
Una implementazione potrebbe associare ad ogni pagina un contatore incrementato ad ogni visita. Le pagine col contatore più alto vanno in testa alla lista. Il problema è che questo approccio non tiene conto dell'andamento delle visite nel tempo. Una pagina che ha avuto 10.000 visite una volta un anno fa vale quanto una che ne ha avute 100 al giorno per gli ultimi 100 giorni e più di una che ne ha avute 8.000 ieri. Per tenere conto di questo si potrebbe salvare per ogni visita anche il giorno in cui è avvenuta e considerare solo le visite degli ultimi 7 giorni, ad esempio. Oppure avere per ogni pagina un contatore per gli ultimi 7 giorni e scalare i contatori ogni giorno.
Un approccio più elegante è quello di usare l'idea di decadimento per il valore delle visite. Ogni pagina ha associato un singolo contatore, che viene incrementato per ogni visita e periodicamente viene ridotto di un certo fattore. In questo modo le visite più vecchie avranno un certo effetto nel tempo, sempre decrescente. Se la riduzione è del 10% al giorno, il tempo di dimezzamento è di circa una settimana, che vuol dire che per superare una notizia attuale, quella di una settimana fa deve aver avuto almeno il doppio delle visite.
Appendice
Il programmino perl per simulare l'andamento dei backup nel tempo è il seguente:
$T = 7; # Frequenza delle cancellazioni
$N = 10; # Proporzione delle cancellazioni
$MaxT = 36500; # Tempo totale della simulazione
@b = ();
for $d ( 1..$MaxT ) {
push @b, $d;
if ( $d % $T == 0 ) {
@nb = ();
$m = int( rand( $N ) );
for ( 0 .. $#b ) {
push @nb, $b[$_] unless $_ % $N == $m;
}
@b = @nb;
}
}
print join ( "-", map { $MaxT - $_ } @b ), "\n";