GTStats: progettazione preliminare del database

gik25

GTStats: progettazione preliminare del database

Partiamo da considerazioni su un sistema esistente, al fine di capire come migliorarlo.

PHPStats ha dei problemi di efficienza dovuti al numero di operazioni su database.

Se sbaglio, può succedere, correggetemi senza timori

PHPStats salva la configurazione su db
Quindi una prima query mysql serve solo a leggere la configurazione. Un include da file è in linea teorica molto più veloce visto che i db hanno requisiti di sicurezza e atomicità che li rendono più lenti. Senza considerare il caching del file in ram e il ritardo dovuto al trasferimento in rete se il DB è presente su un altro server. Secondo un test da me effettuato, per scrivere centinaia di migliaia di record INSERT mysql può impiegare molte ore. Per scrivere le stesse info su file basta una frazione di quel tempo.
PHPStats salva nella tabella referer il mese come stringa. Un intero di 10 cifre salvato come stringa occupa 10 byte, salvato come int ne occupa 2 o 4 a seconda della precisione.
PHPStats non usa indici. In effetti effettua quasi solo inserimenti. Bisogna verificare con test se si tratta di una scelta ottimale.
Bisogna testare INSERT contro INSERT DELAYED e decidere quando passare da uno all'altro.
Risparmiare spazio è un must. La velocità di ina query MySQL è proporzionale alle dimensioni, e in ogni caso non è carino sprecare spazio sul db
Come viene salvato il title della pagina nella tabella pages? Si può passare il parametro tramite js?
Studiare Adsense è indispensabile, deve essere una feature inclusa
Tabella detail =

Visitor id:
9noYQgY7Ji8UkV07Sijn7GWRtKvEZy sono 30 caratteri cioè più di 931.322.574.615.478.515.625.000.000.000.000.000.000.000.000.000.000 utenti monitorabili
Poi varchar(50) quando la dimensione è fissa, è 30 e sarebbe meglio un int.

Basta un bigint, o qualsiasi valore a 8 byte (8 char se necessario).

gik25

Tutto è salvato in varchar mentre praticamente nulla dovrebbe esserlo... Char si usa se la dimensione è fissa, ma valori come l'ip possono essere salvati come numeri, gli agent sono standard vanno sostituiti con un intero hard coded, se la ricerca non lo trova scrive in un file hash(id) = "$useragent". Hash perchè così ogni sistema PHPStats userà gli stessi id per i nuovi useragent. Risoluzione deve essere un int hard coded. Titolo page mi chiedo se serva salvarlo... Colori tyniint unsigned di 2 invece che varchar(10). "http://www." sarà sostituito con un carattere singolo magari non url safe (che quindi non potrà mai comparire in un url) accorciando referer e current page. Il dominio sarà salvato come int e sarà hard coded in un file scritto da PHP stesso.

Lang occupa poco, comunque si potrebbe metterlo sempre come int.

Utilizzare tutto hard coded serve a ridurre al minimo il numero di query al DB.

**visitor_id **varchar(50)
**ip **varchar(15)
**host **varchar(50)
**agent **varchar(255)
**lang **varchar(10)
**date **int(10)
**referer **varchar(255)
**currentPage **varchar(255)
**reso **varchar(10)
**colo **varchar(10)
**titlePage **varchar(255)

gik25

Poi, se la memoria non mi inganna, PHP stats fa dei controlli prima di ogni scrittura, del tipo: se le righe sono 1000 cancellane una. Lo svuotamento se frequente dovrebbe essere fatto con truncate. L'ottimizzazione va fatta di notte, e solo se ci sono cancellazioni, altrimenti è inutile.

In pratica per fare una query ne va ad eseguire cinque. Chiaramente non è accettabile.

Si devono prevedere simil cronjob casuali (ogni tot utente uno scatena il controllo, ma questo si fa con ogni utente ha la probabilità 1/tot di scatenare il controllo).