[
https://issues.apache.org/jira/browse/IOTDB-1431?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17363297#comment-17363297
]
Xiangdong Huang commented on IOTDB-1431:
----------------------------------------
> In practice, a real sensor is a device itself, so the name *_sensor_* is very
>confusing. I would like to propose that we replace all *_sensor_* occurrences
>with *_measurement_*.
+1.
> For example, we can model the utility of CPU cores like
>"root.BJ.ServerRoom001.Server007.CPU0.Core0_Utility", but the *_device_* is
>"root.BJ.ServerRoom001.Server007.CPU0" and "root.BJ.ServerRoom001.Server007"
>is not a *_device_* in IoTDB as it does not collect data directly. From the
>point of view of asset management, "root.BJ.ServerRoom001.Server007" is
>certainly another type of device, but IoTDB focuses on timeseries management
>instead of asset management, so we have a different definition of *_device_*.
Device is indeed confusing. Considering BOM structure, "CPU0" is called a
component or a part.
> It is currently advised to cope with a relational DBMS for asset management
>instead of completely relying on IoTDB.
I think IoTDB needs to manage the properties of "devices", and the BOM. It
should also support query on both the properties (static data) and timeseries
(dynamic data).
> Unify and enhance data model related documents
> ----------------------------------------------
>
> Key: IOTDB-1431
> URL: https://issues.apache.org/jira/browse/IOTDB-1431
> Project: Apache IoTDB
> Issue Type: Improvement
> Components: Document
> Reporter: Tian Jiang
> Priority: Major
>
> In IoTDB, there are two interchangeable concepts: *_sensor_*,
> *_measurement_*. Both of them are the names of physical variables recorded by
> a timeseries, like "temperature", "pressure", "voltage". Together with
> another important concept, *_device_*, a timeseries is described. A
> *_device_* is the full name of a physical entity that collects timeseries
> data, for example, "root.BJ.ServerRoom001.Server007" describes a computer
> whose Id is 007 in a server room with an Id of 001 in Beijing. Put together,
> *_device_* + *_measurement_* describes the full name of a timeseries, which
> is a collection of observations and the observed timestamps, for example,
> timeseries "root.BJ.ServerRoom001.Server007.CPU0.Core0_Utility" stores the
> utility of a CPU core of a computer mentioned above.
> To make it simple:
> *_sensor_*=*_measurement_*=the name of an observation
> *_device_*=the name of an entity that collects data with timestamp
> *_timeseries_*=device + measurement=an observation taken by a specific entity
> It should be noticed that a *_device_* in IoTDB must collect data itself,
> which means having *_measurements_* directly under it, and this may conflict
> with some intuition. For example, we can model the utility of CPU cores like
> "root.BJ.ServerRoom001.Server007.CPU0.Core0_Utility", but the *_device_* is
> "root.BJ.ServerRoom001.Server007.CPU0" and "root.BJ.ServerRoom001.Server007"
> is not a *_device_* in IoTDB as it does not collect data directly. >From the
> point of view of asset management, "root.BJ.ServerRoom001.Server007" is
> certainly another type of device, but IoTDB focuses on timeseries management
> instead of asset management, so we have a different definition of *_device_*.
> It is currently advised to cope with a relational DBMS for asset management
> instead of completely relying on IoTDB.
> In practice, a real sensor is a device itself, so the name *_sensor_* is very
> confusing. I would like to propose that we replace all *_sensor_* occurrences
> with *_measurement_*.
> *_measurement_* is also used in other systems like InfluxDB, but has a
> totally different meaning, as *_measurement_* in InfluxDB is more like the
> table name in a relational DBMS. For a viable schema mapping, one can refer
> to the following:
> measurement(IoTDB)=field(InfluxDB)=non-indexed columns(relational DB)
> device(IoTDB)=measurement+tags(Influxdb)=indexed columns(relational DB)
> For the "root.BJ.ServerRoom001.Server007.CPU0.Core0_Utility" example above,
> the corresponding InfluxDB schema can be:
> measurement(InfluxDB)="BJ"
> tags(InfluxDB)=(ServerRoomId=001, ServerId=007, CPUId=0)
> field(InfluxDB)=Core0_Utility
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
