Efektivní ukládání dat časových řad:mySQL nebo ploché soubory? Mnoho tabulek (nebo souborů) nebo dotazů s podmínkou WHERE?

Abychom na tuto otázku odpověděli, musíme nejprve analyzovat skutečné problém, kterému čelíte.

Skutečným problémem by byla nejúčinnější kombinace zápisu a načítání dat.

Pojďme se podívat na vaše závěry:

tisíce stolů - no, to porušuje účel databází a ztěžuje práci. Také nic nezískáte. Stále se jedná o vyhledávání disku, tentokrát s mnoha používanými deskriptory souborů. Musíte také znát názvy tabulek a jsou jich tisíce. Je také obtížné data extrahovat, k čemuž databáze slouží – strukturovat data takovým způsobem, abyste mohli snadno odkazovat na záznamy. Tisíce tabulek - neefektivní z výkonu. úhel pohledu. Neefektivní z hlediska použití. Špatná volba.
soubor csv - je pravděpodobně vynikající pro načítání dat, pokud potřebujete celý obsah najednou. Ale není to ani zdaleka dobré pro manipulaci nebo transformaci dat. Vzhledem k tomu, že se spoléháte na konkrétní rozložení, musíte být při psaní do CSV mimořádně opatrní. Pokud se to rozroste na tisíce souborů CSV, neudělali jste si laskavost. Odstranili jste veškerou režii SQL (která není tak velká), ale neudělali jste nic pro načtení částí datové sady. Máte také problémy s načítáním historických dat nebo s křížovými odkazy na cokoli. Špatná volba.

Ideálním scénářem by byla možnost přistupovat k jakékoli části datové sady účinným a rychlým způsobem bez jakékoli změny struktury.

A to je přesně důvod, proč používáme relační databáze a proč těmto databázím věnujeme celé servery s velkým množstvím paměti RAM.

Ve vašem případě používáte tabulky MyISAM (přípona souboru .MYD). Jedná se o starý formát úložiště, který skvěle fungoval pro hardware nižší třídy, který se dříve používal. Ale v dnešní době máme vynikající a rychlé počítače. To je důvod, proč používáme InnoDB a umožňujeme mu používat hodně paměti RAM, aby se snížily I/O náklady. Dotyčná proměnná, která ji řídí, se nazývá innodb_buffer_pool_size - googlování, které přinese smysluplné výsledky.

Abych odpověděl na otázku - efektivním a uspokojivým řešením by bylo použít jednu tabulku, kam ukládáte informace o senzoru (id, název, popis) a druhou tabulku, kam ukládáte hodnoty senzoru. Přidělíte dostatek paměti RAM nebo dostatečně rychlé úložiště (SSD). Tabulky by vypadaly takto:

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 standardně používá jeden plochý soubor pro celou databázi/instalaci. To zmírňuje problém překročení limitu deskriptoru souboru OS / souborového systému. Několik, nebo dokonce desítky milionů záznamů by neměly být problémem, pokud byste měli alokovat 5-6 GB RAM pro uložení pracovní sady dat v paměti – to by vám umožnilo rychlý přístup k datům.

Pokud bych takový systém navrhoval, je to první přístup, který bych (osobně) udělal. Odtud je snadné upravit podle toho, co s těmito informacemi potřebujete udělat.