異なる頻度で記録されたデータを保存する方法は？
私は、さまざまな周波数で記録されたデータ（電気パラメーター）を格納する必要がある冶金学的Webアプリケーションを作成しています。例えば：
- 1秒あたり1小節の頻度で記録された6つのパラメーター
- 1秒あたり10小節の頻度で記録された3つのパラメーター。
（すべてのパラメーターは、小数点に続く6桁の10進数です-DECIMAL(10,6)）。
そのような値を効率的に格納するには、データベース構造をどのように設計すればよいですか？そして、この種のデータセットを簡単にクエリして、あらゆる種類のグラフに表示できるようにするには、
可能性（アイデア？）
両方のパラメーターセットを2つの異なるテーブルに保存し、対応する時間単位ごとに1つのレコードを使用し、すべてのパラメーターを上記のように宣言された列（10進数）に保存し、描画されたグラフの各ポイントごとに最初のテーブルから1つのレコードと2番目のテーブルから10つのレコードをクエリします。 1秒あたり11レコードになる。
1秒あたり1レコードですべてのパラメーターを1つのテーブルに格納し、最初のグループの各パラメーターを10進数の列に格納し、2番目のグループの各パラメーターを10進数の配列として格納し、描画されたグラフの各ポイントごとにのみ、このテーブルから1つのレコードをクエリします。 1秒あたり1レコードになる。
何か違う（上記の両方が間違っている場合）。
パフォーマンスが向上し、データの冗長性が低下するという点で、どのソリューションがより優れているかわかりません。
最初のソリューションは、毎秒11レコードの測定値があるため（そして毎秒数千のデバイスが測定値を取得している場合でも対処できるため）、データベーススペースをより多く消費するようですが、同時に解析が高速であるように見えます。各レコードおよび各列の各値に直接アクセスできます。一方、2番目のケースでは、データベースサイズを大幅に小さくする必要があります（1秒ごとに1つのレコードと各デバイスがあるため）。このデータの解析は、1秒あたり10個の値の配列と、 1/100 ms周波数.
私の（上記の）仮定が正しい場合、この質問は答えに絞られます。今日のデータベース設計で何がより重要ですか-データベースサイズまたは解析時間？低コストのソリューション（共有ホスティングや低ハードウェアVPSなど）の場合、データベースのサイズがはるかに重要であるため、2番目のオプションを検討します。
私は主にMySQLの使用に焦点を当てていますが、別のRDBMSを使用する利点がある場合は、他のほぼすべての種類のデータベースを受け入れることができます。
追加情報：
パラメータの2番目のグループ（つまり、1/100 msの周波数で記録されたもの）の場合、DBマイクロタイムに保存する必要はありません（少なくとも私の場合）。それらは、他のパラメーター（1/1秒の周波数で記録された）が格納されるその「秒」（タイムスタンプ）に正しくリンクする必要があるだけです。
各パラメータをデータベースの個別のレコードに保存する必要はありません。私のアイデアが示すように、すべてのパラメーターは、各メジャーごとに1つのレコードに格納できます。
おそらく最も簡単な解決策は、1/10秒のデータをキャッシュに収集し、到着時に1秒のファクトでそれらを書き込むことです。両方の値を同時に保存することで、サマリーテーブルと関連するクリーンアップタスクの処理の複雑さがなくなります。 1/10の値を処理する良い方法は、すべてのサンプルを追加し、1秒のファクトが到着したときに収集された＃で除算することです。スパイクなどの情報の1/10秒の値に応じて、min、max、stddevなどの1/10のファクトに関する他の統計も保持できます。テーブル設計の例は次のようになります：fact 1 is the 1 sec fact 2 is the 1/10th sectimestamp fact_1 fact_2_avg fact_2_min fact_2_max fact_2_count fact_2_stddev
これが整ったら、必要なデータの細分性を検討し、データベースに書き込む前に両方の値をロールアップすることを検討してください。毎分、5分、またはテーブルで構成されている時間だけを書き込むことができます。
また、システムが数か月または数年稼働するため、2012年3月15日の12：03.55の値を知る必要があるかどうかを検討することもできます。必要がない場合は、MRTGに表示されるような24時間のライブビュー、1週間のビューで5分の要約、30日で1時間のビューなどの要約レベルを検討してください。これにより、年間3100万行のデータをクエリすることなく、データを保持し、高速なパフォーマンスと傾向の監視を維持できます。
このようなデータを処理するもう1つの方法は、24時間ローリングテーブルであるテーブルを使用することです。キーは、時、分、秒を使用し、日付は使用しません。このようにして、24時間無料のローリングテーブルがあります。ギャップに注意してください（最後のサンプルとこのサンプルの間のデータはきれいなので、データの収集中に1〜2秒を逃した場合、挿入された値の間に古いデータはありません）。挿入ではなく更新と考えると、このテーブルがどのように機能するかを理解できます。