[MySQL] Consigli di stile / performance - come trattare le tabelle di log "poderose"

[luck]

Ciao ragazzi, pianino pianino, a piccoli passi sto migrando a MySQL.
Insieme alla migrazione mi trovo davanti a quesiti per cercare di far rimanere snello il db e non appesantirlo con tabelle e dati inutili.
un esempio è questo: nelle mie pagine ho un frame che fa un refresh ogni 30 secondi. ad ogni refresh salva una riga nel db con alcune informazioni sull'utente (pagine, ora, nomeutente e altri orpelli vari) che mi servono per:
- mostrare agli altri utenti chi è online in un dato momento
- loggare i comportamenti degli utenti e la loro effettiva presenza online (i dati poi vengono mangiati da altri software di analisi)
Ovvio che con un refresh automatico ogni 30 secondi la tabella assume proporzioni interessanti anche in poco tempo.

E' influente ai fini delle performance spostare periodicamente i dati di questa tabella in un altra tabella dello stesso DB "storica"? oppure meglio risparmiarsi la fatica e periodicamente esportare (e cancellare dal db) i dati vecchi in un semplice csv nel server?

qual'è secondo voi il modo migliore?
grazie mille
ciao!

[Santino83_02]

mah ti dirò la mia tabella di log allo stato attuale ha 415.403 records, e non mi pare di avere problemi particolari. stiamo cmq pensando tra un pò di fare uno script che cancelli i logs piu vecchi di una certa data. Se i tuoi programmi di analisi non richiedono lo storico completo, cancella quelli piu vecchi. altrimenti li sposti in un altro database in una tabella di storico e li usi da li i dati

[luck]

grazie infinite

l'analisi lavora su tutto lo storico, i dati non li posso cancellare (quelli dei 30 secondi sono solo alcuni dei dati che utilizzo, ovviamente)

quindi mi viene da concludere che: spostare in un altra tabella dello stesso db non giova a nulla (sulla tabella 'originale' ogni 30 secondi esegue anche delle query di estrazione - spostando i record vecchi su un altra tabella dello stesso db non gioverebbe a nulla?)

l'unico giovamento l'avrei esportando totalmente i dati obsoleti?

[Santino83_02]

Originariamente inviato da luck
grazie infinite

l'analisi lavora su tutto lo storico, i dati non li posso cancellare (quelli dei 30 secondi sono solo alcuni dei dati che utilizzo, ovviamente)

quindi mi viene da concludere che: spostare in un altra tabella dello stesso db non giova a nulla (sulla tabella 'originale' ogni 30 secondi esegue anche delle query di estrazione - spostando i record vecchi su un altra tabella dello stesso db non gioverebbe a nulla?)

l'unico giovamento l'avrei esportando totalmente i dati obsoleti?

mah dipende effettivamente dal numero di logs che hai.. quelli piu vecchi li sposterei in un altro db e poi istruirei i programmi di analisi ad utilitzzare i due database.

[Roby_72]

Io credo che un conto è la memorizzazione del log un altro le analisi che fai su tutti i dati.
Di per sé scrivere una riga su una tabella per quanto questa sia già popolosa comporta poco dispendio.
Ben maggiore invece è il dispendio facendo query su una mole enorme di dati per le analisi.
A mio avviso queste dovresti farle su un db separato con tutti i dati aggiornati a qualche giorno o settimana prima, comunque non "live".

Roby

[luck]

Originariamente inviato da Roby_72
Di per sé scrivere una riga su una tabella per quanto questa sia già popolosa comporta poco dispendio.

grazie Roby, questo è in parte quello che volevo sapere...
ma l'altra metà è questa: se io devo fare una query da una tabella che estrapoli i record dove la data è compresa fra due periodi in esame (ad esempio), immagino che sia diversa le performance fra eseguirla su una tabella che contiene 1.000 o 1.000.000 di record, no?
ma la differenza di performance è abbastanza per pensare di strutturare un meccanismo di salvataggio dei dati storici esternamente al db?
se si, salvando 900.000 record in una tabella di storicizzazione internamente al db, la query eventuale sui 1.000 che rimangono nella tabella originale sarebbe veloce come se nel db avessi 1.000 record totali? dal momento che non "tocco" nell'interrogazione neanche i 900.000 rimanenti...

Per le analisi non è un problema, non vengono effettuate query sul mysql originale, ma vengono estrapolati i dati in una warehouse e da lì magheggiati, è solo per far capire che comunque i dati vecchi mi servono. Il problema è dove metterli, e se conviene spostarli.

ciao, grazie ragazzi.

[optime]

tu quindi il log lo scrivi soltanto? scrivilo in un terzo db (sempre mySQL), così non influenzi le performances del db principale

[luck]

Originariamente inviato da optime
tu quindi il log lo scrivi soltanto? scrivilo in un terzo db (sempre mySQL), così non influenzi le performances del db principale

no, loggo e leggo i dati più recenti (nelle ASP giornalieri)

[optime]

allora puoi scrivere in due posti e nel db principale lanciare quotidianamente uno script di housekeeping che ti lasci SOLO i dati che tu definisci 'più recenti'

[luck]

quindi al di là del dilemma se:
meglio scrivere due query di inserimento, piuttosto che schedulare (di notte) una query di spostamento

mi confermi anche tu "ottimo" Optime
che meglio non tenere il db principale zeppo di dati storici...

ciao grazie...