Aby odpowiedzieć na to pytanie, musimy najpierw przeanalizować prawdziwe problem, z którym się zmagasz.
Prawdziwym problemem byłaby najbardziej wydajna kombinacja zapisywania i pobierania danych.
Przyjrzyjmy się twoim wnioskom:
-
tysiące stołów - cóż, to narusza cel baz danych i utrudnia pracę. Nic też nie zyskujesz. Nadal jest zaangażowane wyszukiwanie dysku, tym razem z użyciem wielu deskryptorów plików. Musisz także znać nazwy stołów, a jest ich tysiące. Trudno jest również wyodrębnić dane, do czego służą bazy danych - aby ustrukturyzować dane w taki sposób, aby można było łatwo odwoływać się do rekordów. Tysiące stołów - nieefektywne z perf. punkt widzenia. Niewydajny z punktu widzenia użytkowania. Zły wybór.
-
plik csv - prawdopodobnie doskonale nadaje się do pobierania danych, jeśli potrzebujesz całej zawartości na raz. Ale daleko mu do zdalnego manipulowania lub przekształcania danych. Biorąc pod uwagę fakt, że polegasz na określonym układzie - musisz zachować szczególną ostrożność podczas pisania do CSV. Jeśli rozrośnie się do tysięcy plików CSV, nie wyświadczyłeś sobie przysługi. Usunąłeś cały narzut SQL (który nie jest tak duży), ale nie zrobiłeś nic dla pobierania części zbioru danych. Masz również problemy z pobieraniem danych historycznych lub odwoływaniem się do czegokolwiek. Zły wybór.
Idealnym scenariuszem byłaby możliwość uzyskania dostępu do dowolnej części zestawu danych w wydajny i szybki sposób bez jakiejkolwiek zmiany struktury.
I to jest dokładnie powód, dla którego używamy relacyjnych baz danych i przeznaczamy na nie całe serwery z dużą ilością pamięci RAM.
W twoim przypadku używasz tabel MyISAM (rozszerzenie pliku .MYD). Jest to stary format przechowywania, który świetnie sprawdzał się w przypadku sprzętu z niższej półki, który był używany w tamtych czasach. Ale w dzisiejszych czasach mamy doskonałe i szybkie komputery. Dlatego używamy InnoDB i pozwalamy na użycie dużej ilości pamięci RAM, aby zmniejszyć koszty I/O. Zmienna, która ją kontroluje, nazywa się innodb_buffer_pool_size - googlowanie, które przyniesie znaczące wyniki.
Aby odpowiedzieć na pytanie - wydajnym, satysfakcjonującym rozwiązaniem byłoby użycie jednej tabeli, w której przechowujesz informacje z czujnika (id, tytuł, opis) i drugiej tabeli, w której przechowujesz odczyty czujnika. Przydzielasz wystarczającą ilość pamięci RAM lub wystarczająco szybką pamięć masową (dysk SSD). Tabele wyglądałyby tak:
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 domyślnie używa jednego pliku płaskiego dla całej bazy danych/instalacji. To łagodzi problem przekroczenia limitu deskryptorów plików systemu operacyjnego / systemu plików. Kilka, a nawet dziesiątki milionów rekordów nie powinno stanowić problemu, jeśli przydzielisz 5-6 gigabajtów pamięci RAM do przechowywania zestawu danych roboczych w pamięci - to umożliwiłoby szybki dostęp do danych.
Gdybym miał zaprojektować taki system, to jest to pierwsze podejście, które bym zrobił (osobiście). Od tego momentu łatwo jest dostosować w zależności od tego, co musisz zrobić z tymi informacjami.
