間隔とイベントベースの時系列のカッサンドラデータモデル

Question

さまざまなIoTセンサーから時系列データを収集する必要があります。私の研究に基づいて、2つの異なるタイプの時系列データストリームがあります。

ケース1：一定の間隔

データストリームのこのタイプは、一定の間隔を有し、その所与の範囲間のデータポイントを選択することは非常に簡単。典型的な使用例は、カウンタです。

ケース2：イベント

ベースのデータ・ストリームのこのタイプは、時間に不規則なポイントで来て、何かが変更される場合にのみ発生します。典型的な使用例は、センサがオフラインまたはオンラインになったときに電源スイッチの電源スイッチです。

要件

与えられた時間ウィンドウの間で影響を受けるすべてのデータポイントを選択

データモデル

これは私のカサンドラデータモデルです。ストリーム内の任意の点は、これは非常に容易であり、ケース2

にはさらなる議論

SELECT * FROM sensor_raw where 
sensor_id = '1' AND 
bucket_id = '2017' AND 
sensor_time >= '2017-01-01 10:00' 
AND sensor_time < '2017-01-01 10:14' 

ソリューションを必要としない

CREATE TABLE sensor_raw (
    sensor_id text, 
    bucket_id date, 
    sensor_time timestamp, 
    sensor_value double, 
    PRIMARY KEY ((sensor_id, bucket_id), sensor_time) 
) WITH CLUSTERING ORDER BY (sensor_time DESC); 

ケース1のためのソリューション

によってモデル化することができます。

ここでは、ウィンドウの外からのイベントが重複する可能性があるという問題があります選択された範囲。たとえば、E1

最後のイベントE3イベントはまだ終了していません。

は私がにE1を開始窓から

1. 部分的な時間を必要とします。

   この情報を取得するには、ストリームの最初のイベントから前のイベントを取得する必要があります。次に、ウィンドウ開始からE2までの差を計算します。

2. 期間E2から E3 に

   これは（まだ終わっていない）

3. 期間E2 からウィンドウ終了に簡単です

   うラスかどうかをチェックしなければならないtイベントはウィンドウ終了と同じタイムスタンプを持ち、最後のイベントがまだ実行されていない場合結果

   

   質問

は、ケース2のために任意のより良いデータモデルはありますか？

私が必要とするソリューションを得るための追加のクエリがない方法はありますか？

Answer 1

あなたはすべてのシナリオをかなりカバーしていると思います。 「イベント」タイプとend_timeのデータが入るイベントテーブルを作成することができれば、あなたを助ける1つのことがあります。行に何か：

CREATE TABLE sensor_raw_events (
    sensor_id   text, 
    bucket_id   date, 
    event_end_time timestamp, 
    event_begin_time timestamp, 
    event_type  text, 
    PRIMARY KEY ((sensor_id, bucket_id), sensor_end_time) 
) WITH CLUSTERING ORDER BY (sensor_end_time DESC); 

そのための前提条件は、あなたが実際にアプリケーションレベルでの切り替えイベントを追跡することが可能であろう層のいくつかの並べ替えを持っているということでしょう。私が取り組んだプロジェクトでは、プロトコル要件のためにデバイスに接続するときにセッションを維持しなければならなかったので、これは実際には問題ではありませんでした。

私たちは基本的に、すべてのセンサーの現在の状態を定期的にフラッシュするキャセンドラにメモリーグリッドがありませんでした。これはすべてのアプリケーションがダウンした場合にのみ回復するためでしたが、これは起こりませんでした。

このアプローチでは、実行に多大なメモリリソースが必要になるでしょう。センサーが何百万もある場合、これは高価になる可能性があります。

さらに、このアイデアの1つの側面は、まだテーブルに書き込まれていないため、現在進行中のイベントを実際に捕まえないということです。しかし、実際にはo.kです。 E1の開始点を取得するために追加のクエリを作成する必要がないため、分析作業負荷のために既に存在します。

begin_timeとend_timeで1つのテーブルを使用するアプローチもありますが、これもまたスペースを浪費します（センサーではかなり素早くパックされます）。

あなたのモデルとどのように説明し、それはかなり私は単純にそこだけでは前とカサンドラで行ったものと非常によく似ていますが、はるかにそれではない、あなたが行うことができますように私には知られているが:(