Bueno, si está esperando una nueva respuesta, eso significa que probablemente haya leído mis respuestas y suene como un disco rayado. Consulte Blog de partición para los pocos casos de uso en los que la partición puede ayudar al rendimiento. El tuyo no suena como cualquiera de los 4 casos.
Reducir device_id . INT es de 4 bytes; ¿Realmente tienes millones de dispositivos? TINYINT UNSIGNED es de 1 byte y un rango de 0..255. SMALLINT UNSIGNED es de 2 bytes y un rango de 0..64K. Eso encogerá un poco la mesa.
Si eres real pregunta es sobre cómo administrar tantos datos, entonces "pensemos fuera de la caja". Sigue leyendo.
Graficando... ¿Qué intervalos de fechas está graficando?
- ¿La 'última' hora/día/semana/mes/año?
- ¿Una hora/día/semana/mes/año arbitrario?
- ¿Un rango arbitrario, no vinculado a los límites de día/semana/mes/año?
¿Qué estás graficando?
- ¿Valor medio durante un día?
- ¿Máximo/mínimo durante un día?
- ¿Candelabros (etc.) por día o semana o lo que sea?
Independientemente del caso, debe crear (y mantener de forma incremental) una tabla de resumen con datos. Una fila contendría información de resumen durante una hora. Yo sugeriría
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;
La única tabla de resumen puede ser de 9 GB (para la cantidad actual de datos).
SELECT hr,
avg_val,
min_val,
max_val
FROM Summary
WHERE device_id = ?
AND sensor_id = ?
AND hr >= ?
AND hr < ? + INTERVAL 20 DAY;
Le daría los valores alto/bajo/promedio para 480 horas; suficiente para graficar? Tomar 480 filas de la tabla de resumen es mucho más rápido que tomar 60*480 filas de la tabla de datos sin procesar.
Obtener datos similares durante un año probablemente ahogaría un paquete de gráficos, por lo que puede Valdría la pena construir un resumen del resumen -- con resolución de un día. Serían unos 0,4 GB.
Hay algunas formas diferentes de construir la(s) tabla(s) de Resumen; podemos hablar de eso después de haber reflexionado sobre su belleza y leído Blog de tablas de resumen . Puede ser que recopilar los datos de una hora y luego aumentar la tabla Resumen sea la mejor manera. Eso sería algo así como el flip-flop discutido my Staging table blog .
Y, si tuviera los resúmenes por hora, ¿realmente necesita los datos minuto a minuto? Considere tirarlo. O, tal vez datos después de, digamos, un mes. Eso lleva al uso de particiones, pero solo por su beneficio en la eliminación de datos antiguos como se discutió en el "Caso 1" de Blog de partición
. Es decir, tendría particiones diarias, usando DROP y REORGANIZE todas las noches para cambiar el tiempo de la tabla "Hecho". Esto llevaría a disminuir su huella de 145 GB, pero sin perder muchos datos. Nuevo espacio:alrededor de 12 GB (resumen por horas + detalles minuto a minuto de los últimos 30 días)
PD:El Blog de tablas de resumen muestra cómo obtener la desviación estándar.
