Architettura del database per milioni di nuove righe al giorno

Question

Devo implementare un servizio di analisi Web personalizzato per un numero elevato di siti Web. I soggetti chiave sono:

• Sito
• Visitor

ogni visitatore avrà hanno una singola riga nel database con informazioni come pagina di destinazione, l'ora del giorno, sistema operativo, browser, referrer , IP, ecc

ho bisogno di fare domande aggregate su questo database come 'contare tutti i visitatori che hanno Windows come sistema operativo e provenivano da Bing.com'

Ho centinaia di siti Web da monitorare e il numero di visitatori per tali siti web varia da poche centinaia al giorno a pochi milioni al giorno. In totale, mi aspetto che questo database cresca di circa un milione di righe al giorno.

Le mie domande sono:

1) MySQL è una buona base di dati per questo scopo?

2) Quale potrebbe essere una buona architettura? Sto pensando di creare una nuova tabella per ogni sito web. O magari iniziare con una singola tabella e quindi generare una nuova tabella (giornaliera) se il numero di righe in una tabella esistente supera 1 milione (la mia ipotesi è corretta). La mia unica preoccupazione è che se una tabella diventa troppo grande, le query SQL possono diventare drammaticamente lente. Quindi, qual è il numero massimo di righe che dovrei memorizzare per tabella? Inoltre, c'è un limite al numero di tabelle che MySQL può gestire.

3) È consigliabile eseguire query di aggregazione su milioni di righe? Sono pronto per aspettare un paio di secondi per ottenere risultati per tali domande. È una buona pratica o esiste un altro modo per fare query aggregate?

In breve, Sto provando un progetto di un tipo di installazione di data warehouse di grandi dimensioni che sarà scritto pesante. Se sei a conoscenza di casi di studio o rapporti pubblicati, sarà fantastico!

Answer 1

Alcuni suggerimenti in un database agnostico.

Il razionale più semplice è distinguere tra le tabelle di lettura intensiva e di scrittura intensiva. Probabilmente è una buona idea creare due schemi paralleli giornalieri/settimanali e uno schema cronologico. Il partizionamento può essere fatto in modo appropriato. Si può pensare a un lavoro batch per aggiornare lo schema della cronologia con i dati dello schema giornaliero/settimanale. Nello schema della cronologia, è possibile creare tabelle di dati separate per sito Web (in base al volume di dati).

Se tutto ciò che interessa è nell'aggregazione statistiche solo (che può non essere vero). È una buona idea avere tabelle riassuntive (mensili, giornaliere) in cui il sommario è archiviato come totale di visitatori unqiue, visitatori ripetuti ecc; e queste tabelle riassuntive devono essere aggiornate alla fine del giorno. Ciò consente di calcolare al volo le statistiche senza attendere l'aggiornamento del database della cronologia.

Answer 2

Se stai parlando di grandi volumi di dati, guarda MySQL partitioning. Per queste tabelle, una partizione per data/ora sarebbe certamente di aiuto per le prestazioni. C'è un articolo decente sul partizionamento here.

Cerca di creare due database separati: uno per tutti i dati grezzi per le scritture con indicizzazione minima; un secondo per la segnalazione utilizzando i valori aggregati; con un processo batch per aggiornare il database di report dal database di dati non elaborati o utilizzare la replica per farlo automaticamente.

EDIT

Se vuoi essere veramente intelligente con i report di aggregazione, di creare una serie di tabelle di aggregazione ("oggi", "settimana fino ad oggi", "mese fino ad oggi", "per anno"). Aggregarsi dai dati grezzi a "oggi" giornalmente o in "tempo reale"; aggregare da "di giorno" a "settimana a data" a notte; da "Settimana ad oggi" a "il mese fino ad oggi" su base settimanale, ecc Quando l'esecuzione di query, join (UNIONE) le tabelle appropriate per la intervalli di date che ti interessa.

EDIT # 2

Piuttosto che una tabella per client, lavoriamo con uno schema di database per client. A seconda della dimensione del client, potremmo avere diversi schemi in una singola istanza di database o un'istanza di database dedicata per client. Utilizziamo schemi separati per la raccolta di dati grezzi e per l'aggregazione/reporting per ciascun cliente. Eseguiamo più server di database, limitando ogni server a una singola istanza di database. Per la resilienza, i database vengono replicati su più server e bilanciati per garantire prestazioni migliorate.

Answer 3

Dovresti davvero testare la strada da percorrere, simulando gli ambienti il ​​più vicino possibile all'ambiente live, con dati "reali" (formato corretto & lunghezza). Query di riferimento e varianti di strutture di tabelle. Dato che sembri conoscere MySQL, inizia da lì. Non dovresti impiegare molto tempo per impostare alcuni script che bombardano il tuo database con le query. Studiando i risultati di il tuo database con il tuo tipo di dati ti aiuterà a capire dove si verificheranno i colli di bottiglia.

non è una soluzione, ma si spera qualche aiuto sulla strada, buona fortuna :)

Answer 4

Si dovrebbe pensare di dividere i dati dal sito tra i database o schemi - Questo non solo rende molto più facile per il backup, eliminare ecc una singolo sito/cliente, ma elimina anche il fastidio di assicurarsi che nessun cliente possa vedere i dati di altri clienti per errore o codifica scadente, ecc. Significa anche che è più facile fare delle scelte sul partizionamento, al di sopra e al di sopra del partizionamento a livello di tabella per ora o cliente ecc.

Inoltre, hai affermato che il volume di dati è di 1 milione di righe al giorno (non è particolarmente pesante e non richiede un'enorme potenza per il log/store, anzi per segnalare (anche se stavate generando 500 report a mezzanotte potreste loggare). Comunque hai anche detto che alcuni siti avevano 1 milione di visitatori al giorno, quindi forse pensi che sia troppo prudente?

Infine non hai detto se vuoi segnalare in tempo reale a la chartbeat/opentracker ecc o l'aggiornamento ciclico come google analytics - questo avrà un impatto significativo su quale sia il tuo modello di storage dal primo giorno.

M