基于间隔和事件的时间序列的 Cassandra 数据模型
Cassandra data model for interval and event based time series
我必须从各种物联网传感器收集时间序列数据。根据我的研究,有两种不同类型的时间序列数据流。
情况一:固定区间
这种类型的数据流具有固定的间隔,并且很容易在给定范围内 select 数据点。一个典型的用例是 counter.
案例 2:基于事件
这种类型的数据流在不规则的时间点出现,只有在某些事情即将发生变化时才会发生。一个典型的用例是当传感器离线或在线时 电源开关 。
要求
选择给定时间之间所有受影响的数据点 window
数据模型
这是我的 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 的解决方案
这里我有一个问题,来自 window 之外的事件可以重叠到 selected 范围内。例如E1
另一个问题是最后一个事件 E3 事件还没有结束。
我需要
从window开始到E1的部分持续时间。
要获取此信息,我必须从流中的第一个事件往回看以获取前一个事件。然后计算从window开始到E2.
的差值
持续时间从 E2 到 E3
这很简单
持续时间从E2到window结束(尚未完成)
必须检查最后一个事件是否具有与 window 结束相同的时间戳,如果不是最后一个事件仍然是 运行.
结果
问题
案例2有更好的数据模型吗?
有什么方法可以不用额外的查询来获得我需要的解决方案吗?
我认为您几乎涵盖了所有场景。可以帮助您的一件事是,如果您可以创建一个事件 table,其中具有 "event" 类型和 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 来保持每个传感器的当前状态——这只是为了在所有应用程序出现故障时进行恢复,但这从未发生过。
这种方法可能 运行 需要大量内存资源,所以如果你有数百万个传感器,这可能会变得太昂贵,而且它不会增加太多价值,所以基本上这一切都取决于规模你实际拥有的。
此外,这个想法的一个缺点是您不会真正捕捉到当前正在进行的事件,因为它尚未写入 table。但实际上会是 o.k。对于分析工作负载,因为您不必进行额外的查询来获取 E1 的开头,它已经为您准备好了。
一些 table 与 begin_time 和 end_time 的方法也可能是可行的,但话又说回来,这只会浪费 space(并且使用传感器,它很快就会被打包).
你的模型和你描述它的方式与我之前所做的非常相似,而且仅使用 cassandra 就我所知,你可以做的事情不多了:(
我必须从各种物联网传感器收集时间序列数据。根据我的研究,有两种不同类型的时间序列数据流。
情况一:固定区间
这种类型的数据流具有固定的间隔,并且很容易在给定范围内 select 数据点。一个典型的用例是 counter.
案例 2:基于事件
这种类型的数据流在不规则的时间点出现,只有在某些事情即将发生变化时才会发生。一个典型的用例是当传感器离线或在线时 电源开关 。
要求
选择给定时间之间所有受影响的数据点 window
数据模型
这是我的 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 的解决方案
这里我有一个问题,来自 window 之外的事件可以重叠到 selected 范围内。例如E1
另一个问题是最后一个事件 E3 事件还没有结束。
我需要
从window开始到E1的部分持续时间。
要获取此信息,我必须从流中的第一个事件往回看以获取前一个事件。然后计算从window开始到E2.
的差值
持续时间从 E2 到 E3
这很简单
持续时间从E2到window结束(尚未完成)
必须检查最后一个事件是否具有与 window 结束相同的时间戳,如果不是最后一个事件仍然是 运行.
结果
问题
案例2有更好的数据模型吗?
有什么方法可以不用额外的查询来获得我需要的解决方案吗?
我认为您几乎涵盖了所有场景。可以帮助您的一件事是,如果您可以创建一个事件 table,其中具有 "event" 类型和 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 来保持每个传感器的当前状态——这只是为了在所有应用程序出现故障时进行恢复,但这从未发生过。
这种方法可能 运行 需要大量内存资源,所以如果你有数百万个传感器,这可能会变得太昂贵,而且它不会增加太多价值,所以基本上这一切都取决于规模你实际拥有的。
此外,这个想法的一个缺点是您不会真正捕捉到当前正在进行的事件,因为它尚未写入 table。但实际上会是 o.k。对于分析工作负载,因为您不必进行额外的查询来获取 E1 的开头,它已经为您准备好了。
一些 table 与 begin_time 和 end_time 的方法也可能是可行的,但话又说回来,这只会浪费 space(并且使用传感器,它很快就会被打包).
你的模型和你描述它的方式与我之前所做的非常相似,而且仅使用 cassandra 就我所知,你可以做的事情不多了:(