Effektiv lagring av tidsseriedata:mySQL eller platta filer? Många tabeller (eller filer) eller frågor med WHERE-villkor?

För att svara på denna fråga måste vi först analysera det verkliga problem du står inför.

Det verkliga problemet skulle vara den mest effektiva kombinationen av att skriva och hämta data.

Låt oss granska dina slutsatser:

tusentals tabeller - Tja, det bryter mot syftet med databaser och gör det svårare att arbeta med. Du vinner heller ingenting. Det finns fortfarande disksökning inblandat, denna gång med många filbeskrivningar som används. Du måste också känna till tabellnamnen, och det finns tusentals av dem. Det är också svårt att extrahera data, vilket är vad databaser är till för - att strukturera data på ett sådant sätt att du enkelt kan korsreferens posterna. Tusentals bord - inte effektivt från perf. synpunkt. Inte effektivt ur användningssynpunkt. Dåligt val.
en csv-fil - det är förmodligen utmärkt för att hämta data, om du behöver hela innehållet på en gång. Men det är långt ifrån bra för att manipulera eller omvandla data. Med tanke på att du förlitar dig på en specifik layout - måste du vara extra försiktig när du skriver till CSV. Om detta växer till tusentals CSV-filer, gjorde du inte dig själv en tjänst. Du tog bort all overhead av SQL (som inte är så stor) men du gjorde ingenting för att hämta delar av datamängden. Du har också problem med att hämta historisk data eller korsreferenser något. Dåligt val.

Det ideala scenariot skulle vara att kunna komma åt vilken del av datamängden som helst på ett effektivt och snabbt sätt utan någon form av strukturförändring.

Och detta är precis anledningen till att vi använder relationsdatabaser och varför vi dedikerar hela servrar med mycket RAM till dessa databaser.

I ditt fall använder du MyISAM-tabeller (filtillägget .MYD). Det är ett gammalt lagringsformat som fungerade utmärkt för hårdvara i låg kvalitet som användes förr i tiden. Men nuförtiden har vi utmärkta och snabba datorer. Det är därför vi använder InnoDB och låter den använda mycket RAM så att I/O-kostnaderna minskar. Variabeln i fråga som styr den kallas innodb_buffer_pool_size - googling som ger meningsfulla resultat.

För att svara på frågan - en effektiv, tillfredsställande lösning skulle vara att använda en tabell där du lagrar sensorinformation (id, titel, beskrivning) och en annan tabell där du lagrar sensoravläsningar. Du tilldelar tillräckligt med RAM eller tillräckligt snabb lagring (en SSD). Tabellerna skulle se ut så här:

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 använder som standard en platt fil för hela databasen/installationen. Det lindrar problemet med att överskrida filbeskrivningsgränsen för operativsystemet/filsystemet. Flera, eller till och med tiotals miljoner poster borde inte vara ett problem om du skulle allokera 5-6 gig RAM för att hålla arbetsdatauppsättningen i minnet - det skulle ge dig snabb åtkomst till datan.

Om jag skulle designa ett sådant system är detta det första tillvägagångssättet jag skulle göra (personligen). Därefter är det enkelt att justera beroende på vad du behöver göra med den informationen.