Newsgroup: it.comp.www.php
Titolo: Mysql e parecchi dati da visualizzare

Ho la necessita' di gestire alcune tabelle mysql non enormi, ma comuque con un bel numero di righe e visualizzare i risultati in una webapp.
 
Le tabelle sono tabelle di log dell'attivita' dell'utente nel sito e la sua attivita' attorno ai video (quanti ne ha visti, dove, come per che durata ecc).
 
Le tabelle (3) hanno 2 ai 4 milioni di record circa l'una, ma potranno solamente incrementare, essendo log.
 
Il "problema" e' che i risultati devono essere filtrati secondo alcuni criteri, data, categoria e tipologia  del video, ma questi non sono realmente un problema perche' essendo valori che conosco posso gestirli, il problema e' la ricerca per keyword che mi sta facendo impazzire.
 
Attualmente la soluzione alla quale sono giunto e' questa:
-Con un cron leggo le tabelle enormi di log e ficco i dati dentro a tabelle piccole e ordinate ad esempio per la ricerca "Categoria Pippo - Video Professionale" creo la tabella 
'cache_pippo' con i campi:
GIORNO - VISUALIZZAZIONI - TIPO - VIDEOID
5/9          250             1       22
5/10         250             0       22
5/10         20              1       25
 
Questo mi crea parecchie tabelle, ma chissenefrega perche' sono superveloci.
Il problema e' la gestione del campo keyword perche' e' un testo libero e non lo posso "preparare".
 
Se creo le tabelle di cache aggiungendolo
GIORNO - VISUALIZZAZIONI - TIPO - VIDEOID - KEYFIELD
5/9          250             1       22   -  Pippo
5/10         250             0       22   -  Pippo
5/10         20              1       25   -  Sempronio
 
Se ricerco come FULLTEXT per le chiavi corte rischio di non avere risultati, se cerco con like '%...%' le query impegano troppo tempo. In verita' non e' troppo in assoluto ma impiegano fino a 2 secs e per un interfaccia web si traduce in parecchio tempo per l'utente.
 
Avete qualche idea per l'approccio da avere? 
(ho cercato ma non ho trovato alcunche' se non come ottimizzare le query e gli indici, cosa che ho fatto)
 
Soprattuto perche' in futuro vogliono matchare le info dell'utente che ha visto il video, ad esempio quanti video sono stati visti da Milano il 5 settembre.
 
Grazie delle idee
 
J.


quando si parla di datawarehouse in genere si fa riferimento a report o 
a semi-elaborati che di solito sono operazioni batch, quindi il tuo 
approccio di ridurre la mole di informazioni ed organizzarle per poterle 
gestire in modo agevole e fare del data-mining � corretto. � l'approccio 
"real-time" che vuoi dare che � essenzialmente non adatto.
quello che in genere viene fatto � quello di lanciare delle procedure 
che generano report e/o tabelle temporanee che vengono successivamente 
consultati.
un approccio che di solito � usato � quello di far scegliere i parametri 
all'utente tramite un interfaccia e far sottomettere il relativo job in 
schedulazione e avvertire tramite mail quando l'elaborato � consultabile 
tramite pdf/excel/cvs/quel vuoi o tramite un'altra interfaccia che 
consulta le tabelle temporanee che contengono i dati elaborati.
 
Anche perch� oggi la tua query impiega 2 sec, ma domani magari non ti 
limiti solo ad estrarre ma anche a fare calcoli/aggregazioni/ecc e 
potrebbero volercene decine se non centinaia di secondi.
 
 
Ciao

Se ricerco come FULLTEXT
 
A parte quanto detto da bramante, considera la possibilita' di avere le
keyword (o le stringhe) in una tabella separata, ed usare un dizionario
controllato.
 
A quel punto la ricerca per keyword puo' avvenire cosi':
 
	- l'utente inizia a digitare una keyword
	- via AJAX controlli sul dizionario, e volendo gli fai anche
	  l'autocomplete
	- alla fine se nel dizionario non c'e' la ignori o fai fallire
	  la ricerca
        - se no ti trovi con un insieme [...] di ID di keyword
	- e le ricerchi dentro
		video_has_keyword(video_id, keyword_id)
	- e trovi un numero molto piu' ridotto di video_id validi.
Leonardo
 
-- 
What would'st thou do, my squire so gay, that rides beside my reine
Were ye Glenallan's Earl this tide, and I were Roland Cheyne?
To turn the rein were sin and shame, to fight were wondrous peril:
What would ye do now, Roland Cheyne, were ye Glenallan's Earl?

 
 
 
Alla fine abbiamo creato tante tabelle quante sono le varie tipologie di report.
 
La tabella che viene interrogata per creare il report e' una tabellona unica creata dalle join di tutte le tabelle delle statistiche da un cron che aggiorna le tabelle ogni 5 minuti.
 
Abbiamo indici per i campi di ricerca ed ordinamento.
 
La tabella finale la ho testata con circa 20milioni di record (circa 15giga) e impiega circa da 2 a 5 secondi per essere eseguita, quindi piu' che buono perche' dalla seconda volta e' pressoche' istantanea.
 
Le uniche operazioni che ci servono sum e count ed a quanto pare mysql e' veloce nel gestire tabelle di queste grandezze che saranno bene o male le dimensioni che avremo in produzione
 
 
J.

 
 
 
Ottima idea, come posso creare un dizionario sensato?
Magari analizzando tutti i nomi del video e creando le chiavi per ogni parola?
 
Esempio:
 
Titolo 1: "New Experience"
 
2 chiavi: New + Experience
Poi aggiungere anche:
    Exp + Expe + Exper + Experi + Experie + Experien + Experienc
 
Chiavi sotto le 3 lettere non mi interessano
 
J.
 
 
 

Magari analizzando tutti i nomi del video e creando le chiavi per ogni parola?
 
Esatto, ma nel testo metti solo le parole intere.
 
Titolo "New Experience"
 
	-> INSERT IGNORE INTO Keywords (value) VALUE ('New');
	-> INSERT INTO film_has_keyword ( id_film, id_keyword )
              SELECT @film_id, id FROM Keywords WHERE value = 'New';
 
	e ripeti per Experience.
 
Poi il JSON che ritorna fuori dall'AJAX di autocompletamento fa una ricerca
per LIKE 'Exp%' ('%Exp%' non ha molto senso).
 
La cosa un po' piu' complessa e' fare una ricerca per tutte le keyword, nel
senso "trovami i film che contengono TUTTE queste keyword".
