当前位置: 首页 > 知识库问答 >
问题:

Cassandra时间序列数据建模和限制分区大小

王俊哲
2023-03-14

我们目前正在调查卡桑德拉作为大型时间序列系统的数据库。

我已经通读了https://academy . datas tax . com/resources/getting-started-time-series-data-modeling关于Cassandra中时间序列数据建模的内容。

我们有许多气象站的高速时间序列数据。每个气象站都有许多“传感器”,每个传感器收集三个指标:温度、湿度和光照。

我们试图将每个系列存储为一个宽行。然而,我们希望在项目的生命周期内每个站获得数十亿的读数,所以我们想限制行大小。

我们希望每个(weather_station_id,年,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);

在上述文档中,他们利用了这种“按日期限制分区行”的概念。但是,我不清楚它们示例中的日期是否是分区键的一部分。

共有2个答案

童化
2023-03-14

在我看来,数据税模型并不是很好。此模型的问题:

  • 他们使用气象站作为分区键。具有相同分区键的所有行都存储在同一台计算机上。这意味着:如果你有10年的原始数据(100ms步长),你将非常快地打破卡桑德拉的限制。10 年 × 365 天 × 24 小时 × 60 分钟 × 60 秒 x 10(100 毫秒步长)x 7 列。限额是20亿。在我看来,如果你构建这个数据模型,你不会使用卡桑德拉的好处。对于每个气象站,您还可以使用mongo,mysql或其他数据库。

更好的解决方案:问问自己将如何查询这些数据。如果你说:我每年查询所有数据,也使用年份作为部分键。如果还需要查询一年以上的数据,可以创建两个不同年份的查询。这有效,性能更好。(瓶颈可能只是网络到你的客户端)

    < li >还有一点提示:Cassandra不像mysql。这是一个非规范化的数据库。这意味着:不止一次保存你的数据并不脏。这意味着:每年查询数据很重要,每小时、每天或每个传感器id查询数据也很重要,您可以创建具有不同分区键和主键顺序的列族。复制你的数据没问题。Cassandra针对写性能进行了优化,而不是针对读性能。这意味着:以正确的顺序写入数据通常比以正确的顺序读取数据更好。在cassandra 3.0中有一个新特性,叫做物化视图,用于自动复制。如果你想:哦,不,我会复制所需的存储空间。记住:存储真的很便宜。1tb买十块硬盘没问题。它没有花费任何东西。性能很重要。

我有一个问题要问你:你能汇总你的数据吗?Cassandra有一个名为counter的列类型。您可以创建一个java/scala应用程序,在生成数据的同时在其中聚合数据。你可以为此使用一个流框架:Flink或Spark。(如果你需要的不仅仅是数数。).一种情况是:您汇总每小时和每天的数据。你在你的流媒体应用程序中获取数据。现在:你有一个每小时数据的变量。你可以向上或向下计数。如果一个小时结束了,你把这一行放到你的小时列族和日列族中。在你的每日专栏中,你使用了一个计数器。我希望,你明白我的意思。

公孙高轩
2023-03-14

根据教程,如果我们选择将weather_station_id作为唯一分区,那么该行将被耗尽。也就是说,C*对每个分区有20亿列的实际限制。

所以在我看来,你的数据模型很糟糕。

但是,我不清楚他们示例中的日期是否是分区键的一部分。

使用的教程

主键((weatherstation_id,date),event_time)

所以,是的,他们认为数据是分区键的一部分。

我们希望一个站点的所有读数都在同一节点上。

我不知道你为什么不想要这样的要求。你总是可以通过多次查询获取超过一年的天气数据。

从weather_station_id=1234和年份= 2013的weather_station_data中选择*,从weather_station_data中选择*,其中weather_station_id= 1234,年份= 2014;

所以考虑改变你的结构

主键((weather_station_id,年份),day_of_year,时间,sensor_id)

希望它有帮助!

 类似资料:
  • 我正在开发一个Cassandra数据模型来存储用户上传的记录。 潜在的问题是,一些用户可能在5分钟内上传50-100k行,这可能导致分区键(user_id)的“热点”。(如果每个分区超过10k行,建议重新考虑数据模型)。 如何避免在短时间内一个分区键上有太多记录? 我尝试使用Datastax的时间序列建议,但即使我有年、月、日、小时列,热点仍然可能出现。 使用案例包括: 按user_id获取所有上

  • 我正在研究一个用于存储时间序列的卡桑德拉数据模型(我是卡桑德拉新手)。我有两个应用程序:日内股票数据和传感器数据。 库存数据将以一分钟的时间分辨率保存。七个数据字段构建一个时间框架:符号、日期时间、开盘、高位、低位、收盘、成交量 我将主要通过符号和日期来查询数据。例如,给我2013年1月1日到2013年1月31日之间按日期时间排序的AAPL的所有数据。cassandra查询的建议是查询整列。所以你

  • 任何一个都可以,要求数据是一个字符串化的JSON对象。我的查询将返回用户在给定时间范围内的所有数据。哪种模式更有意义,或者有更好的方法来解决这个问题?

  • 编辑:我已经更改了模式,以便做出一些澄清。 每天都会为当天创建一个新表。所以一个表只包含一天的日志。 我的查询条件如下。 查询特定用户在特定日期(日期而不是时间)的所有日志。 因此原因、项目、价格和计数根本不会用作查询的提示或条件。

  • 我目前有一个应用程序,它将事件驱动的实时流数据持久化到一个列系列,该系列建模为: 每个帐户ID每X秒发送一次数据,因此我们每次收到事件时都会覆盖现有行。此数据包含当前实时信息,我们只关心最近的事件(不使用旧数据,这就是我们插入已经存在的键的原因)。从应用程序用户端-我们通过account_id语句查询选择。 我想知道是否有更好的方法来模拟这种行为,并查看了Cassandra的最佳实践和类似的问题(

  • 我将我的数据存储在卡珊德拉·NoSQL数据库中,模式如下: 然后我使用。我希望数据是按时间序列排列的,第一天确实如此,但今天情况发生了变化。 我认为数据库忽略了日期,而只关心时间。 知道怎么解决这个问题吗?