Quanto deve essere grande la tabella MySQL prima di suddividerla in più tabelle?

Question

Problema: abbiamo un tavolo molto grande e in crescita. La maggior parte delle voci (80% circa) sono dati storici (con il campo "data" passata la data corrente) che vengono interrogati raramente, mentre una piccola parte di esso (diciamo il 20%) sono dati correnti (campo "DATA" dopo la data corrente), la maggior parte delle query cerca queste voci correnti.

considerare due possibili scenari, che si sarebbe meglio (considerando la difficoltà di attuazione e le prestazioni generali, ...)

1. Rompere il grande tavolo in due tabella: i dati storici e attuali. E su base giornaliera sposto i record con data scaduta dalla tabella corrente alla tabella storica.

2. Mantenere un record in una tabella (il campo DATI è definito come INDICE).

Lo scenario A indicherebbe più caos nella implementazione e manutenzione, e il sovraccarico su basi quotidiane per data tra le tabelle in movimento, mentre lo scenario B indicherebbe la ricerca di un grande database (anche se indicizzato). Imporre problemi di memoria? Quale scenario è raccomandato? C'è qualche altro consiglio?

Answer 1

In genere non si desidera rompere un grande tavolo in più tabelle, anche se avere una tabella corrente e storica è assolutamente ragionevole. Il tuo processo ha un senso. È quindi possibile ottimizzare la tabella corrente per le esigenze della query. Probabilmente andrei su due tavoli (date le informazioni limitate fornite), perché consente tale ottimizzazione.

Tuttavia, non dividere i dati storici. Invece, usa il partizionamento. Vedi lo documentation. Un avvertimento: le query devono specificare la chiave di partizionamento nella clausola where per sfruttare le partizioni. Con un grande tavolo, questo è comunque tipico.

Answer 2

Domanda: sono i dati storici necessari per la funzionalità del sistema o questi record sono archiviati per altri scopi (ad esempio audit)? Potrebbe essere il momento di pulire la casa spostando i dati storici in un archivio.

Answer 3

Nella mia esperienza, la maggior parte dei sistemi con grandi dati ha tabelle storiche. Nella maggior parte dei casi che sono stato, sia i dati correnti che i dati storici hanno gruppi di utenti diversi. I dati attuali vengono utilizzati dagli utenti front-end per trattare con i clienti le loro transazioni correnti o recenti. I dati storici vengono solitamente utilizzati dai gruppi di utenti che non devono parlare direttamente con clienti/clienti.

Non preoccuparti molto del problema dell'implementazione e della manutenzione, perché penso che la tua considerazione principale riguardi le prestazioni. L'implementazione è solo un accordo occasionale che verrà eseguito su una frequenza specificata (come l'archivio settimanale, mensile o annuale) dopo aver spostato il/i programma/i in produzione. La manutenzione è molto piccola e puoi dimenticartene una volta che è già stata implementata. Devi solo assicurarti di testare accuratamente i programmi.

Per tabelle storiche normalizzate, le tabelle hanno la stessa struttura e nomi di campi che semplificano la copia dei dati. In questo modo, si può solo unire un tavolo tra i tavoli.

Se si sceglie di non dividere i dati, si continuerà ad aggiungere indice dopo indice. Ma da qualche parte lungo la strada, incontrerai ancora lo stesso problema.