Soluzione MySQL per 1 milione di clic al giorno

Question

Stiamo eseguendo un server di annunci OpenX personalizzato su un database MySQL che ottiene circa. 1 milione di clic/giorno. Abbiamo bisogno di memorizzare tutte queste informazioni sui clic e mostrare statistiche basate su di esse.

In questo momento, tutte le informazioni sui clic vengono aggregate ogni 2 giorni e le informazioni di clic specifiche vengono eliminate. Ma vogliamo fornire ai nostri affiliati una nuova funzionalità che consentirà loro di impostare un ID di tracciamento dinamico (TID) e, fondamentalmente, tracciare i loro clic e conversioni basati su questo.

Quindi, il problema è che la nostra tabella di clic crescerà di un minimo di 1 milione di voci al giorno, e dobbiamo essere in grado di cercare questa tabella e mostrare tutti i clic per un utente per un determinato periodo di tempo, raggruppato dal TID che ho menzionato sopra, o cercato dal TID.

Ho dato un'occhiata al partizionamento MySQL e sembra una buona soluzione, ma, non sono sicuro che funzionerà ancora bene su un database ENORME (forse miliardi di voci).

Quale pensi che sarebbe l'approccio corretto per questo problema?

EDIT:

In base alle risposte, ora sto pensando a una soluzione mista.

Abbiamo già una tabella "LIVE" da cui le voci vengono eliminati quando i clic sono aggregate in fase di manutenzione, che sembra qualcosa di simile:

Tabella: scatta

viewer_id | ... | date_time | affiliate_id | ... | tid

(ho saltato le colonne che sono poco importante a questo punto)

in fase di manutenzione, posso spostare tutto ad un altro tavolo mensile che sembra quasi lo stesso, dire Tabella: clicks_2012_11, che ha indici per date_time, affiliate_id e tid ed è diviso dal affiliate_id.

Così ora, quando un affiliato vuole vedere le sue statistiche per gli ultimi 2 mesi, so di avere a guardare dentro il Tabella: clicks_2012_10 e la Tavola : clicks_2012_11 (avrò l'intervallo di tempo limitato per un massimo di 2 mesi). Perché ho le tabelle partizionate da affiliate_id, solo le partizioni necessarie verranno cercate dalle 2 tabelle e ora posso elencare tutte le TID che hanno avuto attività negli ultimi 2 mesi.

Cosa ne pensi di questo approccio? Ci sono problemi evidenti? Sono troppo complicato per le cose senza una solida ragione?

Answer 1

Non c'è nulla di intrinseco in tabelle grandi (anche "enormi") che facciano fallire MySQL.Grandi tavoli sono per lo più di un problema in termini di:

• spazio su disco
utilizzo
• cache (si rischia di non essere in grado di eseguire in memoria)
• manutenzione (modifiche allo schema, ricostruisce, ...)

È necessario affrontare tutti questi.

Il partizionamento è utile soprattutto per la manutenzione dei dati di massa come la caduta di intere partizioni. Non è certamente una best practice per partizionare grandi tabelle di default solo su alcune colonne. Il partizionamento viene sempre introdotto per una ragione specifica.

Answer 2

L'ottimizzazione per l'inserimento e l'ottimizzazione per il recupero di solito si escludono a vicenda. Potresti stare meglio con due tavoli:

live data: no (or minimal) keys, myisam to remove transaction overhead, etc... 
historical data: indexed up the wazoo, with data moved over from the live data on a periodic basis.