[jira] [Commented] (IOTDB-1431) Unify and enhance data model related documents

["Xiangdong Huang (Jira)" <ji...@apache.org>]

    [ 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)