Newsgroup: it.lavoro.professioni.webmaster
Titolo: Data mining

Ciao a tutti,
   da un paio di giorni abbiamo iniziato a vedere scricchiolamente nella nostra architettura di data mining.
L'architettura e' basata su MYSQL.
 
Ad ogni click che avviene creiamo un log per l'evento e dove questo e' avvenuto, poi con un cron leggiamo i log e creaiamo una serie di tabelle che vengono usate per mostrare tutti i dati tramite un frontend in php.
Fin qui tutto bene.
 
Il problema e' che abbiamo notato che la parte "cron", lettura dei dati raw, inserimento dei dati nelle tabelle per il frontend sta diventando mostruosamente lento ed utilizza la CPU del server MySql al 100%.
 
A livello software stiamo cercando di ottimizzare ogni query, ma alcune join enormi le dobbiam tenere.
quando logghiamo l'evento non vogliamo veramente raffinare i dati perche' essendo frontend vogliam tenere il logging il piu' svelto possibile.
 
Ho anche pensato di usare un DB(server) diverso per gestire la parte di logging/analisi e mining.
 
Avete altri suggerimenti?
 
 
Grazie 
 
J
 

Avete altri suggerimenti?
 
Senza avere i dettagli della struttura di front-end, e di cosa fa, non saprei
nemmeno dirti quanto sia una buona idea dividere i server.
 
Proverei, ma e' una impresa abbastanza "importante", a indagare una possibile
migrazione su una diversa architettura, per esempio NoSQL o VoltDB.
 
Nel mentre, controlla bene con un query analyzer, per vedere se sia possibile
fare qualche piccola miglioria.
 
Leonardo
 
-- 
Were I Glenallan's Earl this tide, and were you Roland Cheyne,
My spur would be in my horse's side, the bridle upon his mane.
If they hae twenty thousand blades and we twice ten times ten,
Yet they hae but their tartan plaids, and we're mail-clad men.

 
 
Infatti sara' il prossimo passo da fare, strutturare il tutto in maniera diversa.
Alla fine della fiera potremmo anche solo incrementare la potenza dei db mysql, ma una soluzione tecnologica adatta sicuramente a conti fatti costera' molto meno nel futuro.
 
Ma tu intendi usare il NoSql per la parte di analisi e log? 
 
Si potrebbe usare il NoSql ma salvare molte piu' informazione di quelle che vengono salvate ora, quindi in fase di analisi non dobbiamo cercare nulla (o comunque meno informazioni) nel Db MySql di frontend.
Conosci link a infrastutture che posso guardare come esempio? 
O darmi qualche parola chiave per cercare, l'unica infrastruttura di esempio che ho trovato e' quella di AWS.


Conosci link a infrastutture che posso guardare come esempio?
 
Te la puoi fare anche in casa. Hadoop o qualcosa di simile; senza sapere
esattamente che tipo di lavoro (e di mining!) ci vuoi fare, e' difficile
dare una risposta che non stia "sulle generali".


 Conosci link a infrastutture che posso guardare come esempio?
 
puoi dare una occhiata a questo progetto: 
http://code.google.com/p/enterprise-log-search-and-archive/
 
 
non credo vada bene per te ma � velocissimo a "ingerire" le linee di log 
e poi puoi rileggerle e catalogarle con calma...

 e poi puoi rileggerle e catalogarle con calma...
 
Questo e' interessante perche' permetterebbe di scrivere log un po' piu' elaborati e salvare tempo nel mining, che e' quello che attualmente sta uccidendoci.
 
Gli ingegneri di AWS mi hanno suggerito di integrare DynamoDB e Elastic Map Reduce (Hadoop/Hive) perche' EMR e' gia' di suo integrato con DynamoDB.
 
Entro fine settimana avro' chiara la loro idea, poi postero' la loro idea perche' il data mining e logging sono cmq attivita' interessanti
 
J

 J
 
Quello che mi hanno suggerito e' [sistema batch]:
 
- Loggare tutte le informazioni possibili, meglio avere roba in piu' che non averne
- Log in locale (MongoDb o Redis) (Abbiamo diversi server ed usiamo autoscaling quindi i server si creano e distruggono in modo automatico)
- Spedire i log in un bucket S3 ogni 2 ore (noi faremo le analisi/report ogni 2 ore)
- usare EMR (hadoop+hive) per l'analisi [Tenere il cluster spento ed accenderlo solo durante l'elaborazione]
- Push dei risultati S3 (o DB)
- Mandare i log vecchi (piu' vecchi di un mese per esempio) da S3 a Glacier dove il costo di storage e' 1/8 di S3
 
Se invece si vuol creare un sistema di logging in tempo reale (chiaro non e' reale ma siamo intorno a qualche minuto di latency):
- Log in locale
- Spedire il log in SQS (sitema di coda) e S3 (backup)
- Cluster EC2 che si attiva quando c'e' almeno 1 messaggio in coda e autoscala se la coda cresce troppo
- Push dei risultati S3 (o DB)
- Mandare i log vecchi da S3 a Glacier
 
 
 
J.