2010-07-16 4 views
7

Sto cercando il modo di tenere traccia degli eventi in un'applicazione django (gli eventi sarebbero in genere i clic associati a un ID utente univoco specifico).Consigli per i meccanismi di tracciamento dei clic/eventi (pitone, django, sedano, mongo ecc.)

Questi eventi contengono essenzialmente un tipo di evento come "clic" e quindi ogni evento di clic verrebbe assegnato a un ID univoco (molti eventi possono andare a un ID) e ogni evento avrebbe un set di dati che include elementi come referrer ecc. ...

Ho provato il mixpanel, ma per ora l'API di dati che offrono sembra troppo limitante in quanto non riesco a trovare un modo per estrarre tutti i miei dati da un ID univoco (a parte l'evento si).

Sto cercando di usare django-eventracker, ma sono curioso di pensare a qualcun altro sul modo migliore per farlo. Mongo o CouchDb sembrano un'ottima scelta qui, ma il sedano/coniglio sembra davvero attraente con mongo. Pompare questi eventi nelle applicazioni esistenti db sembra limitante a questo punto.

In ogni modo, questo è solo un filo di vedere ciò che gli altri pensieri sono su questo e il modo in cui hanno implementato qualcosa di simile ...

shoot

+0

mongodb scrive più velocemente di couchdb. mongodb è la scelta lì. – panchicore

risposta

3

Non ho familiarità con le soluzioni preconfezionate voi citare. Se dovessi progettare questo da zero, avrei un semplice JS che raccoglieva informazioni sui clic e li inviava al server tramite Ajax (usando qualsiasi framework JS che stai già utilizzando), e sul lato server aggiungerei semplicemente quelle informazioni su un file di log per un'elaborazione "offline" successiva - in modo tale da essere indipendenti da django o da altri framework lato server, in sostanza.

L'aggiunta a un file di registro è un'azione molto leggera, mentre i DB per l'utilizzo Web sono generalmente ottimizzati per operazioni di lettura intensive (non in scrittura), quindi sono d'accordo con te che forza l'adattamento di tali informazioni (mentre entra) nel database dell'app esistente è improbabile che offra buone prestazioni.

+0

Avrò bisogno di fare più analisi sui dati di quanto non offra un file di log, ma il file di log non è una cattiva idea. Gli eventi vengono elaborati tramite il server tramite chiamate ajax, ma a questo punto mi piace l'idea di una coda di attività .... – jmat

+2

@jmat - non ci sono davvero limiti su ciò che è possibile e non è possibile inserire nei file di registro ... come accennato @Alex, puoi sempre analizzare questi dati "offline" in qualunque tipo di struttura tu debba fare la tua vera analisi. –

+1

@jmat, come dice @Matthew, la registrazione offre esattamente le stesse possibilità di "analisi dei dati", come si otterrebbe pompando i dati direttamente in qualsiasi programma - il log solo _stays_ per un po ', quindi può essere elaborato (più di una volta, se necessario) quando è più comodo farlo (ad esempio, un'elaborazione veloce e veloce eseguita contemporaneamente da un daemon di sorveglianza per alcune cose semplici che devi sapere subito, magazzino più completo offline in un secondo momento - qualunque cosa!). –

1

Se per clic si intende un clic su un collegamento che carica una nuova pagina (o esegue una richiesta AJAX), quindi ciò che si mira a fare è abbastanza semplice. I server Web tendono a mantenere registri di testo in chiaro sulle richieste, con informazioni su utente, ora/data, referrer, pagina richiesta, ecc. È possibile esaminare questi registri ed estrarre le statistiche necessarie.

D'altra parte, se si dispone di un'applicazione Web in cui i clic non generano necessariamente richieste server, la raccolta delle informazioni sui clic con javascript è la soluzione migliore.

+0

Questi clic possono provenire da più domini interni ed esterni, quindi in generale js è l'unica risposta qui ... che funziona già, sono più interessato ai modi per archiviare grandi quantità di questi dati senza influire sui click through e carichi di pagina. – jmat

2

Probabilmente si desidera mantenere un formato flessibile per i registri per anticipare esigenze o cambiamenti futuri. In questo senso, i database orientati ai documenti senza schema sono carini. Un vantaggio è che la struttura dei dati sarà vicina alle esigenze dell'applicazione per qualsiasi analisi eseguita successivamente (quindi, evitando parte dell'inevitabile lavoro di parsing/data munging).

Se stai pensando di usare mysql, postgresql o simili, allora dovresti esaminare qualcosa come rsyslog per il buffering delle scritture ed evitare la penalizzazione delle prestazioni con il logging pesante. (Non posso dire molto sul sedano e altri meccanismi di accodamento per questo tipo di cose, ma sembrano promettenti.)

Mongodb ha alcune caratteristiche interessanti che lo rendono suscettibile di registrazione come capped collections. Un riassunto può essere trovato in this post.

+0

L'ultimo link che hai fornito è uno dei motivi principali per cui sto cercando di usare mongo per questo scopo..thx. – jmat

Problemi correlati