この質問に答えるには、まず実際のを分析する必要があります あなたが直面している問題。
本当の問題は、データの書き込みと取得の最も効率的な組み合わせです。
結論を確認しましょう:
-
数千のテーブル -まあ、それはデータベースの目的に違反し、操作を難しくします。また、何も得られません。まだディスクシークが関係していますが、今回は多くのファイル記述子が使用されています。また、テーブル名を知っている必要があり、それらは何千もあります。また、データベースの目的であるデータを抽出することも困難です。レコードを簡単に相互参照できるようにデータを構造化することです。何千ものテーブル-パフォーマンスからは効率的ではありません。視点。使用の観点からは効率的ではありません。悪い選択です。
-
csvファイル -コンテンツ全体が一度に必要な場合は、データのフェッチに最適です。しかし、データの操作や変換にリモートで適しているとは言えません。特定のレイアウトに依存しているという事実を考えると、CSVへの書き込みには特に注意する必要があります。これが数千のCSVファイルに拡大した場合、あなたは自分自身を支持しませんでした。 SQLのオーバーヘッド(それほど大きくはありません)をすべて削除しましたが、データセットの一部を取得するために何もしませんでした。また、履歴データのフェッチや相互参照に問題があります。悪い選択です。
理想的なシナリオは、構造を変更することなく、効率的かつ迅速な方法でデータセットの任意の部分にアクセスできることです。
そして、これがまさに私たちがリレーショナルデータベースを使用する理由であり、大量のRAMを備えたサーバー全体をそれらのデータベース専用にする理由です。
あなたの場合、MyISAMテーブル(.MYDファイル拡張子)を使用しています。これは、当時使用されていたローエンドのハードウェアに最適な古いストレージ形式です。しかし、最近では、優れた高速のコンピューターがあります。そのため、InnoDBを使用し、大量のRAMを使用できるようにして、I/Oコストを削減しています。それを制御する問題の変数は、innodb_buffer_pool_size
と呼ばれます。 -意味のある結果を生み出すグーグル。
質問に答えるには、効率的で満足のいく解決策は、センサー情報(ID、タイトル、説明)を格納する1つのテーブルと、センサーの読み取り値を格納する別のテーブルを使用することです。十分な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は、デフォルトで、データベース/インストール全体に1つのフラットファイルを使用します。これにより、OS/ファイルシステムのファイル記述子の制限を超える問題が軽減されます。作業データセットをメモリに保持するために5〜6ギガのRAMを割り当てる場合、数、または数千万のレコードでさえ問題にはなりません。これにより、データにすばやくアクセスできます。
私がそのようなシステムを設計する場合、これは私が(個人的に)行う最初のアプローチです。そこから、その情報をどのように処理する必要があるかに応じて、簡単に調整できます。