我们目前正在调查Cassandra作为大型时间序列系统的数据库。
我已阅读https://academy.datastax.com/resources/getting-started-time-series-data-modeling关于Cassandra中时间序列数据建模的内容。
我们所拥有的是许多气象站的高速时间序列数据。每个气象站都有许多传感器"每个都收集三个指标:温度,湿度和光。
我们正试图将每个系列存储为一个宽行。但是,我们希望在项目的整个生命周期内每个站点获得数十亿的读数,因此我们希望限制行大小。
我们希望每个(weather_station_id, year, day_of_year)
都有一行,也就是每天都有一行。但是,我们仍然希望分区键为weather_station_id
- 也就是说,我们希望站的所有读数都在同一节点上。
我们目前有以下架构,但我想得到一些反馈。
CREATE TABLE weather_station_data (
weather_station_id int,
year int,
day_of_year int,
time timestamp,
sensor_id int,
temperature int,
humidity int,
light int,
PRIMARY KEY ((weather_station_id), year, day_of_year, time, sensor_id)
) WITH CLUSTERING ORDER BY (year DESC, day_of_year DESC, time DESC, sensor_id DESC);
在上述文档中,他们使用了这个"限制分区的行和日期"概念。但是,我不清楚他们的示例中的日期是否是分区键的一部分。
答案 0 :(得分:1)
根据教程,如果我们选择将weather_station_id作为唯一分区,则该行将耗尽。 即C *具有每个分区20亿列的实际限制。
所以IMO,你的数据模型很糟糕。
但是,我不清楚他们的示例中的日期是否是分区键的一部分。
使用的教程
PRIMARY KEY ((weatherstation_id,date),event_time)
所以,是的,他们认为数据是分区密钥的一部分。
我们希望电台的所有读数都在同一节点上。
我不确定,为什么你不满足这样的要求。您总是可以使用多个查询获取天气数据一年以上。
select * from weather_station_data where weather_station_id=1234 and year= 2013;
select * from weather_station_data where weather_station_id=1234 and year= 2014;
因此,请考虑将结构更改为
PRIMARY KEY ((weather_station_id, year), day_of_year, time, sensor_id)
希望它有所帮助!
答案 1 :(得分:0)
在我看来,数据模型并不是很好。这个模型的问题是:
更好的解决方案:问问自己如何查询这些数据。如果你说:我每年查询所有数据,也使用年份作为分区键。如果您还需要查询超过一年的数据,则可以创建两个不同年份的查询。这有效,性能更好。 (瓶颈可能只是客户的网络)
我向您提出一个问题:您可以汇总数据吗? Cassandra有一个名为counter的列类型。您可以创建一个java / scala应用程序,您可以在生成数据时聚合数据。您可以使用流式框架:Flink或Spark。 (如果你需要的不仅仅是数数。)一种情况:您汇总每小时和每天的数据。您在流媒体应用中获得了数据。现在:您有一个每小时数据的变量。你算上或下或其他什么。如果小时结束,则将此行放在每小时列族和每日列族中。在您的每日专栏系列中,您使用的是柜台。我希望,你理解我的意思。