Come gestire enormi operazioni su mysql

Question

Ho un database MySQL. Ho molti record (circa 4,000,000,000 righe) e voglio elaborarle per ridurli (riduci a circa 1,000,000,000 Righe).

Supponiamo di avere tabelle seguenti:

• tavolo Rawdata: Ho più di 5000 righe al secondo che voglio inserirle con Rawdata

• tavolo ProcedData : Questa tabella è una memoria elaborata (aggregata) per le righe inserite a Rawdata. Le righe minime contano> 20.000.000

• tavolo ProcedDataDetail: Scrivo i dettagli della tabella ProcedData (dati aggregati)

  Gli utenti vogliono visualizzare e cercare ProcedData tabella che deve unirsi più di 8 Altre tabelle. L'inserimento in rawdata e la ricerca in processEdData (ProcedData interno join elabotadetail join interno ...) sono molto lenti. Ho usato molti indici. Supponiamo che la lunghezza dei miei dati sia 1G, ma la mia lunghezza dell'indice è 4G :). (Voglio fare un giro di questi indici, rallentano il mio processo)

Come posso aumentare la velocità di questo processo?

Penso di aver bisogno di un tavolo da ombra da ProcedData, nominalo ProcedDdatashadow. Quindi proccem Rawdata e aggregarli con ProcedDdatashadow, quindi inserire il risultato in ProcedDdatashadow e ProcedData. Qual è la tua idea??

(Sto sviluppando il progetto di C ++)

Grazie in anticipo.

Answer 1

Senza sapere di più su quale sia la tua vera applicazione, ho questi suggerimenti:

1. Usa INNODB se non lo sei già. INNODB fa uso di bloccanti di righe e sono molto più bravi a gestire aggiornamenti/inserti simultanei. Sarà più lento se non lavori contemporaneamente, ma il blocco delle righe è probabilmente un must per te, a seconda di quante fonti avrai per Rawdata.

2. Gli indici di solito accelerano le cose, ma gli indici scelti male possono rendere le cose più lente. Non credo che tu voglia sbarazzarti di loro, ma molti indici possono rendere gli inserti molto lentamente. È possibile disabilitare gli indici durante l'inserimento di lotti di dati, al fine di impedire l'aggiornamento degli indici su ciascun inserto.

3. Se selezionerai un'enorme quantità di dati che potrebbero disturbare la raccolta dei dati, prendi in considerazione l'utilizzo di un server di database slave replicato che si utilizza solo per la lettura. Anche se ciò bloccerà le righe /tabelle, il database principale (master) non sarà interessato e lo slave tornerà alla velocità non appena sarà libero di farlo.

4. Devi elaborare i dati nel database? Se possibile, forse raccogliere tutti i dati nell'applicazione e inserire solo ProcessData.

Answer 2

Non hai detto quale sia la struttura dei dati, come è consolidato, come deve essere prontamente disponibile i dati per gli utenti né quanto si possa essere grumi del processo di consolidamento.

Tuttavia, il problema più immediato sarà affondare 5000 file al secondo. Avrai bisogno di una macchina molto grande e molto veloce (probabilmente un cluster frammento).

Se possibile, consiglierei di scrivere un buffer consolidato (usando una tabella hash in memoria - non nel DBMS) per inserire i dati consolidati - anche se sono solo parzialmente consolidati - quindi aggiorna da questo nella tabella ProcedData piuttosto che provare a provare a provare a provare a provare a provare a provare a provare popolalo direttamente dal rawdata.

In effetti, probabilmente prenderei in considerazione la separazione dei dati grezzi e consolidati su server/cluster separati (il motore federato MySQL è utile per fornire una visione unificata dei dati).

Hai analizzato le tue domande per vedere quali indici hai veramente bisogno? (suggerimento - questa sceneggiatura è molto utile per questo).