【问题标题】:Cassandra data model for interval and event based time series用于基于间隔和事件的时间序列的 Cassandra 数据模型
【发布时间】:2017-08-19 22:00:15
【问题描述】:

我必须从各种物联网传感器收集时间序列数据。根据我的研究,有两种不同类型的时间序列数据流。

案例1:固定间隔

这种类型的数据流具有固定的间隔,并且很容易在给定范围内选择数据点。 计数器是一个典型的用例。

案例 2:基于事件

这种类型的数据流出现在不规则的时间点,并且仅在某些事情即将发生变化时出现。当传感器离线或在线时,一个典型的用例是电源开关

要求

在给定时间窗口内选择所有受影响的数据点

数据模型

这是我的 cassandra 数据模型。流中的任何点都可以通过

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的解决方案

这很简单,无需进一步讨论

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'

案例2的解决方案

这里我遇到的问题是来自窗口外的事件可能会重叠到所选范围内。例如 E1

另一个问题是最后一个事件E3,该事件尚未结束。

我需要

  1. 窗口开始E1的部分持续时间。

    要获取此信息,我必须从流中的第一个事件回顾以获取前一个事件。然后计算从窗口开始到 E2 的差值。

  2. E2E3

    的持续时间

    这很简单

  3. E2窗口结束的持续时间(尚未结束)

    必须检查最后一个事件是否与窗口结束具有相同的时间戳,如果不是,则最后一个事件仍在运行。

结果

问题

案例 2 有更好的数据模型吗?

有什么方法可以不用额外的查询来获得我需要的解决方案吗?

【问题讨论】:

    标签: cassandra time-series data-modeling


    【解决方案1】:

    我认为您几乎涵盖了所有场景。可以帮助您的一件事是,如果您可以创建一个事件表,其中包含“事件”类型和 end_time 的数据将去。大概是这样的:

    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);
    

    这样做的先决条件是您实际上拥有某种能够跟踪在应用程序级别切换的事件的层。由于协议要求,我从事的一个项目在连接到设备时必须保持会话,所以我猜这不是一个真正的问题。

    我们基本上有一个小的内存网格,它通过定期刷新到 cassandra 来保持每个传感器的当前状态 - 这只是为了在所有应用程序出现故障时恢复,但这从未发生过。

    这种方法可能需要大量内存资源来运行它,因此如果您拥有数百万个传感器,这可能会变得过于昂贵并且不会增加太多价值,因此基本上这一切都取决于您实际拥有的规模。

    另外一个缺点是您不会真正捕捉到当前正在进行的事件,因为它还没有写入表中。但实际上会好的。对于分析工作负载,因为您不必进行额外的查询来获取 E1 的开头,它已经为您准备好了。

    使用一个带有 begin_time 和 end_time 的表的一些方法也可能是可行的,但是这又一次浪费了空间(而且对于传感器,它很快就被打包了)。

    您的模型以及您描述它的方式与我之前所做的非常相似,并且仅使用 cassandra 时,我所知道的您可以做的事情并不多:(

    【讨论】:

    • 感谢您的回答。我想出了几乎相同的解决方案。很高兴看到有些人有同样的问题:)
    猜你喜欢
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 2013-04-17
    • 2013-08-02
    • 1970-01-01
    • 1970-01-01
    • 2013-07-13
    • 2012-12-07
    相关资源
    最近更新 更多