【问题标题】:Best design/technology to store fast growing amount of data存储快速增长的数据量的最佳设计/技术
【发布时间】:2018-05-06 22:12:32
【问题描述】:

我需要每 1 分钟存储来自百万台设备的信号,其中每个信号对象有 4 个属性加上时间戳:

  • 设备 ID,始终相同
  • Attr1,始终相同(设备型号)
  • Attr2,大约每 6 个月更改一次。 (设备固定位置)
  • Attr3,每 2-4 周更改一次(设备固件版本)

使用收集到的数据,我需要获取一些报告,例如“上个月签入了多少带有 attr2 的设备”。这里的限制是我可能需要按任何属性进行过滤和分组,而不仅仅是设备 ID。

我的第一种方法是在 bigquery 中创建一个包含嵌套记录的模型,但我不确定这是否是最佳解决方案。

您会推荐我使用哪个数据库和架构来解决这个问题?

谢谢!

【问题讨论】:

  • 数据量太大了。什么设备消息值变化如此频繁以至于您需要每分钟报告一次?或者您是否尝试在一两分钟内检测到设备缺失/故障?如果是最后一个,也许您的设备每分钟传输一次,但您只需要在发生变化时将某些内容存储在数据库中,根据您的描述,这更像是每两周读取一次。
  • 必须是 BigQuery 吗?为什么不使用可以分别存储时间序列数据和元数据的 TSDB,以便为每种类型的属性选择最佳压缩/模式。

标签: google-bigquery time-series bigdata scalability iot


【解决方案1】:

有趣的问题 - BigQuery 可以以这种速度消化(限制是每个项目每秒 10 万条记录) - 但看起来 DeviceId 是您的关键,因此将其公开为非嵌套列是有意义的 - 在这种情况下 - 没有嵌套列- 存储价格高,但查询非常有效。作为替代方案,您可以使用 Attr1、Attr2、Attr3 作为键列,使用 deviceId 列表作为嵌套列 - 从存储角度来看是最有效的 - 但从分析查询的角度来看可能不是很好。

另一个选项让您仅存储更改(或每日/每小时汇总)(因此,您知道 10:01、10:02、10:03 的特定设备报告并不重要,您可以说知道该设备于 2018 年 5 月 5 日报告(或至少在 2018 年 5 月 5 日的 10 小时) 在这种情况下,您可以实现一些内存解决方案(例如 appengine),等待设备状态的变化,并且仅在这种情况下将数据流式传输到 BigQuery

【讨论】:

  • 拥有一个“受控缓冲区”来存储聚合数据的想法是我目前为解决问题而设计的。但是,考虑到当今所有不同的大数据技术,我不确定这种方法是否是最好的。
  • 我认为,如果您不想存储来自每个设备的每一个心跳 - 使用受控缓冲区将是最具成本效益的方法
猜你喜欢
  • 1970-01-01
  • 2023-04-01
  • 1970-01-01
  • 1970-01-01
  • 2018-01-21
  • 2012-10-01
  • 1970-01-01
  • 1970-01-01
  • 2017-02-04
相关资源
最近更新 更多