Ответ 1
Чтобы ответить на этот вопрос, мы должны сначала проанализировать проблему реального, с которой вы столкнулись.
Реальная проблема будет самой эффективной комбинацией написания и извлечения данных.
Давайте рассмотрим ваши выводы:
-
тысячи таблиц - ну, это нарушает назначение баз данных и затрудняет работу. Вы также ничего не получаете. По-прежнему существует поиск дисков, на этот раз с использованием многих дескрипторов файлов. Вы также должны знать имена таблиц, а там тысячи. Также сложно извлечь данные, для чего предназначены базы данных, - структурировать данные таким образом, чтобы вы могли легко перекрестно ссылаться на записи. Тысячи столов - не эффективны от перфорации. точка зрения. Неэффективна с точки зрения использования. Плохой выбор.
-
файл csv - он, вероятно, отлично подходит для сбора данных, если вам нужно полное содержимое сразу. Но это далеко не удалённо полезно для манипулирования или преобразования данных. Учитывая тот факт, что вы полагаетесь на конкретный макет, вы должны быть очень осторожны при записи в CSV. Если это вырастет до тысяч CSV файлов, вы не сделаете одолжение. Вы удалили все накладные расходы SQL (что не так уж и много), но вы ничего не сделали для извлечения частей набора данных. У вас также есть проблемы с получением исторических данных или перекрестной ссылкой на что-либо. Плохой выбор.
Идеальный сценарий будет иметь возможность доступа к любой части набора данных эффективным и быстрым способом без какого-либо изменения структуры.
И именно поэтому мы используем реляционные базы данных и почему мы выделяем целые серверы с большим количеством ОЗУ для этих баз данных.
В вашем случае вы используете таблицы MyISAM (расширение файла .MYD).
Это старый формат хранения, который отлично подойдет для низкопроизводительного оборудования, которое использовалось в тот же день. Но в наши дни у нас отличные и быстрые компьютеры. Поэтому мы используем InnoDB и позволяем ему использовать много оперативной памяти, поэтому затраты на ввод-вывод сокращаются. Эта переменная, которая ее контролирует, называется innodb_buffer_pool_size - googling, которая даст значимые результаты.
Чтобы ответить на вопрос - эффективным, выполнимым решением будет использование одной таблицы, в которой вы храните информацию о датчике (идентификатор, название, описание) и другую таблицу, в которой хранятся показания датчика. Вы выделяете достаточное количество оперативной памяти или достаточно быстрое хранилище (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 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 гигабайт ОЗУ для хранения рабочего набора данных в памяти - это позволит вам быстро получить доступ к данным.
Если бы я планировал такую систему, это первый подход, который я сделал бы (лично). Оттуда это легко настраивается в зависимости от того, что вам нужно делать с этой информацией.