Una volta ho lavorato con un database MySQL molto grande (Terabyte +). La tabella più grande che avevamo era letteralmente di oltre un miliardo di righe.
Ha funzionato. MySQL ha elaborato i dati correttamente per la maggior parte del tempo. Era estremamente ingombrante però.
Solo il backup e l'archiviazione dei dati è stata una sfida. Ci vorrebbero giorni per ripristinare la tabella, se necessario.
Avevamo numerose tabelle nell'intervallo 10-100 milioni di righe. Qualsiasi aggiunta significativa ai tavoli richiedeva troppo tempo e richiedeva un'eternità. Quindi abbiamo scritto procedure memorizzate per "camminare" nelle tabelle ed elaborare join rispetto a intervalli di "id". In questo modo elaboreremo i dati 10-100.000 righe alla volta (Unisciti contro ID 1-100.000 quindi 100.001-200.000, ecc.). Questo è stato significativamente più veloce che unirsi contro l'intero tavolo.
Anche l'uso di indici su tabelle molto grandi che non sono basate sulla chiave primaria è molto più difficile. Mysql archivia gli indici in due parti:memorizza gli indici (diversi dall'indice primario) come indici ai valori della chiave primaria. Quindi le ricerche indicizzate vengono eseguite in due parti:prima MySQL va a un indice e ne estrae i valori della chiave primaria che deve trovare, quindi esegue una seconda ricerca sull'indice della chiave primaria per trovare dove si trovano quei valori.
La rete è che per tabelle molto grandi (1-200 milioni più righe) l'indicizzazione rispetto alle tabelle è più restrittiva. Hai bisogno di meno indici più semplici. E anche fare semplici istruzioni select che non si trovano direttamente su un indice potrebbe non tornare mai più. Dove le clausole devono colpisci gli indici o dimenticalo.
Ma tutto ciò detto, le cose hanno funzionato davvero. Siamo stati in grado di utilizzare MySQL con queste tabelle molto grandi ed eseguire calcoli e ottenere risposte corrette.
