Om deze vraag te beantwoorden, moeten we eerst de echte . analyseren probleem waarmee u wordt geconfronteerd.
Het echte probleem zou de meest efficiënte combinatie zijn van het schrijven en ophalen van gegevens.
Laten we uw conclusies eens bekijken:
-
duizenden tafels - nou, dat schendt het doel van databases en maakt het moeilijker om mee te werken. Je wint er ook niets mee. Er is nog steeds sprake van het zoeken naar schijven, deze keer met veel bestandsdescriptors in gebruik. Je moet ook de tafelnamen kennen, en er zijn er duizenden. Het is ook moeilijk om gegevens te extraheren, waar databases voor zijn - om de gegevens zo te structureren dat u gemakkelijk naar de records kunt verwijzen. Duizenden tafels - niet efficiënt van perf. standpunt. Niet efficiënt vanuit het oogpunt van gebruik. Slechte keuze.
-
een csv-bestand - het is waarschijnlijk uitstekend geschikt voor het ophalen van de gegevens, als u de volledige inhoud in één keer nodig hebt. Maar het is verre van goed voor het manipuleren of transformeren van de gegevens. Aangezien u afhankelijk bent van een specifieke lay-out, moet u extra voorzichtig zijn bij het schrijven naar CSV. Als dit uitgroeit tot duizenden CSV-bestanden, heb je jezelf geen plezier gedaan. Je hebt alle overhead van SQL verwijderd (wat niet zo groot is), maar je hebt niets gedaan om delen van de dataset op te halen. Je hebt ook problemen met het ophalen van historische gegevens of met het verwijzen naar iets. Slechte keuze.
Het ideale scenario zou zijn om op een efficiënte en snelle manier toegang te krijgen tot elk deel van de dataset zonder enige vorm van structuurverandering.
En dit is precies de reden waarom we relationele databases gebruiken en waarom we hele servers met veel RAM aan die databases toewijzen.
In jouw geval gebruik je MyISAM-tabellen (bestandsextensie .MYD). Het is een oud opslagformaat dat prima werkte voor low-end hardware die vroeger werd gebruikt. Maar tegenwoordig hebben we uitstekende en snelle computers. Daarom gebruiken we InnoDB en laten we het veel RAM gebruiken, zodat de I/O-kosten worden verlaagd. De variabele in kwestie die deze regelt, heet innodb_buffer_pool_size - Googlen dat zinvolle resultaten oplevert.
Om de vraag te beantwoorden:een efficiënte, bevredigende oplossing zou zijn om één tabel te gebruiken waarin u sensorinformatie (id, titel, beschrijving) opslaat en een andere tabel waarin u sensormetingen opslaat. Je wijst voldoende RAM of voldoende snelle opslag toe (een SSD). De tabellen zien er als volgt uit:
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 gebruikt standaard één plat bestand voor de hele database/installatie. Dat verlicht het probleem van het overschrijden van de bestandsdescriptorlimiet van het besturingssysteem / bestandssysteem. Meerdere of zelfs tientallen miljoenen records zouden geen probleem moeten zijn als je 5-6 gigabyte RAM zou toewijzen om de werkende dataset in het geheugen te bewaren - dat zou je snel toegang geven tot de data.
Als ik zo'n systeem zou ontwerpen, is dit de eerste benadering die ik (persoonlijk) zou maken. Vanaf daar is het gemakkelijk aan te passen, afhankelijk van wat je met die informatie moet doen.