diff --git a/src/.vuepress/public/img/Modeling-scheme01.png b/src/.vuepress/public/img/Modeling-scheme01.png new file mode 100644 index 000000000..fb9022025 Binary files /dev/null and b/src/.vuepress/public/img/Modeling-scheme01.png differ diff --git a/src/.vuepress/public/img/Modeling-scheme02.png b/src/.vuepress/public/img/Modeling-scheme02.png new file mode 100644 index 000000000..87c5e5530 Binary files /dev/null and b/src/.vuepress/public/img/Modeling-scheme02.png differ diff --git a/src/.vuepress/public/img/Modeling-scheme03.png b/src/.vuepress/public/img/Modeling-scheme03.png new file mode 100644 index 000000000..f9d94cd86 Binary files /dev/null and b/src/.vuepress/public/img/Modeling-scheme03.png differ diff --git a/src/.vuepress/public/img/Modeling-scheme04.png b/src/.vuepress/public/img/Modeling-scheme04.png new file mode 100644 index 000000000..9dc839325 Binary files /dev/null and b/src/.vuepress/public/img/Modeling-scheme04.png differ diff --git a/src/.vuepress/public/img/Modeling-scheme05.png b/src/.vuepress/public/img/Modeling-scheme05.png new file mode 100644 index 000000000..505814251 Binary files /dev/null and b/src/.vuepress/public/img/Modeling-scheme05.png differ diff --git a/src/.vuepress/public/img/Modeling-scheme06.png b/src/.vuepress/public/img/Modeling-scheme06.png new file mode 100644 index 000000000..c25046c67 Binary files /dev/null and b/src/.vuepress/public/img/Modeling-scheme06.png differ diff --git "a/src/.vuepress/public/img/\345\273\272\346\250\241\346\226\271\346\241\210\350\256\276\350\256\24101.png" "b/src/.vuepress/public/img/\345\273\272\346\250\241\346\226\271\346\241\210\350\256\276\350\256\24101.png" new file mode 100644 index 000000000..d25d2d378 Binary files /dev/null and "b/src/.vuepress/public/img/\345\273\272\346\250\241\346\226\271\346\241\210\350\256\276\350\256\24101.png" differ diff --git a/src/zh/UserGuide/Master/Table/Background-knowledge/Data-Model-and-Terminology.md b/src/zh/UserGuide/Master/Table/Background-knowledge/Data-Model-and-Terminology.md index 65fc48659..2defd48f0 100644 --- a/src/zh/UserGuide/Master/Table/Background-knowledge/Data-Model-and-Terminology.md +++ b/src/zh/UserGuide/Master/Table/Background-knowledge/Data-Model-and-Terminology.md @@ -29,56 +29,81 @@ ## 2 IoTDB 的两种时序模型 -> IoTDB 提供了两种数据建模方式——树模型和表模型，以满足用户多样化的应用需求。 +> IoTDB 提供了两种数据建模方式——树模型和表模型，其特点分别如下： -### 2.1 树模型 +**树模型**：以测点为对象进行管理，每个测点对应一条时间序列，测点名按`.`分割可形成一个树形目录结构，与物理世界一一对应，对测点的读写操作简单直观。 -以测点为单元进行管理，每个测点对应一条时间序列，测点名按逗号分割可看作一个树形目录结构，与物理世界一一对应，简单直观。 +**表模型**：推荐为每类设备创建一张表，同类设备的物理量采集都具备一定共性（如都采集温度和湿度物理量），数据分析灵活丰富。 -示例：下图是一个风电场的建模管理，通过多个层级【集团】-【风电场】-【风机】-【物理量】可以唯一确定一个实体测点。 +### 2.1 模型特点 -
- -
+两种模型有各自的适用场景。 -### 2.2 表模型 +以下表格从适用场景、典型操作等多个维度对树模型和表模型进行了对比。用户可以根据具体的使用需求，选择适合的模型，从而实现数据的高效存储和管理。 -一张表管理一类设备。下图是一个工厂设备的建模管理，每个设备的物理量采集都具备一定共性（如都采集温度和湿度物理量、同一设备的物理量同频采集等）。 -此时通过【地区】-【工厂】-【设备】（下图橙色列，又称设备标签）可以唯一确定一个实体设备，同时一个设备的描述信息【型号】【维护周期】（下图黄色列，又称设备属性/描述信息）也可在表格里进行记录。设备最终采集的指标为【温度】、【湿度】、【状态】、【到达时间】（下图蓝色列）。 + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
对比维度树模型表模型
适用场景测点管理，监控场景设备管理，分析场景
典型操作指定点位路径进行读写通过标签进行数据筛选分析
结构特点和文件系统一样灵活增删模板化管理，便于数据治理
语法特点简洁标准
性能对比相同
-
- -
+**注意：** +- 同一个集群实例中可以存在两种模型空间，不同模型的语法、数据库命名方式不同，默认不互相可见。 -### 2.3 模型选择 +- 在通过客户端工具 Cli 或 SDK 建立数据库连接时，需要通过 sql_dialect 参数指定使用的模型语法（默认使用树语法进行操作）。 -两种模型有各自的适用场景。 -树模型采用层级式结构，适合实时监控场景，能够直观映射物理设备的层级关系；表模型以设备为管理单位，适合大规模设备的数据管理和多属性关联分析，能够高效支持复杂的批量查询需求。 +## 应用场景 -以下表格从适用场景、典型操作等多个维度对树模型和表模型进行了对比。用户可以根据具体的使用需求，选择适合的模型，从而实现数据的高效存储和管理。 +应用场景主要包括三类： -| 对比维度 | 树模型 | 表模型 | -| -------- | ---------------------- | ------------------------ | -| 适用场景 | 点位监控场景 | 多维分析场景 | -| 典型操作 | 指定点位路径进行读写 | 通过标签进行数据筛选分析 | -| 结构特点 | 和文件系统一样灵活增删 | 模板化管理，便于数据治理 | -| 语法特点 | 简洁 | 标准 | +- 场景一：使用树模型进行数据的读写 -**注意：** -- 同一个集群实例中可以存在两种模型空间，不同模型的语法、数据库命名方式不同，默认不互相可见。 -- 在通过客户端工具 Cli 或 SDK 建立数据库连接时，需要通过 sql_dialect 参数指定使用的模型语法（默认使用树语法进行操作）。 +- 场景二：使用表模型进行数据的读写 + +- 场景三：共用一份数据，使用树模型进行数据读写、使用表模型进行数据分析 -## 3 树模型 +![](/img/%E5%BB%BA%E6%A8%A1%E6%96%B9%E6%A1%88%E8%AE%BE%E8%AE%A101.png) -### 3.1 特点 + +### 3 场景一：树模型 + +#### 3.1 特点 - 简单直观，和物理世界的监测点位一一对应 + - 类似文件系统一样灵活，可以设计任意分支结构 + - 适用 DCS、SCADA 等工业监控场景 -### 3.2 基础概念 +#### 3.2 基础概念 | **概念** | **定义** | | -------------------- | ------------------------------------------------------------ | @@ -86,17 +111,17 @@ | **时间序列（测点）** | 定义：
1. 一个以数据库路径为前缀的、由 . 分割的路径，可包含任意多个层级，如 root.db.turbine.device1.metric1
2. 每个时间序列可以有不同的数据类型。
命名推荐:
1. 仅将唯一定位时间序列的标签（类似联合主键）放入路径中，一般不超过10层
2. 通常将基数（不同的取值数量）少的标签放在前面，便于系统将公共前缀进行压缩
数量推荐:
1. 集群可管理的时间序列总量和总内存相关，可参考资源推荐章节
2. 任一层级的子节点数量没有限制
创建方式：可手动创建或在数据写入时自动创建。 | | **设备** | 定义：倒数第二级为设备，如 root.db.turbine.**device1**.metric1中的“device1”这一层级即为设备
创建方式：无法仅创建设备，随时间序列创建而存在 | -### 3.3 建模示例 +#### 3.3 建模示例 -#### 3.3.1 有多种类型的设备需要管理，如何建模？ +##### 3.3.1 有多种类型的设备需要管理，如何建模？ - 如场景中不同类型的设备具备不同的层级路径和测点集合，可以在数据库节点下按设备类型创建分支。每种设备下可以有不同的测点结构。
- +
-#### 3.3.2 如果场景中没有设备，只有测点，如何建模？ +##### 3.3.2 如果场景中没有设备，只有测点，如何建模？ - 如场站的监控系统中，每个测点都有唯一编号，但无法对应到某些设备。 @@ -104,30 +129,32 @@ -#### 3.3.3 如果在一个设备下，既有子设备，也有测点，如何建模？ +##### 3.3.3 如果在一个设备下，既有子设备，也有测点，如何建模？ -- 如在储能场景中，每一层结构都要监控其电压和电流，可以采用如下建模方式 +- 如在储能场景中，每一层结构都要监控其电压和电流，可以采用如下建模方式。
- +
-## 4 表模型 +### 4 场景二：表模型 + +#### 4.1 特点 -### 4.1 特点 +- 以时序表建模管理设备时序数据，便于使用标准 SQL 进行分析 -- 以标准关系建模管理设备时序数据，便于使用标准 SQL 进行分析 -- 适用物联网数据分析场景，或从其他时序数据库迁移至 IoTDB 的场景 +- 适用于设备数据分析或从其他数据库迁移至 IoTDB 的场景 -### 4.2 基础概念 +#### 4.2 基础概念 - 数据库：可管理多类设备 + - 时序表：对应一类设备 | **列类别** | **定义** | | --------------------------- | ------------------------------------------------------------ | -| **时间列（TIME）** | 每个时序表必须有一个时间列，数据类型为 TIMESTAMP，名称可以自定义 | +| **时间列（TIME）** | 每个时序表必须有一个时间列，且列名必须为 time，数据类型为 TIMESTAMP | | **标签列（TAG）** | 设备的唯一标识（联合主键），可以为 0 至多个
标签信息不可修改和删除，但允许增加
推荐按粒度由大到小进行排列 | | **测点列（FIELD）** | 一个设备采集的测点可以有1个至多个，值随时间变化
表的测点列没有数量限制，可以达到数十万以上 | | **属性列（ATTRIBUTE）** | 对设备的补充描述，**不随时间变化**
设备属性信息可以有0个或多个，可以更新或新增
少量希望修改的静态属性可以存至此列 | @@ -135,17 +162,18 @@ 数据筛选效率：时间列=标签列>属性列>测点列 -### 4.3 建模示例 +#### 4.3 建模示例 -#### 4.3.1 有多种类型的设备需要管理，如何建模？ +##### 4.3.1 有多种类型的设备需要管理，如何建模？ -- 推荐为每一类型的设备建立一张表，每个表可以具有不同的标签和测点集合 +- 推荐为每一类型的设备建立一张表，每个表可以具有不同的标签和测点集合。 +- 即使设备之间有联系，或有层级关系，也推荐为每一类设备建一张表。
-#### 4.3.2 如果没有设备标识列和属性列，如何建模？ +##### 4.3.2 如果没有设备标识列和属性列，如何建模？ - 列数没有数量限制，可以达到数十万以上。 @@ -153,10 +181,54 @@ -#### 4.3.3 如果在一个设备下，既有子设备，也有测点，如何建模？ +##### 4.3.3 如果在一个设备下，既有子设备，也有测点，如何建模？ -- 设备之间存在嵌套关系，每个设备可以有多个子设备及测点信息，推荐建立多个表进行管理。 +- 每个设备有多个子设备及测点信息，推荐为每类设备建一个表进行管理。
- -
\ No newline at end of file + + + +### 5 场景三：双模型结合（企业版功能） + +#### 5.1 特点 + +- 巧妙融合了树模型与表模型的优点，共用一份数据，写入灵活，查询丰富。 + +- 数据写入阶段，采用树模型语法，支持数据灵活接入和扩展。 + +- 数据分析阶段，采用表模型语法，允许用户通过标准 SQL 查询语言，执行复杂的数据分析。 + +#### 5.2 建模示例 + +##### 5.2.1 有多种类型的设备需要管理，如何建模？ + +- 场景中不同类型的设备具备不同的层级路径和测点集合。 + +- 树模型：在数据库节点下按设备类型创建分支，每种设备下可以有不同的测点结构。 + +- 表视图：为每种类型的设备建立一张表视图，每个表视图具有不同的标签和测点集合。 + +
+ +
+ +##### 5.2.2 如果没有设备标识列和属性列，如何建模？ + +- 树模型：每个测点都有唯一编号，但无法对应到某些设备。 + +- 表视图：将所有测点放入一张表中，测点列数没有数量限制，可以达到数十万以上。若测点具有相同的数据类型，可将测点作为同一类设备。 + +
+ +
+ +##### 5.2.3 如果在一个设备下，既有子设备，也有测点，如何建模？ + +- 树模型：按照物理世界的监测点，对每一层结构进行建模。 + +- 表视图：按照设备分类，建立多个表对每一层结构信息进行管理。 + +
+ +
diff --git a/src/zh/UserGuide/latest-Table/Background-knowledge/Data-Model-and-Terminology.md b/src/zh/UserGuide/latest-Table/Background-knowledge/Data-Model-and-Terminology.md index 65fc48659..2defd48f0 100644 --- a/src/zh/UserGuide/latest-Table/Background-knowledge/Data-Model-and-Terminology.md +++ b/src/zh/UserGuide/latest-Table/Background-knowledge/Data-Model-and-Terminology.md @@ -29,56 +29,81 @@ ## 2 IoTDB 的两种时序模型 -> IoTDB 提供了两种数据建模方式——树模型和表模型，以满足用户多样化的应用需求。 +> IoTDB 提供了两种数据建模方式——树模型和表模型，其特点分别如下： -### 2.1 树模型 +**树模型**：以测点为对象进行管理，每个测点对应一条时间序列，测点名按`.`分割可形成一个树形目录结构，与物理世界一一对应，对测点的读写操作简单直观。 -以测点为单元进行管理，每个测点对应一条时间序列，测点名按逗号分割可看作一个树形目录结构，与物理世界一一对应，简单直观。 +**表模型**：推荐为每类设备创建一张表，同类设备的物理量采集都具备一定共性（如都采集温度和湿度物理量），数据分析灵活丰富。 -示例：下图是一个风电场的建模管理，通过多个层级【集团】-【风电场】-【风机】-【物理量】可以唯一确定一个实体测点。 +### 2.1 模型特点 -
- -
+两种模型有各自的适用场景。 -### 2.2 表模型 +以下表格从适用场景、典型操作等多个维度对树模型和表模型进行了对比。用户可以根据具体的使用需求，选择适合的模型，从而实现数据的高效存储和管理。 -一张表管理一类设备。下图是一个工厂设备的建模管理，每个设备的物理量采集都具备一定共性（如都采集温度和湿度物理量、同一设备的物理量同频采集等）。 -此时通过【地区】-【工厂】-【设备】（下图橙色列，又称设备标签）可以唯一确定一个实体设备，同时一个设备的描述信息【型号】【维护周期】（下图黄色列，又称设备属性/描述信息）也可在表格里进行记录。设备最终采集的指标为【温度】、【湿度】、【状态】、【到达时间】（下图蓝色列）。 + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
对比维度树模型表模型
适用场景测点管理，监控场景设备管理，分析场景
典型操作指定点位路径进行读写通过标签进行数据筛选分析
结构特点和文件系统一样灵活增删模板化管理，便于数据治理
语法特点简洁标准
性能对比相同
-
- -
+**注意：** +- 同一个集群实例中可以存在两种模型空间，不同模型的语法、数据库命名方式不同，默认不互相可见。 -### 2.3 模型选择 +- 在通过客户端工具 Cli 或 SDK 建立数据库连接时，需要通过 sql_dialect 参数指定使用的模型语法（默认使用树语法进行操作）。 -两种模型有各自的适用场景。 -树模型采用层级式结构，适合实时监控场景，能够直观映射物理设备的层级关系；表模型以设备为管理单位，适合大规模设备的数据管理和多属性关联分析，能够高效支持复杂的批量查询需求。 +## 应用场景 -以下表格从适用场景、典型操作等多个维度对树模型和表模型进行了对比。用户可以根据具体的使用需求，选择适合的模型，从而实现数据的高效存储和管理。 +应用场景主要包括三类： -| 对比维度 | 树模型 | 表模型 | -| -------- | ---------------------- | ------------------------ | -| 适用场景 | 点位监控场景 | 多维分析场景 | -| 典型操作 | 指定点位路径进行读写 | 通过标签进行数据筛选分析 | -| 结构特点 | 和文件系统一样灵活增删 | 模板化管理，便于数据治理 | -| 语法特点 | 简洁 | 标准 | +- 场景一：使用树模型进行数据的读写 -**注意：** -- 同一个集群实例中可以存在两种模型空间，不同模型的语法、数据库命名方式不同，默认不互相可见。 -- 在通过客户端工具 Cli 或 SDK 建立数据库连接时，需要通过 sql_dialect 参数指定使用的模型语法（默认使用树语法进行操作）。 +- 场景二：使用表模型进行数据的读写 + +- 场景三：共用一份数据，使用树模型进行数据读写、使用表模型进行数据分析 -## 3 树模型 +![](/img/%E5%BB%BA%E6%A8%A1%E6%96%B9%E6%A1%88%E8%AE%BE%E8%AE%A101.png) -### 3.1 特点 + +### 3 场景一：树模型 + +#### 3.1 特点 - 简单直观，和物理世界的监测点位一一对应 + - 类似文件系统一样灵活，可以设计任意分支结构 + - 适用 DCS、SCADA 等工业监控场景 -### 3.2 基础概念 +#### 3.2 基础概念 | **概念** | **定义** | | -------------------- | ------------------------------------------------------------ | @@ -86,17 +111,17 @@ | **时间序列（测点）** | 定义：
1. 一个以数据库路径为前缀的、由 . 分割的路径，可包含任意多个层级，如 root.db.turbine.device1.metric1
2. 每个时间序列可以有不同的数据类型。
命名推荐:
1. 仅将唯一定位时间序列的标签（类似联合主键）放入路径中，一般不超过10层
2. 通常将基数（不同的取值数量）少的标签放在前面，便于系统将公共前缀进行压缩
数量推荐:
1. 集群可管理的时间序列总量和总内存相关，可参考资源推荐章节
2. 任一层级的子节点数量没有限制
创建方式：可手动创建或在数据写入时自动创建。 | | **设备** | 定义：倒数第二级为设备，如 root.db.turbine.**device1**.metric1中的“device1”这一层级即为设备
创建方式：无法仅创建设备，随时间序列创建而存在 | -### 3.3 建模示例 +#### 3.3 建模示例 -#### 3.3.1 有多种类型的设备需要管理，如何建模？ +##### 3.3.1 有多种类型的设备需要管理，如何建模？ - 如场景中不同类型的设备具备不同的层级路径和测点集合，可以在数据库节点下按设备类型创建分支。每种设备下可以有不同的测点结构。
- +
-#### 3.3.2 如果场景中没有设备，只有测点，如何建模？ +##### 3.3.2 如果场景中没有设备，只有测点，如何建模？ - 如场站的监控系统中，每个测点都有唯一编号，但无法对应到某些设备。 @@ -104,30 +129,32 @@ -#### 3.3.3 如果在一个设备下，既有子设备，也有测点，如何建模？ +##### 3.3.3 如果在一个设备下，既有子设备，也有测点，如何建模？ -- 如在储能场景中，每一层结构都要监控其电压和电流，可以采用如下建模方式 +- 如在储能场景中，每一层结构都要监控其电压和电流，可以采用如下建模方式。
- +
-## 4 表模型 +### 4 场景二：表模型 + +#### 4.1 特点 -### 4.1 特点 +- 以时序表建模管理设备时序数据，便于使用标准 SQL 进行分析 -- 以标准关系建模管理设备时序数据，便于使用标准 SQL 进行分析 -- 适用物联网数据分析场景，或从其他时序数据库迁移至 IoTDB 的场景 +- 适用于设备数据分析或从其他数据库迁移至 IoTDB 的场景 -### 4.2 基础概念 +#### 4.2 基础概念 - 数据库：可管理多类设备 + - 时序表：对应一类设备 | **列类别** | **定义** | | --------------------------- | ------------------------------------------------------------ | -| **时间列（TIME）** | 每个时序表必须有一个时间列，数据类型为 TIMESTAMP，名称可以自定义 | +| **时间列（TIME）** | 每个时序表必须有一个时间列，且列名必须为 time，数据类型为 TIMESTAMP | | **标签列（TAG）** | 设备的唯一标识（联合主键），可以为 0 至多个
标签信息不可修改和删除，但允许增加
推荐按粒度由大到小进行排列 | | **测点列（FIELD）** | 一个设备采集的测点可以有1个至多个，值随时间变化
表的测点列没有数量限制，可以达到数十万以上 | | **属性列（ATTRIBUTE）** | 对设备的补充描述，**不随时间变化**
设备属性信息可以有0个或多个，可以更新或新增
少量希望修改的静态属性可以存至此列 | @@ -135,17 +162,18 @@ 数据筛选效率：时间列=标签列>属性列>测点列 -### 4.3 建模示例 +#### 4.3 建模示例 -#### 4.3.1 有多种类型的设备需要管理，如何建模？ +##### 4.3.1 有多种类型的设备需要管理，如何建模？ -- 推荐为每一类型的设备建立一张表，每个表可以具有不同的标签和测点集合 +- 推荐为每一类型的设备建立一张表，每个表可以具有不同的标签和测点集合。 +- 即使设备之间有联系，或有层级关系，也推荐为每一类设备建一张表。
-#### 4.3.2 如果没有设备标识列和属性列，如何建模？ +##### 4.3.2 如果没有设备标识列和属性列，如何建模？ - 列数没有数量限制，可以达到数十万以上。 @@ -153,10 +181,54 @@ -#### 4.3.3 如果在一个设备下，既有子设备，也有测点，如何建模？ +##### 4.3.3 如果在一个设备下，既有子设备，也有测点，如何建模？ -- 设备之间存在嵌套关系，每个设备可以有多个子设备及测点信息，推荐建立多个表进行管理。 +- 每个设备有多个子设备及测点信息，推荐为每类设备建一个表进行管理。
- -
\ No newline at end of file + + + +### 5 场景三：双模型结合（企业版功能） + +#### 5.1 特点 + +- 巧妙融合了树模型与表模型的优点，共用一份数据，写入灵活，查询丰富。 + +- 数据写入阶段，采用树模型语法，支持数据灵活接入和扩展。 + +- 数据分析阶段，采用表模型语法，允许用户通过标准 SQL 查询语言，执行复杂的数据分析。 + +#### 5.2 建模示例 + +##### 5.2.1 有多种类型的设备需要管理，如何建模？ + +- 场景中不同类型的设备具备不同的层级路径和测点集合。 + +- 树模型：在数据库节点下按设备类型创建分支，每种设备下可以有不同的测点结构。 + +- 表视图：为每种类型的设备建立一张表视图，每个表视图具有不同的标签和测点集合。 + +
+ +
+ +##### 5.2.2 如果没有设备标识列和属性列，如何建模？ + +- 树模型：每个测点都有唯一编号，但无法对应到某些设备。 + +- 表视图：将所有测点放入一张表中，测点列数没有数量限制，可以达到数十万以上。若测点具有相同的数据类型，可将测点作为同一类设备。 + +
+ +
+ +##### 5.2.3 如果在一个设备下，既有子设备，也有测点，如何建模？ + +- 树模型：按照物理世界的监测点，对每一层结构进行建模。 + +- 表视图：按照设备分类，建立多个表对每一层结构信息进行管理。 + +
+ +