0

現在、私は1つのテーブルを持っており、それは非常に速く移入されています。私は50台のデバイスを持っています。30秒ごとに各デバイスからデータを収集します。したがって、10,000台のデバイスを追加すると、1か月あたり8億7600万件のレコードが生成されます。これは膨大な量です。

INSERT INTO unit_data
(`id`,`dt`,`id_unit`,`data1`,`data2`,
`ip`,`unique_id`,`loc_age`,`reason_code`,
`data3`,`data4`,`Odo`,`event_time_gmt_unix`,
`switches`,`on_off`,`data5`)

これが私の関係です

  PRIMARY KEY (`id`),
  UNIQUE KEY `id_unit_data_UNIQUE` `id`),
  KEY `fk_gp2` (`id_unit`),
  KEY `unit_dt_id` (`dt`,`id_unit`),
  KEY `unit_id_dt` (`id_unit`,`dt`),
  CONSTRAINT `fk_gp2` FOREIGN KEY (`id_unit`) REFERENCES `unit` (`id_unit`) ON DELETE CASCADE ON UPDATE CASCADE
) ENGINE=InnoDB AUTO_INCREMENT=1049392 DEFAULT CHARSET=utf8$$

非常に複雑なクエリとレポートに直面していますが、それらを実行すると、システムが応答せず、実行タイムアウトになります。（これは2mil以上のレコードです）

データベース構造を再考して再実装する必要があります。そして現在、私はどちらかについて考えています

  • ユニットごとに新しいテーブルを作成します
  • Create new table for each unit for each month

What would you suggest?

4

1 に答える 1

0

新しいテーブルを作成するのは良い考えですが、それを実装する必要はありません。MySql には既にそのようなツールがあります。キーワード「mysql+partitioning」で検索してください。クエリを変更する必要がないため、使用することをお勧めします.mysql自体がそれを気にします. create table ステートメントに「partition by」キーワードを追加するだけです。

もう 1 つ、大きなテーブルに大量の情報を収集し、そこからいくつかのデータを選択することをお勧めします。しかし、多くの新しい行を挿入すると、テーブルがロックされ (選択には使用できなくなります)、インデックスが再構築されます (テーブルにインデックスが作成されているはずです)。私の現在のプロジェクトでは、あなたと同様のことを行っています。次のことをお勧めします。

1) BIG-TABLE のテーブルクローンを作成します。BIG-TABLE と同じ構造を持つ必要がありますが、1 つの違いがあります。table-clone にはインデックスがありません。

2）デバイスからデータを受信したら、それをテーブルクローンに入れます。

3) 小さなテーブルから大きなテーブルにレコードを毎時間または毎日配置するロボットエージェントを作成します。索引付けされていません)。

4) SELECT クエリを実行する場合は、2 つのテーブル (インデックス付きの BIG テーブル) で実行します。これは、誰もデータを挿入しようとしないため (ロボットだけが時々行う)、小さなテーブルでのフルスキャンも十分に高速です。小さく保つことができます。

5) ロボットは穏やかな時間に起床する必要があります c- 夜かもしれません。

于 2013-03-13T11:52:33.807 に答える