Bene, se speri in una nuova risposta, significa che probabilmente hai letto le mie risposte e sembro un disco rotto. Vedi blog sul partizionamento per i pochi casi d'uso in cui il partizionamento può aiutare le prestazioni. Il tuo non suona come uno qualsiasi dei 4 casi.
Riduci device_id . INT è 4 byte; hai davvero milioni di dispositivi? TINYINT UNSIGNED è 1 byte e un intervallo di 0..255. SMALLINT UNSIGNED è 2 byte e un intervallo di 0..64K. Ciò ridurrà un po' il tavolo.
Se sei reale la domanda riguarda come gestire così tanti dati, quindi "pensare fuori dagli schemi". Continua a leggere.
Rappresentazione grafica... Quali intervalli di date stai rappresentando graficamente?
- L'"ultima" ora/giorno/settimana/mese/anno?
- Un'ora/giorno/settimana/mese/anno arbitrario?
- Un intervallo arbitrario, non legato ai limiti di giorno/settimana/mese/anno?
Cosa stai rappresentando graficamente?
- Valore medio su un giorno?
- Max/min nell'arco della giornata?
- Candelieri (ecc.) per giorno o settimana o altro?
Indipendentemente dal caso, è necessario creare (e mantenere in modo incrementale) una tabella di riepilogo con i dati. Una riga conterrebbe informazioni di riepilogo per un'ora. Suggerirei
CREATE TABLE Summary (
device_id SMALLINT UNSIGNED NOT NULL,
sensor_id TINYINT UNSIGNED NOT NULL,
hr TIMESTAMP NOT NULL,
avg_val FLOAT NOT NULL,
min_val FLOAT NOT NULL,
max_val FLOAT NOT NULL
PRIMARY KEY (device_id, sensor_id, hr)
) ENGINE=InnoDB;
L'unica tabella di riepilogo potrebbe essere 9 GB (per la quantità attuale di dati).
SELECT hr,
avg_val,
min_val,
max_val
FROM Summary
WHERE device_id = ?
AND sensor_id = ?
AND hr >= ?
AND hr < ? + INTERVAL 20 DAY;
Ti darebbe i valori hi/lo/avg per 480 ore; abbastanza per rappresentare graficamente? L'acquisizione di 480 righe dalla tabella di riepilogo è molto più veloce dell'acquisizione di 60*480 righe dalla tabella di dati grezzi.
Ottenere dati simili per un anno probabilmente soffocherebbe un pacchetto grafico, quindi potrebbe vale la pena costruire un riassunto del riassunto -- con risoluzione di un giorno. Sarebbe circa 0,4 GB.
Esistono diversi modi per creare le tabelle di riepilogo; possiamo discuterne dopo aver riflettuto sulla sua bellezza e aver letto il Blog delle tabelle di riepilogo . Potrebbe essere che la raccolta di un'ora di dati, quindi l'aumento della tabella di riepilogo, sia il modo migliore. Sarebbe un po' come il flip-flop discusso il mio blog Staging table .
E, se avessi i riepiloghi orari, hai davvero bisogno dei dati minuto per minuto? Considera di buttarlo via. O forse dati dopo, diciamo, un mese. Ciò porta all'utilizzo del partizionamento, ma solo per il suo vantaggio nell'eliminazione dei vecchi dati come discusso nel "Caso 1" di blog sul partizionamento
. Cioè, avresti partizioni giornaliere, usando DROP e REORGANIZE tutte le sere per spostare l'ora della tavola "Fatto". Ciò porterebbe a ridurre l'ingombro di 145 GB, ma senza perdere molti dati. Nuovo footprint:circa 12 GB (riepilogo orario + dettagli minuto per minuto degli ultimi 30 giorni)
PS:il blog della tabella riepilogativa mostra come ottenere la deviazione standard.
