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.

@Tambu said:

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 :D)

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

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

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.

Capito. ottimo questo sistema.

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

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.

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

@Tambu said:

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

http://tony-ischia.blogspot.com/2006/05/yamaha-r1-2006-laguna-seca.html

Grazie per i complimenti