Teecno e le Stats

[Giorgiotave]

Lo sappiamo, tutti i motori tengono traccia dei dati dei propri utenti. Per motivi loro e di privacy non li mostrano.

Noi non mostreremo gli IP come è avvenuto in fase di test, ma oscureremo questo dato per rispettare i nostri utenti.

Però creeremo () un database di accessi e query da mostrare al pubblico e creare tools. Questo perchè questi tipi di dati sono molto interessanti e ci possono servire per capire quali risultati non soddisfano l'utente.

Quindi, oltre ad immagazzinare i dati, dobbiamo iniziare a preparare una serie di Tools come:

- la Top Ten del Giorno
- la Top Ten della Settimana
- la Top Ten del Mese
- le query effettuate in un giorno e in un mese
- gli utenti unici collegati
- tools che estrapola tutti i dati in base ad una chiave e dice quante ricerche si sono effettuate
- tools che in base alla chiave estrapola le altre più cercate

Per ora mi fermo perchè so che voi ne avrete più di me.

[Tambu]

a quanto trimmi le tabelle di un database del genere? potenzialmente potrebbe saturarsi in pochi giorni, e cmq secondo me ci sarebbero da subito problemi di performance...

poi se trimmi ci saranno alcune chiavi che sono state cercate ma non escono da una interrogazione.

[Giorgiotave]

Tambu

a quanto trimmi le tabelle di un database del genere? potenzialmente potrebbe saturarsi in pochi giorni, e cmq secondo me ci sarebbero da subito problemi di performance...

poi se trimmi ci saranno alcune chiavi che sono state cercate ma non escono da una interrogazione.

In effetti ieri aveva fatto 400 query, oggi siamo già a 140 query cercate.

Quindi....si, dobbiamo ottimizzare il tutto, che tra un pochino compro un server.

Puoi darci qualche consiglio? (Trimmi ad esempio, che è? Io non sono un programmatore, capiranno gli mette mani al DB )

[Tambu]

scusami. il trim ("taglio") delle tabelle è un valore limite di records possibili, ecceduto il quale i nuovi valori non vengono registrati/vengono eliminati.

Webtrends, tanto per restare nelle statistiche, ha delle tabelle enormi ma da qualche parte devi pur decidere di tagliare, pena il decadimento prestazionale. Ad esempio puoi dirgli di memorizzare le prime 1000 città di provenienza dei visitatori, o le prime 10mila, o le prime 100mila, dipende cosa ti serve, ma se non gli dai un valore-limite lui continuerà a scrivere all'infinito, facendo esplodere il database

Ora, converrai con me che un dato come le città di provenienza dei visitatori di un sito ha un valore relativo. un database con le statistiche di utilizzo di un motore di ricerca non so bene come sia pensato e/o cosa debba esattamente tirare fuori, ma proprio perchè i possibili record sono infiniti quante le queries che vorresti memorizzare, vien da sè che un valore max deve esistere

[Giorgiotave]

AAAAAAAAAAAAAAAAAAA

Capito!

Per ora memorizziamo poche cose, dovremmo implementare un sistema che calcoli anche il sito che ha cliccato nelle serp.

Ovviamente potremmo tagliare le ricerche alla fine del mese e ogni mese creare una nuova tabella.

Poi in visualizzazione per gli utenti, faremo scegliere il periodo in base ad un menù a tendina, così ricerca solo nel DB del mese.

Come la vedi come soluzione? Tu taglieresti a ricerche?

Se usassimo il metodo sopra, i DB li potremmo anche spostare in altri server, senza andare ad intaccare lo stesso DB.

No? O forse io penso più da utente che da programmatore? Capita

[Tambu]

premesso che non ho mai progettato un database - mi baso su quanto letto in ufficio per altri motivi - una tabella a mese penso vada bene SE non farai mai interrogazioni su più mesi. Il discorso che faccio è: è all'inizio ok, ma se prende piede rischia di gonfiarsi molto in poco tempo, anche all'interno di una singola tabella-mese

Tagliare a ricerche significa ottenere un possibile-probabile risultato così:

- ipotizziamo di trimmare a 10mila ricerche
- 100 utenti questo mese cercano la key "tambu", che sta in 9millesima posizione
- la key più cercata del mese è "sesso" ovviamente, con 5000 ricerche fatte e prima posizione
- in mezzo ci sono tutti gli altri 9998 record del database, l'ultimo dei quali ha come valore 13 ricerche.

il penultimo giorno del mese arriva un utente e cerca "tambuweb": 1 sola ricerca, ovviamente legata a tambu.

con 1 sola ricerca si è fuori dal valoreMAX di trim, cioè quella query manco ci entra nel database.
l'utente usa il tool che chiedi nell'ultimo punto della tua lista, scrive TAMBUWEB sicuroe speranzoso di trovare voci corrispondenti ma il tool gli ritorna "spiacente, quella query non esiste" e lui va in confusione perchè invece l'ha appena digitata nel motore di ricerca, ma è stata trimmata.

[Giorgiotave]

Capito. ottimo questo sistema.

Interverrà a risponderti ed a implementarlo/migliorarlo chi è in grado

[tonyx]

L'idea di Tambu non è male, ma non vorrei che ci stiamo preoccupando troppo inutilmente, ovvero è sempre meglio valutare le possibili conseguenze negative di un algoritmo prima che queste si verifichino, però, da esperienze passate, usando gli indici e magari dividendo le tabelle di ricerca, come indicavi tu no ndovrebbero esserci problemi a gestire una grossa quantità di dati.
Questo anche perchè ogni record è costituito da pochi dati: Ricerca, Ip, Dataora, Browser utilizzato (opzionale)

C'è solo un modo per capire come agire, monitorare le prestazioni del server.
Qualsiasi cosa implementeremo la renderemo pubblica ovviamente.
Ciao
Tony.

[Tambu]

capito! ok, e complimenti per la moto, se non è un avatar campato per aria

[Giorgiotave]

Tambu

capito! ok, e complimenti per la moto, se non è un avatar campato per aria

http://tony-ischia.blogspot.com/2006...guna-seca.html

[tonyx]

Grazie per i complimenti