Ecco cosa consiglio in base ai server/dipendenti/dati se questi server sono. Poiché si sta utilizzando 1 server (e 1 backup), la capacità dell'unità dovrebbe essere sufficiente per un po ', a meno che non si desideri archiviare dati completi su questo server. I dati possono crescere rapidamente e io penserei di aumentare la capacità o archiviare i dati da qualche altra parte.
Ora, poiché ci sono molte persone che possono richiedere i dati di reporting, l'idea principale è quella di recuperare i dati il più velocemente possibile per assicurarsi di non bloccare i record (specialmente se si utilizzano tabelle myisam - table locking vs innodb che ha il blocco a livello di riga).
Usa il tuo indice (unico se necessario) con saggezza e conserva i tuoi dati nel modo più efficiente possibile utilizzando il timestamp.
Quello che puoi fare è anche riassumere i tuoi dati che possono semplificare le tue domande. Anche se, non è una pratica comune nei database poiché non rispetta le forme normali. Puoi ottenere grandi prestazioni, ma è un problema da mantenere.
Per essere onesti, un cron eseguito ogni minuto va bene poiché si ha il tempo in cui si salva il record ma è possibile ottenere dati ogni secondo. Ti consiglio di assicurarti che quando ricevi un record, contrassegni questo record come "elaborato" o in qualche altro stato in modo che tu non prenda questo record due volte.
Ora, quando riepilogate i vostri dati, assicuratevi di ottimizzare le vostre domande e potete anche controllare che cosa emetterà l'explain e poi prendere una decisione.
EDIT: dati che sintetizzano (che non rispettano la normalizzazione del database) si arriva grandi prestazioni dal momento che solo i record di query senza l'utilizzo di funzioni di aggregazione e avendo unisce le tabelle utilizzando il minimo in cui clausola.
Esempio:
98 views on product 1
1 order
21 referral click from clients
2 added to wishlist
può essere:
SELECT
views, orders, referral, whishlist
FROM
summarize_stats_20111201 /* daily table for example */
WHERE
`time` between 1322791200 /*2011-12-01 21:00:00*/ AND 1322791260 /*2011-12-01 21:01:00*/;
views ha la quantità totale di visualizzazioni, in questo esempio 98
orders ha la quantità totale di ordini, in questo esempio 1
referral ha il Tal quantità di riferimento, in questo esempio 21
wishlist ha la quantità totale di lista dei desideri, in questo esempio 2
Questi dati sono calcolati in una tabella riassuntiva (questo è il motivo per cui ho detto "non rispetta la normalizzazione dei database "perché non si calcolano mai i dati in un RDBMS), ma se hai bisogno di dati istantaneamente, questo è un modo per farlo.
EDIT 2: Ecco un esempio di mantenimento di questa soluzione:
Si dispone di un cronjob che mantiene le tabelle. Il suo compito è quello di creare il tavolo per il giorno dopo o quello che ti serve.
// in php
$date = date('Ymd', strtotime('+1 day')); // for daily table
$sql = 'CREATE TABLE IF NOT EXISTS the_database.summarize_stats_" . $date . ";
Quindi, quando si inserti, assicurarsi di avere il nome della tabella a destra e si utilizza ON DUPLICATE KEY
// in php
$sql = 'INSERT INTO TABLE summarize_stats_20111201 SET /* all the fields you need */ ON DUPLICATE KEY views = views + 1;
per esempio, se si desidera aumentare la vista
Quello che ho anche dimenticare è se è necessario interrogare 1 settimana di dati, sarà necessario creare una tabella merge. In questo modo si può fare qualcosa di simile:
SELECT
views, orders, referral, whishlist
FROM
summarize_stats_2011 /* yearly merge table for example */
WHERE
`time` between 1322272800 /*2011-11-25 21:00:00*/ AND 1322791260 /*2011-12-01 21:01:00*/;
In questo modo non c'è bisogno di UNION ALL tonnellate di query.
quanti utenti hai e cresceranno? quanti dati ottieni al minuto? Che tipo di server hai (quanto, velocità, hdd, memoria)? –
ho aggiornato la mia risposta grazie –
grazie per l'aggiornamento –