2

1 時間ごとの温度測定値は、動物保護施設のいくつかの動物ケージから 30 分ごとに収集され、ファイルにダンプされます。cron はそのデータを処理し、MYSQL データベースに挿入します。現在、その日の 48 の温度測定値はすべて 1 つのテーブルに保存されており、データが入ってくると更新されます。レコードが存在しない場合は、最初の温度を保存する新しいレコードが作成されます。

現在、ケージ情報用のテーブルとケージ温度測定値用のテーブルがあります。ケージの総数は 45 です。データの量は 7 年 (約 2557 日) です。温度テーブルの合計レコード数: 115,065

システムに別の場所と追加のケージを追加するため、ケージの総数は 1,000 を超えます。私たちは、データの使用が非常に急速に拡大すると予想しています。

読み取り速度を最適化するために、以下のテーブルを構造化するより効率的な方法はありますか? データは、毎朝表示されるすべてのケージのグラフを生成するために使用され、ケージ内の不十分な換気をチェックするために 30 分の cron が生成されます。

現在の温度表は次のとおりです。

CREATE TABLE `temperature_readings` (
  `CAGE_ID` int(10) NOT NULL DEFAULT '0',
  `INT_VALUE_0000` decimal(5,2) DEFAULT NULL,
  `INT_VALUE_0030` decimal(5,2) DEFAULT NULL,
  `INT_VALUE_0100` decimal(5,2) DEFAULT NULL,
  `INT_VALUE_0130` decimal(5,2) DEFAULT NULL,
  `INT_VALUE_0200` decimal(5,2) DEFAULT NULL,
  `INT_VALUE_0230` decimal(5,2) DEFAULT NULL,
  `INT_VALUE_0300` decimal(5,2) DEFAULT NULL,
  `INT_VALUE_0330` decimal(5,2) DEFAULT NULL,
  `INT_VALUE_0400` decimal(5,2) DEFAULT NULL,
  `INT_VALUE_0430` decimal(5,2) DEFAULT NULL,
  `INT_VALUE_0500` decimal(5,2) DEFAULT NULL,
  `INT_VALUE_0530` decimal(5,2) DEFAULT NULL,
  `INT_VALUE_0600` decimal(5,2) DEFAULT NULL,
  `INT_VALUE_0630` decimal(5,2) DEFAULT NULL,
  `INT_VALUE_0700` decimal(5,2) DEFAULT NULL,
  `INT_VALUE_0730` decimal(5,2) DEFAULT NULL,
  `INT_VALUE_0800` decimal(5,2) DEFAULT NULL,
  `INT_VALUE_0830` decimal(5,2) DEFAULT NULL,
  `INT_VALUE_0900` decimal(5,2) DEFAULT NULL,
  `INT_VALUE_0930` decimal(5,2) DEFAULT NULL,
  `INT_VALUE_1000` decimal(5,2) DEFAULT NULL,
  `INT_VALUE_1030` decimal(5,2) DEFAULT NULL,
  `INT_VALUE_1100` decimal(5,2) DEFAULT NULL,
  `INT_VALUE_1130` decimal(5,2) DEFAULT NULL,
  `INT_VALUE_1200` decimal(5,2) DEFAULT NULL,
  `INT_VALUE_1230` decimal(5,2) DEFAULT NULL,
  `INT_VALUE_1300` decimal(5,2) DEFAULT NULL,
  `INT_VALUE_1330` decimal(5,2) DEFAULT NULL,
  `INT_VALUE_1400` decimal(5,2) DEFAULT NULL,
  `INT_VALUE_1430` decimal(5,2) DEFAULT NULL,
  `INT_VALUE_1500` decimal(5,2) DEFAULT NULL,
  `INT_VALUE_1530` decimal(5,2) DEFAULT NULL,
  `INT_VALUE_1600` decimal(5,2) DEFAULT NULL,
  `INT_VALUE_1630` decimal(5,2) DEFAULT NULL,
  `INT_VALUE_1700` decimal(5,2) DEFAULT NULL,
  `INT_VALUE_1730` decimal(5,2) DEFAULT NULL,
  `INT_VALUE_1800` decimal(5,2) DEFAULT NULL,
  `INT_VALUE_1830` decimal(5,2) DEFAULT NULL,
  `INT_VALUE_1900` decimal(5,2) DEFAULT NULL,
  `INT_VALUE_1930` decimal(5,2) DEFAULT NULL,
  `INT_VALUE_2000` decimal(5,2) DEFAULT NULL,
  `INT_VALUE_2030` decimal(5,2) DEFAULT NULL,
  `INT_VALUE_2100` decimal(5,2) DEFAULT NULL,
  `INT_VALUE_2130` decimal(5,2) DEFAULT NULL,
  `INT_VALUE_2200` decimal(5,2) DEFAULT NULL,
  `INT_VALUE_2230` decimal(5,2) DEFAULT NULL,
  `INT_VALUE_2300` decimal(5,2) DEFAULT NULL,
  `INT_VALUE_2330` decimal(5,2) DEFAULT NULL,
  PRIMARY KEY (`CAGE_ID`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8;

私の考えは、複数の温度測定値を次のような halfhour_read テーブルに正規化することでした

halfhour_read{
 - cage_id
 - datetime
 - temperature reading
}

または、それがパーティション化されるように、cage_id または今日 (日付) のいずれかで temperature_readings をハッシュします。

私が理解している限り、最初のオプションはレコード数を 115,065 から 5,523,120 に増やし、比較すると急速に増加し、将来のスペースの問題を引き起こします。

4

2 に答える 2

5

はい、構造を正規化します。おもしろいので、現在の構造で次のクエリを書いてみてください: ケージ A の先週の最高気温は何度でしたか?

本能に従って、次の構造を使用してください。

CREATE TABLE readings (
    cage_id INT,
    dateofreading DATETIME,
    temperature DECIMAL(10,2),
    PRIMARY KEY (cage_id, dateofreading),
    INDEX (dateofreading, cage_id) -- suggested index, useful for time-based queries
)

予想される行サイズ (データのみ): 4 + 8 + 4 = 16 バイト。

16 バイト x 1 日あたり 48 回の読み取り x 10,000 ケージ x 365 日 = 1 年あたり 2.6 GB。必要に応じて、3 または 4 を掛けてインデックスを作成します。とにかく、収納スペースには困りません。

このテーブルからのデータの抽出は、数十億のレコードが含まれている場合でも、適切なインデックスのおかげで事実上瞬時に行われます。ワーキング セット (過去数週間のデータ) は、おそらく常にメモリに収まります。

(そして、要件が「毎日 4,800,000 回の読み取りを行う 100,000 個のケージ」である場合、主な関心事はストレージ スペースではなく、1 秒あたり数百万回の挿入を処理することです)

そして、作業データセットを妥当なサイズに保つには、はい、テーブルを分割するか、古いレコードを時々アーカイブテーブルに移動してください.

于 2013-10-06T09:41:41.630 に答える
1

ほとんど間違いなく正規化します...しかし、より大きなディスクが必要になります:-)

実際には、500 万の短い行は実際には多くのデータではありません。MySQL はそれ以上のことを処理できます。500 万reading行は 100MB のオーダーになります。

履歴データは変更されないため、年ごとにデータを分割することも検討する必要があります。

于 2013-10-06T07:34:27.237 に答える