首页 > 解决方案 > 传感器网络计算特征 - 设计数据库

问题描述

您将如何对涉及传感器的系统进行建模

这是我对桌子的想法

Sensor
- id
- model
- type

SensorMetadata
- sensorId
- timestamp // for time series to account for changing
- lat
- long
- alt
- metadata: json // some dynamic changeable data based on the domain lets say relative distance to something...
- unit

Measurements
- id
- timestamp
- sensorId
- value

Feature
- id
- type // complex features like volume
- value
- timestamp
- // relation to location (maybe sensorMetadata)

1 如果假设有问题的液体罐,您是否会将其建模为特定于该领域,或者您是否会使用“特征”语言对其进行通用建模?

2 您将如何以及何时根据测量值计算“特征”?很明显,我错过了计算位置特征时需要考虑的传感器(假设他们在某些情况下使用多个传感器)

标签: databasedatabase-designarchitectureiot

解决方案


关于Sensor,不要害怕使用类似的东西SensorInstance- 如果可以的话,应该避免歧义,特别是如果你可以这样做而不用很长的名字。从长远来看,清晰(明确)的数据库设计通常比简洁的设计要好。

SensorMetadata- SensorState 是另一种选择。

Measurements- 尽量避免使用复数名称,单数(如Sensor)通常更好。这个页面有一些很好的指导:https ://www.sqlshack.com/learn-sql-naming-conventions/

我能看到的最大问题是 Measurements.value - 你如何解释这个值?它是什么数据类型——即您的传感器产生的数据类型是什么?测量与传感器有关 - 传感器测量是否总是产生一个值(正如您的设计所暗示的那样)?

我不清楚这张Feature桌子的目的是什么。

对于这样的设计挑战,请查看现有的参考架构和设计 - 这家公司看起来可能有一些有用的白皮书:https ://crate.io/use-cases/iot-sensor-data/ 这也可能有用为您阅读,但本身不会提供直接答案:https ://hackernoon.com/ingesting-iot-and-sensor-data-at-scale-ee548e0f8b78

21 年 6 月 28 日更新

因此,Measurement 中的 Value 列将根据它来自的 SensorId 进行解释,并且由于 Sensor 具有存储其 Unit 的 SensorMetadata,如果可以的话,我将能够解释 Value 吗?

应该没事。

对于功能 - 几种方法:

  1. 稍后计算 - 即只收集原始数据,然后进行批量计算。例如,您可以将数据从数据捕获系统(由于表设计基本上是OLTP数据模型)ETL 到报告系统(OLAP数据模型)。

  2. 现在计算它 - 即它被提供数据库的应用程序或数据库中的触发器/逻辑捕获。为此,您需要在特征表与测量和/或传感器表之间进行某种参考。这样你就可以测试计算 Feature.Value 的逻辑,因为如果你不能这样做 - 你能相信你的数据吗?如果您决定要更改计算公式,它还允许您计算新值。

我个人认为#1 更灵活,一旦你拥有原始数据,你可以追溯添加任何你喜欢的新功能,但这可能不符合你需要系统工作的方式。

选项 2 很棘手。如果 Feature.Value 是根据多个 Measurement.Value (并且可能不止一个传感器)计算得出的,那么测量值和传感器的数量也可能会因不同的功能而异 - 所以你需要一个多对多的关系它们(特征和测量)。

拥有多对多关系很好:连接表是常见的做法(一般而言),并且适合用于事务(即数据收集)的 OLTP 模型。不过,将其转换为对报告更友好的 OLAP 模型会更加复杂。

最后,关于你的问题 #2 - 我想我已经间接地部分回答了。基本上这取决于:需要多长时间的特征数据?如果在运行时需要它,以便向人员或系统提供即时信息,那么您将希望尽快计算它。也许将其作为第二个问题,并提供有关功能用例、解决方案上下文(谁在使用它,在什么情况下)等的信息。


推荐阅读