2010-11-15 14 views
8

Sto lavorando senza un sito che memorizza le singole pagine viste in una tabella 'vista':modo migliore per conservare views/stats in MySQL

CREATE TABLE `views` (
    `view_id` bigint(16) NOT NULL auto_increment, 
    `user_id` int(10) NOT NULL, 
    `user_ip` varchar(15) NOT NULL, 
    `view_url` varchar(255) NOT NULL, 
    `view_referrer` varchar(255) NOT NULL, 
    `view_date` date NOT NULL, 
    `view_created` int(10) NOT NULL, 
    PRIMARY KEY (`view_id`), 
    KEY `view_url` (`view_url`) 
) ENGINE=MyISAM DEFAULT CHARSET=utf8 AUTO_INCREMENT=1 ; 

E 'piuttosto semplice, negozi user_id (id dell'utente sul sito), il loro indirizzo IP, l'url (senza il dominio per ridurre la dimensione del tavolo un po '), l'url di riferimento (non lo si sta usando proprio ora e potrebbe liberarsene), la data (AAAA-MM-GG) formato ovviamente) e il timestamp unix di quando si è verificata la visualizzazione.

La tabella, ovviamente, sta diventando piuttosto grande (4 milioni di righe al momento e si tratta di un sito piuttosto giovane) e le query in esecuzione su di esso sono lente.

Per qualche ottimizzazione di base Ora ho creato una tabella 'views_archive':

CREATE TABLE `views_archive` (
    `archive_id` bigint(16) NOT NULL auto_increment, 
    `view_url` varchar(255) NOT NULL, 
    `view_count` smallint(5) NOT NULL, 
    `view_date` date NOT NULL, 
    PRIMARY KEY (`archive_id`), 
    KEY `view_url` (`view_url`), 
    KEY `view_date` (`view_date`) 
) ENGINE=MyISAM DEFAULT CHARSET=utf8 AUTO_INCREMENT=1 ; 

questo ignora le informazioni utente (e l'URL di riferimento) e memorizza quante volte un URL è stato visto al giorno. Questo è probabilmente il modo in cui generalmente vorremmo utilizzare i dati (quante volte una pagina è stata visualizzata su una base giornaliera), quindi è necessario rendere l'interrogazione abbastanza veloce, ma anche se la utilizzo principalmente sostituisce la tabella 'views' (destra ora immagino di poter mostrare le visualizzazioni di pagina all'ora per l'ultima settimana/mese o giù di lì e quindi mostrare viste giornaliere oltre a quella e quindi sarebbe solo bisogno della tabella 'viste' per contenere i dati dell'ultima settimana/mese) ma è ancora una grande tavolo.

In ogni caso, per farla breve, mi chiedo se puoi darmi qualche consiglio su come gestire al meglio la memorizzazione di statistiche/visualizzazioni di pagina in un sito MySQL, con l'obiettivo di mantenere entrambe le dimensioni del tavolo (s) nel db il più piccolo possibile ed essere ancora in grado di interrogare facilmente (e almeno in modo relativamente rapido) le informazioni. Ho guardato un po 'le tabelle partizionate, ma il sito non ha MySQL 5.1 installato. Qualsiasi altro consiglio o idea che potresti offrire sarebbe molto apprezzato.

+0

umm, doesn il tuo server ha un log di accesso che conserva già tutti questi dati? Ci sono un sacco di visualizzatori/riepiloghi di log là fuori per i log di accesso web. C'è un valido motivo per non usarne uno? – dnagirl

+0

Qual è lo scopo della colonna view_created? –

+0

Lo scopo della colonna view_created, MicWafflestix, verrebbe utilizzato se volessi mostrare le visualizzazioni ogni ora (ad esempio quante volte un articolo è stato visualizzato ogni ora oggi). Suppongo che potrei usare DATETIME invece del timestamp INT (10), ma non sono sicuro che mi avrebbe aiutato molto. – Charlie

risposta

1

Probabilmente si desidera avere una tabella solo per le pagine e le viste utente hanno un riferimento a tale tabella. Un'altra possibile ottimizzazione potrebbe essere l'IP dell'utente memorizzato in una tabella diversa, forse alcune informazioni sulla tabella di sessione. Ciò dovrebbe ridurre leggermente i tempi di interrogazione. Sei sulla strada giusta con la tabella degli archivi; le stesse ottimizzazioni dovrebbero aiutare anche questo.

+0

Mi piace questa idea. Sembra una ottimizzazione piuttosto semplice e solida della struttura dei dati (al contrario dell'aggiornamento di mysql o dell'uso di una tabella nosql o di qualche altro grande cambiamento che temevo di dover fare). Ho anche appena scoperto la funzione INET_ATON() in MySQL che potrebbe aiutarmi a ridurre la dimensione della memorizzazione dell'indirizzo IP (può usare INT invece di VARCHAR). Per il breve termine, comunque, penso che le soluzioni che hai menzionato faranno molta strada nel risolvere i miei problemi. Grazie. – Charlie

+0

@ Charlie: prego. A grandi scale, le piccole ottimizzazioni cominciano davvero a fare una grande differenza; allo stesso tempo, alcune delle ottimizzazioni davvero complesse non danno il rendimento che ci si aspetta spesso. Trovo che partire per le ottimizzazioni semplici e dirette in primo luogo è di solito ciò che mi dà il 90% del percorso verso una buona soluzione, se non addirittura tutto lì. –

1

Engine Archive Storage MySQL

http://dev.mysql.com/tech-resources/articles/storage-engine.html

E 'grande per i registri, è veloce a scrivere, l'unico aspetto negativo è la lettura è un po' più lento. ma è ottimo per le tabelle di registro.

+0

L'ho guardato un po 'l'altro giorno. Sembra interessante, ma non è "supportato" (controllato tramite SHOW ENGINES; query) sulla mia attuale installazione MySQL. Chiederò agli ospitanti di accenderlo o qualsiasi altra cosa e giocarci. Grazie per il consiglio. – Charlie

+0

Il collegamento è rotto. –

0

Supponendo che la tua applicazione sia un blog e desideri tenere traccia delle visualizzazioni per i post del tuo blog, probabilmente avrai una tabella denominata blog_posts. In questa tabella, ti suggerisco di creare una colonna chiamata "views" e in questa colonna, verrà archiviato un valore statico di quante visualizzazioni ha questo post. Continuerai a utilizzare la tabella views, ma questa verrà utilizzata solo per tenere traccia di tutte le visualizzazioni (e per verificare se sono "univoci" o meno).

In pratica, quando un utente visita un post di un blog, controlla la tabella views per vedere se è necessario aggiungerla. In tal caso, incrementerà anche il campo "Visualizzazioni" nella riga corrispondente per il post del blog in blog_posts. In questo modo, puoi semplicemente fare riferimento al campo "visualizzazioni" per ogni post per avere una rapida panoramica su quante visualizzazioni ha. È possibile fare un ulteriore passo avanti e aggiungere la ridondanza impostando un lavoro CRON per contare nuovamente e verificare tutte le visualizzazioni e aggiornare ogni riga blog_posts di conseguenza alla fine della giornata.O se preferisci, puoi anche eseguire un conteggio su ogni aggiornamento se la precisione al secondo è la chiave .

Questa soluzione funziona bene se il tuo sito viene letto ad alta intensità e si sono costantemente dover ottenere un conteggio di quanti viste ogni post del blog ha (di nuovo, partendo dal presupposto che è il vostro :-) applicazione)

Problemi correlati