За да отговорим на този въпрос, първо трябва да анализирамеистинското проблем, с който се сблъсквате.
Истинският проблем би бил най-ефективната комбинация от писане и извличане на данни.
Нека прегледаме вашите заключения:
-
хиляди таблици - Е, това нарушава целта на базите данни и затруднява работата с тях. Вие също не печелите нищо. Все още има търсене на диск, този път с много използвани файлови дескриптори. Трябва също да знаете имената на таблиците, а те са хиляди. Също така е трудно да се извличат данни, за което са предназначени базите данни - да се структурират данните по такъв начин, че да можете лесно да правите кръстосани препратки към записите. Хиляди маси - не е ефективно от перф. гледна точка. Не е ефективно от гледна точка на употреба. Лош избор.
-
csv файл - вероятно е отличен за извличане на данните, ако имате нужда от цялото съдържание наведнъж. Но далеч не е далеч добър за манипулиране или трансформиране на данните. Предвид факта, че разчитате на конкретно оформление - трябва да бъдете особено внимателни, докато пишете в CSV. Ако това нарасне до хиляди CSV файлове, не сте си направили услуга. Премахнахте всички допълнителни разходи за SQL (които не са толкова големи), но не сте направили нищо за извличането на части от набора от данни. Също така имате проблеми с извличането на исторически данни или кръстосаното препращане към нещо. Лош избор.
Идеалният сценарий би бил възможността за достъп до всяка част от набора от данни по ефективен и бърз начин без каквато и да е промяна в структурата.
И точно това е причината да използваме релационни бази данни и защо посвещаваме цели сървъри с много RAM за тези бази данни.
Във вашия случай използвате MyISAM таблици (файлово разширение .MYD). Това е стар формат за съхранение, който работи чудесно за хардуер от нисък клас, който е бил използван през деня. Но в наши дни имаме отлични и бързи компютри. Ето защо ние използваме InnoDB и му позволяваме да използва много RAM, така че разходите за I/O са намалени. Въпросната променлива, която я контролира, се нарича innodb_buffer_pool_size - Google, което ще даде значими резултати.
За да отговорите на въпроса - ефективно и задоволително решение би било да използвате една таблица, където съхранявате информация за сензора (идентификатор, заглавие, описание) и друга таблица, където съхранявате показанията на сензора. Разпределяте достатъчно RAM или достатъчно бързо съхранение (SSD). Таблиците ще изглеждат така:
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 по подразбиране използва един плосък файл за цялата база данни/инсталация. Това облекчава проблема с превишаването на ограничението на файловия дескриптор на операционната система / файловата система. Няколко или дори десетки милиони записа не би трябвало да представляват проблем, ако разпределите 5-6 гига RAM за съхраняване на работния набор от данни в паметта – това ще ви позволи бърз достъп до данните.
Ако трябваше да проектирам такава система, това е първият подход, който бих използвал (лично). Оттам нататък е лесно да се коригира в зависимост от това какво трябва да правите с тази информация.
