Come gestire grandi quantità di dati per un modulo di statistiche web

Question

Sto sviluppando un modulo statistico per il mio sito Web che mi aiuterà a misurare i tassi di conversione e altri dati interessanti.

Il meccanismo che utilizzo è - per memorizzare una voce di database in una tabella statistica - ogni volta che un utente entra in una zona specifica nel mio DB (evito i record duplicati con l'aiuto dei cookie).

Ad esempio, ho le seguenti zone:

1. Sito web: una zona generale utilizzata per contare utenti unici poiché di recente ho smesso di fidarmi di Google Analytics.
2. Categoria: auto-descrittiva.
3. Minisito: auto-descrittivo.
4. Immagine prodotto: ogni volta che l'utente vede un prodotto e il modulo di invio dei lead.

Il problema è dopo un mese, la mia tabella delle statistiche è piena di molte righe e le pagine ASP.NET che ho scritto per analizzare il caricamento dei dati davvero sono lente.

Ho pensato che forse scrivere un servizio in qualche modo analizzasse i dati, ma non riesco a vedere alcun modo per farlo senza perdere flessibilità.

Le mie domande:

1. In che modo le applicazioni di analisi dei dati su larga scala, come Google Analytics, caricano i dati così velocemente?
2. Qual è il modo migliore per farlo?
3. Forse il mio design del DB è sbagliato e dovrei archiviare i dati in una sola tabella?

Grazie per chiunque ti aiuti,

Eytan.

Answer 1

L'approccio di base che stai cercando si chiama aggregazione .

Sei interessato a determinate funzioni calcolate sui tuoi dati e invece di calcolare i dati " online " quando si avvia il sito Web di visualizzazione, li si calcola offline, tramite un processo batch di notte o in modo incrementale quando viene scritto il registro.

Un semplice miglioramento sarebbe quello di memorizzare i conteggi per utente / sessione, invece di memorizzare ogni hit e contarli. Ciò ridurrebbe i requisiti di elaborazione analitica di un fattore nell'ordine dei risultati per sessione. Naturalmente aumenterebbe i costi di elaborazione quando si inseriscono voci di registro.

Un altro tipo di aggregazione si chiama elaborazione analitica online , che aggrega solo alcune dimensioni di i tuoi dati e consente agli utenti di aggregare le altre dimensioni in una modalità di navigazione. Questo compromette prestazioni, archiviazione e flessibilità.

Answer 2

Sembra che tu possa fare bene usando due database. Uno è per i dati transazionali e gestisce tutte le istruzioni INSERT. L'altro è per la segnalazione e gestisce tutte le richieste di query.

È possibile indicizzare lo snot dal database di report e / o denormalizzare i dati in modo da utilizzare meno query nelle query. Esportare periodicamente i dati dal database delle transazioni al database di report. Questo atto migliorerà i tempi di risposta dei rapporti insieme alle idee di aggregazione menzionate in precedenza.

Answer 3

Un altro trucco da sapere è il partizionamento . Guarda come viene fatto nel database di tua scelta, ma fondamentalmente l'idea è di dire al tuo database di mantenere una tabella partizionata in diversi sottotitoli, ognuno con una definizione identica, basata su un valore.

Nel tuo caso, ciò che è molto utile è " range partitioning " - scegliere la partizione in base a un intervallo in cui rientra un valore. Se esegui la partizione per intervallo di date, puoi creare sotto-tabelle separate per ogni settimana (o ogni giorno o ogni mese - dipende da come usi i tuoi dati e dalla loro quantità).

Ciò significa che se si specifica un intervallo di date quando si emette una query, i dati al di fuori di tale intervallo non verranno nemmeno considerati; ciò può portare a un notevole risparmio di tempo, persino migliore di un indice (un indice deve considerare ogni riga, quindi crescerà con i tuoi dati; una partizione è una al giorno).

Questo rende sia le query online (quelle inviate quando colpisci la tua pagina ASP), sia le query di aggregazione utilizzate per pre-calcolare le statistiche necessarie, molto più velocemente.