Um diese Frage zu beantworten, müssen wir zuerst die Wirklichkeit analysieren Problem, mit dem Sie konfrontiert sind.
Das eigentliche Problem wäre die effizienteste Kombination aus Schreiben und Abrufen von Daten.
Sehen wir uns Ihre Schlussfolgerungen an:
-
Tausende Tabellen - Nun, das verstößt gegen den Zweck von Datenbanken und macht es schwieriger, damit zu arbeiten. Sie gewinnen auch nichts. Es ist immer noch eine Festplattensuche erforderlich, diesmal mit vielen verwendeten Dateideskriptoren. Sie müssen auch die Tabellennamen kennen, und davon gibt es Tausende. Es ist auch schwierig, Daten zu extrahieren, wofür Datenbanken da sind – um die Daten so zu strukturieren, dass Sie die Datensätze leicht mit Querverweisen versehen können. Tausende von Tischen - nicht effizient von der Leistung. Standpunkt. Aus Nutzungssicht nicht effizient. Schlechte Wahl.
-
eine CSV-Datei - Es ist wahrscheinlich hervorragend zum Abrufen der Daten geeignet, wenn Sie den gesamten Inhalt auf einmal benötigen. Aber es ist alles andere als gut, um die Daten zu manipulieren oder zu transformieren. Angesichts der Tatsache, dass Sie sich auf ein bestimmtes Layout verlassen, müssen Sie beim Schreiben in CSV besonders vorsichtig sein. Wenn dies auf Tausende von CSV-Dateien anwächst, haben Sie sich keinen Gefallen getan. Sie haben den gesamten Overhead von SQL (der nicht so groß ist) entfernt, aber Sie haben nichts unternommen, um Teile des Datensatzes abzurufen. Sie haben auch Probleme, historische Daten abzurufen oder Querverweise zu erstellen. Schlechte Wahl.
Das ideale Szenario wäre, ohne jegliche Strukturänderung effizient und schnell auf jeden Teil des Datensatzes zugreifen zu können.
Und genau aus diesem Grund verwenden wir relationale Datenbanken und widmen diesen Datenbanken ganze Server mit viel RAM.
In Ihrem Fall verwenden Sie MyISAM-Tabellen (Dateierweiterung .MYD). Es handelt sich um ein altes Speicherformat, das sich hervorragend für Low-End-Hardware eignete, die damals verwendet wurde. Aber heutzutage haben wir ausgezeichnete und schnelle Computer. Aus diesem Grund verwenden wir InnoDB und erlauben ihm, viel RAM zu verwenden, damit die I/O-Kosten reduziert werden. Die fragliche Variable, die sie steuert, heißt innodb_buffer_pool_size - googeln, das aussagekräftige Ergebnisse liefert.
Um die Frage zu beantworten:Eine effiziente, zufriedenstellende Lösung wäre die Verwendung einer Tabelle, in der Sie Sensorinformationen (ID, Titel, Beschreibung) speichern, und einer anderen Tabelle, in der Sie Sensormesswerte speichern. Sie weisen ausreichend RAM oder ausreichend schnellen Speicher (eine SSD) zu. Die Tabellen würden wie folgt aussehen:
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 verwendet standardmäßig eine Flatfile für die gesamte Datenbank/Installation. Dadurch wird das Problem der Überschreitung der Dateideskriptorgrenze des Betriebssystems / Dateisystems verringert. Mehrere oder sogar zig Millionen Datensätze sollten kein Problem darstellen, wenn Sie 5-6 GB RAM zuweisen würden, um den Arbeitsdatensatz im Speicher zu halten - das würde Ihnen einen schnellen Zugriff auf die Daten ermöglichen.
Wenn ich ein solches System entwerfen würde, wäre dies der erste Ansatz, den ich (persönlich) machen würde. Von da an ist es einfach anzupassen, je nachdem, was Sie mit diesen Informationen tun müssen.
