Para responder a esta pregunta, primero debemos analizar el real problema al que te enfrentas.
El problema real sería la combinación más eficiente de escritura y recuperación de datos.
Repasemos tus conclusiones:
-
miles de mesas - bueno, eso viola el propósito de las bases de datos y hace que sea más difícil trabajar con ellas. Tampoco ganas nada. Todavía hay búsqueda de disco involucrada, esta vez con muchos descriptores de archivos en uso. También debe conocer los nombres de las tablas, y hay miles de ellos. También es difícil extraer datos, que es para lo que están las bases de datos:estructurar los datos de tal manera que pueda cruzar fácilmente los registros. Miles de tablas:no eficientes de perf. Punto de vista. No es eficiente desde el punto de vista del uso. Mala elección.
-
un archivo csv - probablemente sea excelente para obtener los datos, si necesita todo el contenido a la vez. Pero está lejos de ser remotamente bueno para manipular o transformar los datos. Dado el hecho de que confía en un diseño específico, debe tener mucho cuidado al escribir en CSV. Si esto crece a miles de archivos CSV, no te hiciste un favor. Quitó toda la sobrecarga de SQL (que no es tan grande) pero no hizo nada para recuperar partes del conjunto de datos. También tiene problemas para obtener datos históricos o hacer referencias cruzadas a cualquier cosa. Mala elección.
El escenario ideal sería poder acceder a cualquier parte del conjunto de datos de una manera eficiente y rápida sin ningún tipo de cambio de estructura.
Y esta es exactamente la razón por la que usamos bases de datos relacionales y por la que dedicamos servidores completos con mucha RAM a esas bases de datos.
En su caso, está utilizando tablas MyISAM (extensión de archivo .MYD). Es un formato de almacenamiento antiguo que funcionó muy bien para el hardware de gama baja que se usaba en el pasado. Pero en estos días, tenemos computadoras excelentes y rápidas. Es por eso que usamos InnoDB y le permitimos usar mucha RAM para reducir los costos de E/S. La variable en cuestión que lo controla se llama innodb_buffer_pool_size - googlear que producirá resultados significativos.
Para responder a la pregunta, una solución eficiente y satisfactoria sería usar una tabla donde almacene la información del sensor (id, título, descripción) y otra tabla donde almacene las lecturas del sensor. Asigna suficiente RAM o almacenamiento suficientemente rápido (un SSD). Las tablas se verían así:
CREATE TABLE sensors (
id int unsigned not null auto_increment,
sensor_title varchar(255) not null,
description varchar(255) not null,
date_created datetime,
PRIMARY KEY(id)
) ENGINE = InnoDB DEFAULT CHARSET = UTF8;
CREATE TABLE sensor_readings (
id int unsigned not null auto_increment,
sensor_id int unsigned not null,
date_created datetime,
reading_value varchar(255), -- note: this column's value might vary, I do not know what data type you need to hold value(s)
PRIMARY KEY(id),
FOREIGN KEY (sensor_id) REFERENCES sensors (id) ON DELETE CASCADE
) ENGINE = InnoDB DEFAULT CHARSET = UTF8;
InnoDB, de forma predeterminada, utiliza un archivo plano para toda la base de datos/instalación. Eso alivia el problema de exceder el límite del descriptor de archivos del SO/sistema de archivos. Varios, o incluso decenas de millones de registros no deberían ser un problema si tuviera que asignar 5-6 gigas de RAM para mantener el conjunto de datos de trabajo en la memoria, lo que le permitiría acceder rápidamente a los datos.
Si tuviera que diseñar un sistema de este tipo, este es el primer enfoque que haría (personalmente). A partir de ahí, es fácil ajustar según lo que necesite hacer con esa información.
