This is an automated email from the ASF dual-hosted git repository.
critas pushed a commit to branch main
in repository https://gitbox.apache.org/repos/asf/iotdb-docs.git
The following commit(s) were added to refs/heads/main by this push:
new 71d4150e add description about data model (#886)
71d4150e is described below
commit 71d4150ece2468df7d8fc0dde329184d5db0e2a9
Author: leto-b <[email protected]>
AuthorDate: Fri Sep 19 12:09:21 2025 +0800
add description about data model (#886)
* add description about data model
* update description about data model
* update description about data model
* update description about data model
---
.../Tree/Background-knowledge/Data-Model-and-Terminology_apache.md | 5 ++++-
.../Tree/Background-knowledge/Data-Model-and-Terminology_timecho.md | 5 ++++-
.../Background-knowledge/Data-Model-and-Terminology_apache.md | 5 ++++-
.../Background-knowledge/Data-Model-and-Terminology_timecho.md | 4 +++-
.../Tree/Background-knowledge/Data-Model-and-Terminology_apache.md | 4 +++-
.../Tree/Background-knowledge/Data-Model-and-Terminology_timecho.md | 6 ++++--
.../Background-knowledge/Data-Model-and-Terminology_apache.md | 5 ++++-
.../Background-knowledge/Data-Model-and-Terminology_timecho.md | 6 ++++--
8 files changed, 30 insertions(+), 10 deletions(-)
diff --git
a/src/UserGuide/Master/Tree/Background-knowledge/Data-Model-and-Terminology_apache.md
b/src/UserGuide/Master/Tree/Background-knowledge/Data-Model-and-Terminology_apache.md
index 6d16ae92..9e9946b5 100644
---
a/src/UserGuide/Master/Tree/Background-knowledge/Data-Model-and-Terminology_apache.md
+++
b/src/UserGuide/Master/Tree/Background-knowledge/Data-Model-and-Terminology_apache.md
@@ -33,7 +33,9 @@ IoTDB offers two data modeling syntaxes—tree model and table
model, each with
**Tree Model**: It manages data points as objects, with each data point
corresponding to a time series. The data point names, segmented by dots, form a
tree-like directory structure that corresponds one-to-one with the physical
world, making the read and write operations on data points straightforward and
intuitive.
-> When constructing tree model
[paths](../Basic-Concept/Operate-Metadata_apache.md#4-path-query), if node
naming may include non-standard characters or special symbols, it is
recommended to implement a backtick encapsulation strategy for all hierarchical
nodes. This approach effectively mitigates issues such as probe registration
failures and data write interruptions caused by character parsing errors,
ensuring the accuracy of path identifiers in syntax parsing.
+> 1. When performing data modeling, to meet sufficient performance
requirements, it is recommended that the penultimate layer node (corresponding
to the number of devices) in the data path (Path) contains no fewer than 1,000
entries. The number of devices is linked to concurrent processing capability—a
higher number of devices ensures more efficient concurrent read and write
operations.
+In scenarios where "the number of devices is small but each device contains a
large number of data points" (e.g., only 3 devices, each with 10,000 data
points), it is advisable to add a .value level at the end of the path. This
increases the total number of nodes in the penultimate layer. Example:
root.db.device01.metric.value.
+> 2. When constructing tree model
[paths](../Basic-Concept/Operate-Metadata_apache.md#4-path-query), if node
naming may include non-standard characters or special symbols, it is
recommended to implement a backtick encapsulation strategy for all hierarchical
nodes. This approach effectively mitigates issues such as probe registration
failures and data write interruptions caused by character parsing errors,
ensuring the accuracy of path identifiers in syntax parsing.
**Table Model**: It is recommended to create a table for each type of device.
The collection of physical quantities from devices of the same type shares
certain commonalities (such as the collection of temperature and humidity
physical quantities), allowing for flexible and rich data analysis.
@@ -108,6 +110,7 @@ The application scenarios mainly include two categories:
| **Time Series (Data Point)** | **Definition**:<br>A path prefixed with the
database path, segmented by `.`, and can contain any number of levels, such as
`root.db.turbine.device1.metric1`.<br>Each time series can have different data
types.<br>**Naming Recommendation**:<br>Only include unique identifiers
(similar to a composite primary key) in the path, generally not exceeding 10
levels.<br>Typically, place tags with low cardinality (fewer distinct values)
at the front to facilitate sys [...]
| **Device** | **Definition**: The second-to-last level is
the device, such as `device1` in
`root.db.turbine.device1.metric1`.<br>**Creation Method**: Cannot create a
device alone; it exists as time series are created. |
+
#### 3.1.3 Modeling Examples
##### 3.1.3.1 How to model when managing multiple types of devices?
diff --git
a/src/UserGuide/Master/Tree/Background-knowledge/Data-Model-and-Terminology_timecho.md
b/src/UserGuide/Master/Tree/Background-knowledge/Data-Model-and-Terminology_timecho.md
index cd3b9e48..d8d294ae 100644
---
a/src/UserGuide/Master/Tree/Background-knowledge/Data-Model-and-Terminology_timecho.md
+++
b/src/UserGuide/Master/Tree/Background-knowledge/Data-Model-and-Terminology_timecho.md
@@ -33,7 +33,9 @@ IoTDB offers two data modeling syntaxes—tree model and table
model, each with
**Tree Model**: It manages data points as objects, with each data point
corresponding to a time series. The data point names, segmented by dots, form a
tree-like directory structure that corresponds one-to-one with the physical
world, making the read and write operations on data points straightforward and
intuitive.
-> When constructing tree model
[paths](../Basic-Concept/Operate-Metadata_timecho.md#4-path-query), if node
naming may include non-standard characters or special symbols, it is
recommended to implement a backtick encapsulation strategy for all hierarchical
nodes. This approach effectively mitigates issues such as probe registration
failures and data write interruptions caused by character parsing errors,
ensuring the accuracy of path identifiers in syntax parsing.
+> 1. When performing data modeling, to meet sufficient performance
requirements, it is recommended that the penultimate layer node (corresponding
to the number of devices) in the data path (Path) contains no fewer than 1,000
entries. The number of devices is linked to concurrent processing capability—a
higher number of devices ensures more efficient concurrent read and write
operations.
+ In scenarios where "the number of devices is small but each device
contains a large number of data points" (e.g., only 3 devices, each with 10,000
data points), it is advisable to add a .value level at the end of the path.
This increases the total number of nodes in the penultimate layer. Example:
root.db.device01.metric.value.
+> 2. When constructing tree model
[paths](../Basic-Concept/Operate-Metadata_timecho.md#4-path-query), if node
naming may include non-standard characters or special symbols, it is
recommended to implement a backtick encapsulation strategy for all hierarchical
nodes. This approach effectively mitigates issues such as probe registration
failures and data write interruptions caused by character parsing errors,
ensuring the accuracy of path identifiers in syntax parsing.
**Table Model**: It is recommended to create a table for each type of device.
The collection of physical quantities from devices of the same type shares
certain commonalities (such as the collection of temperature and humidity
physical quantities), allowing for flexible and rich data analysis.
@@ -110,6 +112,7 @@ The application scenarios mainly include three categories:
| **Time Series (Data Point)** | **Definition**:<br>A path prefixed with the
database path, segmented by `.`, and can contain any number of levels, such as
`root.db.turbine.device1.metric1`.<br>Each time series can have different data
types.<br>**Naming Recommendation**:<br>Only include unique identifiers
(similar to a composite primary key) in the path, generally not exceeding 10
levels.<br>Typically, place tags with low cardinality (fewer distinct values)
at the front to facilitate sys [...]
| **Device** | **Definition**: The second-to-last level is
the device, such as `device1` in
`root.db.turbine.device1.metric1`.<br>**Creation Method**: Cannot create a
device alone; it exists as time series are created. |
+
#### 3.1.3 Modeling Examples
##### 3.1.3.1 How to model when managing multiple types of devices?
diff --git
a/src/UserGuide/latest/Background-knowledge/Data-Model-and-Terminology_apache.md
b/src/UserGuide/latest/Background-knowledge/Data-Model-and-Terminology_apache.md
index 6d16ae92..c3c6b9b8 100644
---
a/src/UserGuide/latest/Background-knowledge/Data-Model-and-Terminology_apache.md
+++
b/src/UserGuide/latest/Background-knowledge/Data-Model-and-Terminology_apache.md
@@ -33,7 +33,9 @@ IoTDB offers two data modeling syntaxes—tree model and table
model, each with
**Tree Model**: It manages data points as objects, with each data point
corresponding to a time series. The data point names, segmented by dots, form a
tree-like directory structure that corresponds one-to-one with the physical
world, making the read and write operations on data points straightforward and
intuitive.
-> When constructing tree model
[paths](../Basic-Concept/Operate-Metadata_apache.md#4-path-query), if node
naming may include non-standard characters or special symbols, it is
recommended to implement a backtick encapsulation strategy for all hierarchical
nodes. This approach effectively mitigates issues such as probe registration
failures and data write interruptions caused by character parsing errors,
ensuring the accuracy of path identifiers in syntax parsing.
+> 1. When performing data modeling, to meet sufficient performance
requirements, it is recommended that the penultimate layer node (corresponding
to the number of devices) in the data path (Path) contains no fewer than 1,000
entries. The number of devices is linked to concurrent processing capability—a
higher number of devices ensures more efficient concurrent read and write
operations.
+ In scenarios where "the number of devices is small but each device
contains a large number of data points" (e.g., only 3 devices, each with 10,000
data points), it is advisable to add a .value level at the end of the path.
This increases the total number of nodes in the penultimate layer. Example:
root.db.device01.metric.value.
+> 2. When constructing tree model
[paths](../Basic-Concept/Operate-Metadata_apache.md#4-path-query), if node
naming may include non-standard characters or special symbols, it is
recommended to implement a backtick encapsulation strategy for all hierarchical
nodes. This approach effectively mitigates issues such as probe registration
failures and data write interruptions caused by character parsing errors,
ensuring the accuracy of path identifiers in syntax parsing.
**Table Model**: It is recommended to create a table for each type of device.
The collection of physical quantities from devices of the same type shares
certain commonalities (such as the collection of temperature and humidity
physical quantities), allowing for flexible and rich data analysis.
@@ -108,6 +110,7 @@ The application scenarios mainly include two categories:
| **Time Series (Data Point)** | **Definition**:<br>A path prefixed with the
database path, segmented by `.`, and can contain any number of levels, such as
`root.db.turbine.device1.metric1`.<br>Each time series can have different data
types.<br>**Naming Recommendation**:<br>Only include unique identifiers
(similar to a composite primary key) in the path, generally not exceeding 10
levels.<br>Typically, place tags with low cardinality (fewer distinct values)
at the front to facilitate sys [...]
| **Device** | **Definition**: The second-to-last level is
the device, such as `device1` in
`root.db.turbine.device1.metric1`.<br>**Creation Method**: Cannot create a
device alone; it exists as time series are created. |
+
#### 3.1.3 Modeling Examples
##### 3.1.3.1 How to model when managing multiple types of devices?
diff --git
a/src/UserGuide/latest/Background-knowledge/Data-Model-and-Terminology_timecho.md
b/src/UserGuide/latest/Background-knowledge/Data-Model-and-Terminology_timecho.md
index cd3b9e48..bf130820 100644
---
a/src/UserGuide/latest/Background-knowledge/Data-Model-and-Terminology_timecho.md
+++
b/src/UserGuide/latest/Background-knowledge/Data-Model-and-Terminology_timecho.md
@@ -33,7 +33,9 @@ IoTDB offers two data modeling syntaxes—tree model and table
model, each with
**Tree Model**: It manages data points as objects, with each data point
corresponding to a time series. The data point names, segmented by dots, form a
tree-like directory structure that corresponds one-to-one with the physical
world, making the read and write operations on data points straightforward and
intuitive.
-> When constructing tree model
[paths](../Basic-Concept/Operate-Metadata_timecho.md#4-path-query), if node
naming may include non-standard characters or special symbols, it is
recommended to implement a backtick encapsulation strategy for all hierarchical
nodes. This approach effectively mitigates issues such as probe registration
failures and data write interruptions caused by character parsing errors,
ensuring the accuracy of path identifiers in syntax parsing.
+> 1. When performing data modeling, to meet sufficient performance
requirements, it is recommended that the penultimate layer node (corresponding
to the number of devices) in the data path (Path) contains no fewer than 1,000
entries. The number of devices is linked to concurrent processing capability—a
higher number of devices ensures more efficient concurrent read and write
operations.
+ In scenarios where "the number of devices is small but each device
contains a large number of data points" (e.g., only 3 devices, each with 10,000
data points), it is advisable to add a .value level at the end of the path.
This increases the total number of nodes in the penultimate layer. Example:
root.db.device01.metric.value.
+> 2. When constructing tree model
[paths](../Basic-Concept/Operate-Metadata_timecho.md#4-path-query), if node
naming may include non-standard characters or special symbols, it is
recommended to implement a backtick encapsulation strategy for all hierarchical
nodes. This approach effectively mitigates issues such as probe registration
failures and data write interruptions caused by character parsing errors,
ensuring the accuracy of path identifiers in syntax parsing.
**Table Model**: It is recommended to create a table for each type of device.
The collection of physical quantities from devices of the same type shares
certain commonalities (such as the collection of temperature and humidity
physical quantities), allowing for flexible and rich data analysis.
diff --git
a/src/zh/UserGuide/Master/Tree/Background-knowledge/Data-Model-and-Terminology_apache.md
b/src/zh/UserGuide/Master/Tree/Background-knowledge/Data-Model-and-Terminology_apache.md
index cf3c76bf..a9bd51a4 100644
---
a/src/zh/UserGuide/Master/Tree/Background-knowledge/Data-Model-and-Terminology_apache.md
+++
b/src/zh/UserGuide/Master/Tree/Background-knowledge/Data-Model-and-Terminology_apache.md
@@ -33,7 +33,9 @@ IoTDB 提供了两种数据建模方式——树模型和表模型，其特点
**树模型**：以测点为对象进行管理，每个测点对应一条时间序列，测点名按`.`分割可形成一个树形目录结构，与物理世界一一对应，对测点的读写操作简单直观。
->
在构建树模型[路径](../Basic-Concept/Operate-Metadata_apache.md#4-路径查询)时，节点命名若存在包含非标准字符或特殊符号的可能性，则建议对所有层级节点实施反引号封装策略。这样可以有效规避因字符解析异常导致的测点注册失败及数据写入中断问题，确保路径标识符在语法解析层面的准确性。
+> 1. 数据建模时，为了足够的性能要求，建议数据路径（Path）的倒数第二层节点（对应设备数量）不少于 1000
个，且设备数量与并发处理能力挂钩，设备数量充足时，并发读写效率更优。
+ 若遇到“设备数量较少但单设备测点数量较多”的场景（如仅 3 台设备，每台设备含 10000 个测点），推荐在最后层级新增 `.value`
，以此提升倒数第二层节点总数，示例：`root.db.device01.metric.value`。
+> 2.
在构建树模型[路径](../Basic-Concept/Operate-Metadata_apache.md#4-路径查询)时，节点命名若存在包含非标准字符或特殊符号的可能性，则建议对所有层级节点实施反引号封装策略。这样可以有效规避因字符解析异常导致的测点注册失败及数据写入中断问题，确保路径标识符在语法解析层面的准确性。
**表模型**：推荐为每类设备创建一张表，同类设备的物理量采集都具备一定共性（如都采集温度和湿度物理量），数据分析灵活丰富。
diff --git
a/src/zh/UserGuide/Master/Tree/Background-knowledge/Data-Model-and-Terminology_timecho.md
b/src/zh/UserGuide/Master/Tree/Background-knowledge/Data-Model-and-Terminology_timecho.md
index 0686f14d..985e1d10 100644
---
a/src/zh/UserGuide/Master/Tree/Background-knowledge/Data-Model-and-Terminology_timecho.md
+++
b/src/zh/UserGuide/Master/Tree/Background-knowledge/Data-Model-and-Terminology_timecho.md
@@ -33,8 +33,9 @@ IoTDB 提供了两种数据建模方式——树模型和表模型，其特点
**树模型**：以测点为对象进行管理，每个测点对应一条时间序列，测点名按`.`分割可形成一个树形目录结构，与物理世界一一对应，对测点的读写操作简单直观。
->
在构建树模型[路径](../Basic-Concept/Operate-Metadata_timecho.md#4-路径查询)时，节点命名若存在包含非标准字符或特殊符号的可能性，则建议对所有层级节点实施反引号封装策略。这样可以有效规避因字符解析异常导致的测点注册失败及数据写入中断问题，确保路径标识符在语法解析层面的准确性。
-
+> 1. 数据建模时，为了足够的性能要求，建议数据路径（Path）的倒数第二层节点（对应设备数量）不少于 1000
个，且设备数量与并发处理能力挂钩，设备数量充足时，并发读写效率更优。
+ 若遇到“设备数量较少但单设备测点数量较多”的场景（如仅 3 台设备，每台设备含 10000 个测点），推荐在最后层级新增 `.value`
，以此提升倒数第二层节点总数，示例：`root.db.device01.metric.value`。
+> 2.
在构建树模型[路径](../Basic-Concept/Operate-Metadata_timecho.md#4-路径查询)时，节点命名若存在包含非标准字符或特殊符号的可能性，则建议对所有层级节点实施反引号封装策略。这样可以有效规避因字符解析异常导致的测点注册失败及数据写入中断问题，确保路径标识符在语法解析层面的准确性。
**表模型**：推荐为每类设备创建一张表，同类设备的物理量采集都具备一定共性（如都采集温度和湿度物理量），数据分析灵活丰富。
@@ -111,6 +112,7 @@ IoTDB 提供了两种数据建模方式——树模型和表模型，其特点
| **时间序列（测点）** | 定义：<br>1. 一个以数据库路径为前缀的、由 . 分割的路径，可包含任意多个层级，如
root.db.turbine.device1.metric1 <br>2. 每个时间序列可以有不同的数据类型。<br>命名推荐:<br>1.
仅将唯一定位时间序列的标签（类似联合主键）放入路径中，一般不超过10层<br>2.
通常将基数（不同的取值数量）少的标签放在前面，便于系统将公共前缀进行压缩<br>数量推荐:<br>1.
集群可管理的时间序列总量和总内存相关，可参考资源推荐章节<br>2. 任一层级的子节点数量没有限制<br>创建方式：可手动创建或在数据写入时自动创建。 |
| **设备** | 定义：倒数第二级为设备，如
root.db.turbine.**device1**.metric1中的“device1”这一层级即为设备<br>创建方式：无法仅创建设备，随时间序列创建而存在
|
+
#### 3.1.3 建模示例
##### 3.1.3.1 有多种类型的设备需要管理，如何建模？
diff --git
a/src/zh/UserGuide/latest/Background-knowledge/Data-Model-and-Terminology_apache.md
b/src/zh/UserGuide/latest/Background-knowledge/Data-Model-and-Terminology_apache.md
index cf3c76bf..eb47ab5a 100644
---
a/src/zh/UserGuide/latest/Background-knowledge/Data-Model-and-Terminology_apache.md
+++
b/src/zh/UserGuide/latest/Background-knowledge/Data-Model-and-Terminology_apache.md
@@ -33,7 +33,9 @@ IoTDB 提供了两种数据建模方式——树模型和表模型，其特点
**树模型**：以测点为对象进行管理，每个测点对应一条时间序列，测点名按`.`分割可形成一个树形目录结构，与物理世界一一对应，对测点的读写操作简单直观。
->
在构建树模型[路径](../Basic-Concept/Operate-Metadata_apache.md#4-路径查询)时，节点命名若存在包含非标准字符或特殊符号的可能性，则建议对所有层级节点实施反引号封装策略。这样可以有效规避因字符解析异常导致的测点注册失败及数据写入中断问题，确保路径标识符在语法解析层面的准确性。
+> 1. 数据建模时，为了足够的性能要求，建议数据路径（Path）的倒数第二层节点（对应设备数量）不少于 1000
个，且设备数量与并发处理能力挂钩，设备数量充足时，并发读写效率更优。
+ 若遇到“设备数量较少但单设备测点数量较多”的场景（如仅 3 台设备，每台设备含 10000 个测点），推荐在最后层级新增 `.value`
，以此提升倒数第二层节点总数，示例：`root.db.device01.metric.value`。
+> 2.
在构建树模型[路径](../Basic-Concept/Operate-Metadata_apache.md#4-路径查询)时，节点命名若存在包含非标准字符或特殊符号的可能性，则建议对所有层级节点实施反引号封装策略。这样可以有效规避因字符解析异常导致的测点注册失败及数据写入中断问题，确保路径标识符在语法解析层面的准确性。
**表模型**：推荐为每类设备创建一张表，同类设备的物理量采集都具备一定共性（如都采集温度和湿度物理量），数据分析灵活丰富。
@@ -109,6 +111,7 @@ IoTDB 提供了两种数据建模方式——树模型和表模型，其特点
| **时间序列（测点）** | 定义：<br>1. 一个以数据库路径为前缀的、由 . 分割的路径，可包含任意多个层级，如
root.db.turbine.device1.metric1 <br>2. 每个时间序列可以有不同的数据类型。<br>命名推荐:<br>1.
仅将唯一定位时间序列的标签（类似联合主键）放入路径中，一般不超过10层<br>2.
通常将基数（不同的取值数量）少的标签放在前面，便于系统将公共前缀进行压缩<br>数量推荐:<br>1.
集群可管理的时间序列总量和总内存相关，可参考资源推荐章节<br>2. 任一层级的子节点数量没有限制<br>创建方式：可手动创建或在数据写入时自动创建。 |
| **设备** | 定义：倒数第二级为设备，如
root.db.turbine.**device1**.metric1中的“device1”这一层级即为设备<br>创建方式：无法仅创建设备，随时间序列创建而存在
|
+
#### 3.1.3 建模示例
##### 3.1.3.1 有多种类型的设备需要管理，如何建模？
diff --git
a/src/zh/UserGuide/latest/Background-knowledge/Data-Model-and-Terminology_timecho.md
b/src/zh/UserGuide/latest/Background-knowledge/Data-Model-and-Terminology_timecho.md
index 0686f14d..ab623290 100644
---
a/src/zh/UserGuide/latest/Background-knowledge/Data-Model-and-Terminology_timecho.md
+++
b/src/zh/UserGuide/latest/Background-knowledge/Data-Model-and-Terminology_timecho.md
@@ -33,8 +33,9 @@ IoTDB 提供了两种数据建模方式——树模型和表模型，其特点
**树模型**：以测点为对象进行管理，每个测点对应一条时间序列，测点名按`.`分割可形成一个树形目录结构，与物理世界一一对应，对测点的读写操作简单直观。
->
在构建树模型[路径](../Basic-Concept/Operate-Metadata_timecho.md#4-路径查询)时，节点命名若存在包含非标准字符或特殊符号的可能性，则建议对所有层级节点实施反引号封装策略。这样可以有效规避因字符解析异常导致的测点注册失败及数据写入中断问题，确保路径标识符在语法解析层面的准确性。
-
+> 1. 数据建模时，为了足够的性能要求，建议数据路径（Path）的倒数第二层节点（对应设备数量）不少于 1000
个，且设备数量与并发处理能力挂钩，设备数量充足时，并发读写效率更优。
+若遇到“设备数量较少但单设备测点数量较多”的场景（如仅 3 台设备，每台设备含 10000 个测点），推荐在最后层级新增 `.value`
，以此提升倒数第二层节点总数，示例：`root.db.device01.metric.value`。
+> 2.
在构建树模型[路径](../Basic-Concept/Operate-Metadata_timecho.md#4-路径查询)时，节点命名若存在包含非标准字符或特殊符号的可能性，则建议对所有层级节点实施反引号封装策略。这样可以有效规避因字符解析异常导致的测点注册失败及数据写入中断问题，确保路径标识符在语法解析层面的准确性。
**表模型**：推荐为每类设备创建一张表，同类设备的物理量采集都具备一定共性（如都采集温度和湿度物理量），数据分析灵活丰富。
@@ -111,6 +112,7 @@ IoTDB 提供了两种数据建模方式——树模型和表模型，其特点
| **时间序列（测点）** | 定义：<br>1. 一个以数据库路径为前缀的、由 . 分割的路径，可包含任意多个层级，如
root.db.turbine.device1.metric1 <br>2. 每个时间序列可以有不同的数据类型。<br>命名推荐:<br>1.
仅将唯一定位时间序列的标签（类似联合主键）放入路径中，一般不超过10层<br>2.
通常将基数（不同的取值数量）少的标签放在前面，便于系统将公共前缀进行压缩<br>数量推荐:<br>1.
集群可管理的时间序列总量和总内存相关，可参考资源推荐章节<br>2. 任一层级的子节点数量没有限制<br>创建方式：可手动创建或在数据写入时自动创建。 |
| **设备** | 定义：倒数第二级为设备，如
root.db.turbine.**device1**.metric1中的“device1”这一层级即为设备<br>创建方式：无法仅创建设备，随时间序列创建而存在
|
+
#### 3.1.3 建模示例
##### 3.1.3.1 有多种类型的设备需要管理，如何建模？
