1

時系列を使用して科学実験を行う必要があります。

MySQLデータストレージプラットフォームとして使用するつもりです。

次の一連のテーブルを使用してデータを保存することを考えています。

Table1--> ts_id(時系列インデックスを保存します。いくつかの時系列を処理する必要があります)

Table2--> ts_id, obs_date, value( で索引付けする必要があります{ts_idx,obs_date})

それぞれ数百万の観測値を持つ多くの時系列 (数百) があるため、表 2 は非常に大きくなる可能性があります。

問題は、この実験を数回繰り返さなければならないことです。

  1. テーブルに を追加しexperiment_idて、さらに大きくできるようにします。
  2. 実験ごとに個別のデータベースを作成します。

オプション 2 の方が優れている場合 (個人的にはそう思います)、これを行うための最良の論理的な方法は何でしょうか? 実行するさまざまな実験があり、それぞれに複製が必要です。レプリケーションごとに異なるデータベースを作成すると、すぐに数百のデータベースが作成されます。各レプリケーションをその実験の「サブデータベース」として論理的に編成する方法はありますmaster databaseか?

4

2 に答える 2

0

実験ごとに 1 つ、複数のデータベースが必要ですか?

あなたの質問に対する答えは、次の質問に対するあなたの答えにかかっています。ある実験を別の実験と比較する分析をたくさんしたいですか?

実験ごとに多くの比較を行う場合、実験ごとに個別のデータベースを用意するのは非常に骨の折れる作業です。

観測テーブルに実験 ID 列を追加するという提案は良いアイデアだと思います。このようにして、実験の全体的な説明を含む実験表を作成できます。そのテーブルは、値の列に観測単位 (温度、電圧など) を保持することもできます。

複数の実験の何らかの複雑な編成がある場合は、その編成を実験テーブルに格納できます。

MySQL は、短い行のデータを処理するのに非常に効率的であることに注意してください。数十時間の労力で優れたサーバーを購入するか、数時間の労力でクラウド サービスでサーバーをレンタルできます。

また、MySQL が MERGE ストレージ エンジンを提供していることにも注意してください。 http://dev.mysql.com/doc/refman/5.5/en/merge-storage-engine.html これにより、同じ列構造を持つ一連の異なるテーブルに、1 つのテーブルであるかのようにアクセスできます。これにより、個々の実験またはそれらのグループの結果を独自のテーブルに保存し、それらにまとめてアクセスできます。データ収集システムのスケールアップに問題がある場合は、これを検討することをお勧めします。しかし、良いニュースは、データベースを機能させてから、これに変換できることです。

もう 1 つの質問: ts_id 値しかないテーブルがあるのはなぜですか? わかりません。

于 2012-07-27T13:05:09.170 に答える
0

データをどのように分析する必要があるかを検討することから始めたいと思うかもしれません。

おそらく、分析では、実験名、実験の複製数、内部複製について知る必要があります (たとえば、各時点で、各治療について測定された 3 つの「同一の」被験者が存在します)。したがって、db スキーマは次のようになります。

experiments

exp_id int unsigned not null auto_increment primary key,
exp_name varchar(45)
other fields that any kind of experiment can have

replicates

rep_id  int unsigned not null auto_increment primary key,
exp_id int unsigned not null foreign key to experiments
other fields that any kind of experiment replica can have

subjects

subject_id int unsigned not null auto_increment primary key,
subject_name varchar(45),
other fields that any kind of subject can have

observations

ob_id int unsigned not null auto_increment primary key,
rep_id  int unsigned not null foreign key to replicates,
subject_id int unsigned not null foreign key to subjects,
ob_time timestamp
other fields to hold the measurements you make at each timepoint

内部レプリケートがある場合は、内部レプリケートとサブジェクトの関係を保持する別のテーブルが必要になります。

何百万もの行について心配する必要はありません。適切にインデックスを作成している限り、問題は発生しません。しかし、最悪の事態が発生した場合は、観測テーブル (最大になる可能性が高い) をいつでも分割できますrep_id。

于 2012-07-27T13:17:40.597 に答える