Effektiv lagring af tidsseriedata:mySQL eller flade filer? Mange tabeller (eller filer) eller forespørgsler med WHERE-tilstand?

For at besvare dette spørgsmål skal vi først analysere det virkelige problem, du står over for.

Det virkelige problem ville være den mest effektive kombination af at skrive og hente data.

Lad os gennemgå dine konklusioner:

• tusindvis af tabeller - ja, det krænker formålet med databaser og gør det sværere at arbejde med. Du vinder heller ikke noget. Der er stadig disksøgning involveret, denne gang med mange filbeskrivelser i brug. Du skal også kende tabelnavnene, og der er tusindvis af dem. Det er også svært at udtrække data, hvilket er hvad databaser er til - at strukturere dataene på en sådan måde, at du nemt kan krydshenvise til posterne. Tusindvis af borde - ikke effektive fra perf. synspunkt. Ikke effektiv fra brugssynspunkt. Dårligt valg.

• en csv-fil - den er formentlig fremragende til at hente data, hvis du skal bruge hele indholdet på én gang. Men det er langt fra eksternt godt til at manipulere eller transformere dataene. I betragtning af det faktum, at du er afhængig af et bestemt layout - skal du være ekstra forsigtig, mens du skriver til CSV. Hvis dette vokser til tusindvis af CSV-filer, gjorde du ikke dig selv en tjeneste. Du fjernede al overhead af SQL (som ikke er så stor), men du gjorde intet for at hente dele af datasættet. Du har også problemer med at hente historiske data eller krydshenvise til noget. Dårligt valg.

Det ideelle scenarie ville være at kunne få adgang til enhver del af datasættet på en effektiv og hurtig måde uden nogen form for strukturændring.

Og det er netop grunden til, at vi bruger relationelle databaser, og hvorfor vi dedikerer hele servere med meget RAM til disse databaser.

I dit tilfælde bruger du MyISAM-tabeller (.MYD-filtypenavn). Det er et gammelt lagringsformat, der fungerede godt til low-end hardware, som blev brugt dengang. Men i disse dage har vi fremragende og hurtige computere. Derfor bruger vi InnoDB og tillader det at bruge meget RAM, så I/O omkostningerne reduceres. Den pågældende variabel, der styrer den, hedder innodb_buffer_pool_size - google, der vil give meningsfulde resultater.

For at besvare spørgsmålet - en effektiv, tilfredsstillende løsning ville være at bruge en tabel, hvor du gemmer sensoroplysninger (id, titel, beskrivelse) og en anden tabel, hvor du gemmer sensoraflæsninger. Du tildeler tilstrækkelig RAM eller tilstrækkelig hurtig lagring (en SSD). Tabellerne ville se sådan ud:

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 bruger som standard én flad fil til hele databasen/installationen. Det afhjælper problemet med at overskride fildeskriptorgrænsen for OS/filsystemet. Flere, eller endda titusinder af poster burde ikke være et problem, hvis du skulle allokere 5-6 gigs RAM til at opbevare arbejdsdatasættet i hukommelsen - det ville give dig hurtig adgang til dataene.

Hvis jeg skulle designe sådan et system, er dette den første tilgang, jeg ville lave (personligt). Derefter er det nemt at justere afhængigt af, hvad du skal gøre med disse oplysninger.