Per rispondere a questa domanda, dobbiamo prima analizzare il reale problema che stai affrontando.
Il vero problema sarebbe la combinazione più efficiente di scrittura e recupero dei dati.
Esaminiamo le tue conclusioni:
-
migliaia di tavoli - beh, ciò viola lo scopo dei database e rende più difficile lavorarci. Anche tu non guadagni nulla. È ancora coinvolta la ricerca del disco, questa volta con molti descrittori di file in uso. Devi anche conoscere i nomi dei tavoli e ce ne sono migliaia. È anche difficile estrarre i dati, che è lo scopo dei database:strutturare i dati in modo tale da poter fare facilmente riferimento incrociato ai record. Migliaia di tavoli - non efficienti da perf. punto di vista. Non efficiente dal punto di vista dell'utilizzo. Cattiva scelta.
-
un file CSV - è probabilmente eccellente per recuperare i dati, se hai bisogno di interi contenuti in una volta. Ma è tutt'altro che lontanamente buono per manipolare o trasformare i dati. Dato che ti affidi a un layout specifico, devi stare molto attento mentre scrivi su CSV. Se questo cresce fino a migliaia di file CSV, non ti sei fatto un favore. Hai rimosso tutto il sovraccarico di SQL (che non è così grande) ma non hai fatto nulla per recuperare parti del set di dati. Hai anche problemi a recuperare dati storici o fare riferimenti incrociati a qualsiasi cosa. Cattiva scelta.
Lo scenario ideale sarebbe poter accedere a qualsiasi parte del set di dati in modo efficiente e rapido senza alcun tipo di modifica della struttura.
E questo è esattamente il motivo per cui utilizziamo database relazionali e perché a quei database dedichiamo interi server con molta RAM.
Nel tuo caso, stai utilizzando le tabelle MyISAM (estensione file .MYD). È un vecchio formato di archiviazione che funzionava benissimo per l'hardware di fascia bassa che veniva utilizzato in passato. Ma al giorno d'oggi abbiamo computer eccellenti e veloci. Ecco perché utilizziamo InnoDB e gli consentiamo di utilizzare molta RAM in modo da ridurre i costi di I/O. La variabile in questione che la controlla si chiama innodb_buffer_pool_size - Google che produrrà risultati significativi.
Per rispondere alla domanda, una soluzione efficiente e soddisfacente sarebbe quella di utilizzare una tabella in cui si memorizzano le informazioni del sensore (id, titolo, descrizione) e un'altra tabella in cui si memorizzano le letture del sensore. Assegni RAM sufficiente o spazio di archiviazione sufficientemente veloce (un SSD). Le tabelle sarebbero così:
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, per impostazione predefinita, utilizza un file flat per l'intero database/installazione. Ciò allevia il problema del superamento del limite del descrittore di file del sistema operativo / filesystem. Diversi, o addirittura decine di milioni di record non dovrebbero essere un problema se dovessi allocare 5-6 giga di RAM per mantenere in memoria il set di dati di lavoro, ciò ti consentirebbe un rapido accesso ai dati.
Se dovessi progettare un tale sistema, questo è il primo approccio che farei (personalmente). Da lì in poi è facile regolare a seconda di cosa devi fare con tali informazioni.
