add description about data model

Author: leto-bbq

src/UserGuide/Master/Tree/Background-knowledge/Data-Model-and-Terminology_apache.md

@@ -108,6 +108,8 @@ 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 system compression of common prefixes.<br>**Quantity Recommendation**:<br>The total number of time series manageable by the cluster is related to total memory; refer to the resource recommendation section.<br>There is no limit to the number of child nodes at any level.<br>**Creation Method**: Can be created manually or automatically during data writing. |
 | **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. |
 
+> When designing your data model, to ensure system performance and scalability, prioritize creating a large number of devices rather than accumulating an unlimited number of time series under a single device. Simultaneously, ensure that the cardinality of the penultimate node in the path reaches at least 1000 to provide sufficient concurrency granularity, and use suffixes such as .value at the end of the path to clearly identify data points—for example, it is recommended to adopt a high-concurrency model like root.db.device01.metric.value, rather than the inefficient structure of root.db.device01.metric.
+
 #### 3.1.3 Modeling Examples
 
 ##### 3.1.3.1 How to model when managing multiple types of devices?

src/UserGuide/Master/Tree/Background-knowledge/Data-Model-and-Terminology_timecho.md

@@ -110,6 +110,9 @@ 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 system compression of common prefixes.<br>**Quantity Recommendation**:<br>The total number of time series manageable by the cluster is related to total memory; refer to the resource recommendation section.<br>There is no limit to the number of child nodes at any level.<br>**Creation Method**: Can be created manually or automatically during data writing. |
 | **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. |
 
+
+> When designing your data model, to ensure system performance and scalability, prioritize creating a large number of devices rather than accumulating an unlimited number of time series under a single device. Simultaneously, ensure that the cardinality of the penultimate node in the path reaches at least 1000 to provide sufficient concurrency granularity, and use suffixes such as .value at the end of the path to clearly identify data points—for example, it is recommended to adopt a high-concurrency model like root.db.device01.metric.value, rather than the inefficient structure of root.db.device01.metric.
+
 #### 3.1.3 Modeling Examples
 
 ##### 3.1.3.1 How to model when managing multiple types of devices?

src/UserGuide/latest/Background-knowledge/Data-Model-and-Terminology_apache.md

@@ -108,6 +108,8 @@ 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 system compression of common prefixes.<br>**Quantity Recommendation**:<br>The total number of time series manageable by the cluster is related to total memory; refer to the resource recommendation section.<br>There is no limit to the number of child nodes at any level.<br>**Creation Method**: Can be created manually or automatically during data writing. |
 | **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. |
 
+> When designing your data model, to ensure system performance and scalability, prioritize creating a large number of devices rather than accumulating an unlimited number of time series under a single device. Simultaneously, ensure that the cardinality of the penultimate node in the path reaches at least 1000 to provide sufficient concurrency granularity, and use suffixes such as .value at the end of the path to clearly identify data points—for example, it is recommended to adopt a high-concurrency model like root.db.device01.metric.value, rather than the inefficient structure of root.db.device01.metric.
+
 #### 3.1.3 Modeling Examples
 
 ##### 3.1.3.1 How to model when managing multiple types of devices?

src/UserGuide/latest/Background-knowledge/Data-Model-and-Terminology_timecho.md

@@ -110,6 +110,8 @@ 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 system compression of common prefixes.<br>**Quantity Recommendation**:<br>The total number of time series manageable by the cluster is related to total memory; refer to the resource recommendation section.<br>There is no limit to the number of child nodes at any level.<br>**Creation Method**: Can be created manually or automatically during data writing. |
 | **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. |
 
+> When designing your data model, to ensure system performance and scalability, prioritize creating a large number of devices rather than accumulating an unlimited number of time series under a single device. Simultaneously, ensure that the cardinality of the penultimate node in the path reaches at least 1000 to provide sufficient concurrency granularity, and use suffixes such as .value at the end of the path to clearly identify data points—for example, it is recommended to adopt a high-concurrency model like root.db.device01.metric.value, rather than the inefficient structure of root.db.device01.metric.
+
 #### 3.1.3 Modeling Examples
 
 ##### 3.1.3.1 How to model when managing multiple types of devices?

src/zh/UserGuide/Master/Tree/Background-knowledge/Data-Model-and-Terminology_apache.md

@@ -109,6 +109,8 @@ 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>创建方式：无法仅创建设备，随时间序列创建而存在 |
 
+> 注意：在进行数据建模时，为保障系统性能与扩展性，应优先创建大量设备而非在单一设备下堆积无限序列，同时确保路径倒数第二层节点基数不少于1000以提供足够的并发粒度，并在路径末级使用.value等后缀明确标识数据点——例如，推荐采用root.db.device01.metric.value的高并发模型，而非root.db.device01.metric的低效结构。
+
 #### 3.1.3 建模示例
 
 ##### 3.1.3.1 有多种类型的设备需要管理，如何建模？

src/zh/UserGuide/Master/Tree/Background-knowledge/Data-Model-and-Terminology_timecho.md

@@ -111,6 +111,10 @@ 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>创建方式：无法仅创建设备，随时间序列创建而存在 |
 
+
+> 注意：在进行数据建模时，为保障系统性能与扩展性，应优先创建大量设备而非在单一设备下堆积无限序列，同时确保路径倒数第二层节点基数不少于1000以提供足够的并发粒度，并在路径末级使用.value等后缀明确标识数据点——例如，推荐采用root.db.device01.metric.value的高并发模型，而非root.db.device01.metric的低效结构。
+
+
 #### 3.1.3 建模示例
 
 ##### 3.1.3.1 有多种类型的设备需要管理，如何建模？

src/zh/UserGuide/latest/Background-knowledge/Data-Model-and-Terminology_apache.md

@@ -109,6 +109,8 @@ 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>创建方式：无法仅创建设备，随时间序列创建而存在 |
 
+> 注意：在进行数据建模时，为保障系统性能与扩展性，应优先创建大量设备而非在单一设备下堆积无限序列，同时确保路径倒数第二层节点基数不少于1000以提供足够的并发粒度，并在路径末级使用.value等后缀明确标识数据点——例如，推荐采用root.db.device01.metric.value的高并发模型，而非root.db.device01.metric的低效结构。
+
 #### 3.1.3 建模示例
 
 ##### 3.1.3.1 有多种类型的设备需要管理，如何建模？

src/zh/UserGuide/latest/Background-knowledge/Data-Model-and-Terminology_timecho.md

@@ -111,6 +111,9 @@ 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>创建方式：无法仅创建设备，随时间序列创建而存在 |
 
+> 注意：在进行数据建模时，为保障系统性能与扩展性，应优先创建大量设备而非在单一设备下堆积无限序列，同时确保路径倒数第二层节点基数不少于1000以提供足够的并发粒度，并在路径末级使用.value等后缀明确标识数据点——例如，推荐采用root.db.device01.metric.value的高并发模型，而非root.db.device01.metric的低效结构。
+
+
 #### 3.1.3 建模示例
 
 ##### 3.1.3.1 有多种类型的设备需要管理，如何建模？