2016-09-05 5 views
0

タイムスタンプが大きく成長するデータストアを考慮して日付間の範囲内にあるかどうかをテストする最も効果的な方法は何ですか?タイムスタンプが範囲内にあるかどうかをテストする最も効果的な方法

セットアップ

は基本的に私はテーブルに持っています。密度が1分当たりのセンサデータの場合は(A)であり、変化が監視されるテーブルの場合は1つだけです。

は、1分ごとにすべてのセンサーデータが保存され、絶え間なく成長する表です。データはこの密度で格納され、圧縮できないという要件です。

+-----------+------------------------+-------+ 
| sensor_id |  datetime  | value | 
+-----------+------------------------+-------+ 
|   1 | 2016-08-22 17:26:00 | 23 | 
|   1 | 2016-08-22 17:27:00 |  5 | 
|   1 | 2016-08-22 17:28:00 | 12 | 
|   1 | 2016-08-22 17:29:00 |  0 | 
|   1 | 2016-08-22 17:30:00 | 150 | 
|   1 | 2016-08-22 17:31:00 |  9 | 
+-----------+------------------------+-------+ 

Bセンサからのすべての状態変化を監視しているテーブルです。これらのイベントは無作為に発生する可能性があり、毎分ではありません。

+-----------+------------------------+----------+ 
| sensor_id |  datetime  | state | 
+-----------+------------------------+----------+ 
|   1 | 2016-08-22 17:26:00 | up  | 
|   1 | 2016-08-22 17:29:00 | down  | 
|   1 | 2016-08-22 17:31:00 | shutdown | 
+-----------+------------------------+----------+ 

結果

今私は、テーブルA

+-----------+------------------------+-------+----------+ 
| sensor_id |  datetime  | value | state | 
+-----------+------------------------+-------+----------+ 
|   1 | 2016-08-22 17:26:00 | 23 | up  | 
|   1 | 2016-08-22 17:27:00 |  5 | up  | 
|   1 | 2016-08-22 17:28:00 | 12 | up  | 
|   1 | 2016-08-22 17:29:00 |  0 | down  | 
|   1 | 2016-08-22 17:30:00 | 150 | down  | 
|   1 | 2016-08-22 17:31:00 |  9 | shutdown | 
+-----------+------------------------+-------+----------+ 

問題

のように見えるテーブルBから対応する状態の各データのためにマッピングします両方のテーブルのデータは、複数のセンサーのために常に増加しています。例えば、1ヶ月間のすべての値と1つのセンサを保持すると、のデータポイントになります。センサーの数を増やすと、両方のテーブルのデータポイント数も増加し、マッピングが遅くなり、遅くなります。

テーブルAのタイムスタンプが、店舗が何百万というデータポイントに達しているときのテーブルBの状態かどうかを確認するにはどうすればよいですか?私はAから各単一のポイントを取って、数百万のデータポイントを持つことができるテーブルBから一致する状態を調べなければならないだろうと私は、これが非常に遅くて不安定になると推測しています。私は分析のためにリアルタイムでこれを行う必要があります!

Thxをは

+0

インデックスについて知っていますか? –

+0

私はそれらを使用していますが、この議論は、この問題のgenerel用語とデータストアの選択のほうがもっと重要です。 – Jay

+0

あなたは何をしていても、テーブルのレコード数で成長するプロセスについて話しています。代わりに、各センサーごとに1つのレコードを持つ余分なテーブルを用意し、センサーの状態が変わるたびに更新することもできます。このようにして、スキャンされたテーブルのレコード数は安定したままになり、クエリのパフォーマンスは予測可能になります。 – FDavidov

答えて

0

さて、現在のデータセットに基づいて、次は有効なようです - 私はあなたが問題を過剰に簡略化しましたかどうかの両方、と私は解決策をかけて調理しましたかどうかを疑問に思うけれども。

SELECT x.* 
    , y.state -- or possibly COALESCE(y.state,'up') state 
    FROM 
    (SELECT a.* 
      , MAX(b.datetime) max_datetime 
     FROM table_a a 
     LEFT 
     JOIN table_b b 
      ON b.sensor_id = a.sensor_id 
      AND b.datetime <= a.datetime 
     GROUP 
      BY a.sensor_id,a.datetime 
    ) x 
    LEFT 
    JOIN table_b y 
    ON y.sensor_id = x.sensor_id 
    AND y.datetime = x.max_datetime; 
+0

試してみましょう – Jay

関連する問題