update description about data model

Author: leto-bbq

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

@@ -108,7 +108,10 @@ 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.
+> Note:  
+> 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.
+
 
 #### 3.1.3 Modeling Examples
 

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

@@ -111,7 +111,9 @@ The application scenarios mainly include three categories:
 | **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.
+> Note:  
+> 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.
 
 #### 3.1.3 Modeling Examples
 

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

@@ -108,7 +108,9 @@ 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.
+> Note:  
+> 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.
 
 #### 3.1.3 Modeling Examples
 

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

@@ -110,7 +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.
+> Note:  
+> 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.
 
 #### 3.1.3 Modeling Examples
 

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

@@ -109,7 +109,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的低效结构。
+> 注意：
+> 数据建模时，为了足够的性能要求，建议数据路径（Path）的倒数第二层节点（对应设备数量）不少于 1000 个，且设备数量与并发处理能力挂钩，设备数量充足时，并发读写效率更优。  
+> 若遇到“设备数量较少但单设备测点数量较多”的场景（如仅 3 台设备，每台设备含 10000 个测点），推荐在最后层级新增 `.value` ，以此提升倒数第二层节点总数，示例：`root.db.device01.metric.value`。
 
 #### 3.1.3 建模示例
 

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

@@ -112,8 +112,9 @@ IoTDB 提供了两种数据建模方式——树模型和表模型，其特点
 | **设备**                 | 定义：倒数第二级为设备，如 root.db.turbine.**device1**.metric1中的“device1”这一层级即为设备<br>创建方式：无法仅创建设备，随时间序列创建而存在 |
 
 
-> 注意：在进行数据建模时，为保障系统性能与扩展性，应优先创建大量设备而非在单一设备下堆积无限序列，同时确保路径倒数第二层节点基数不少于1000以提供足够的并发粒度，并在路径末级使用.value等后缀明确标识数据点——例如，推荐采用root.db.device01.metric.value的高并发模型，而非root.db.device01.metric的低效结构。
-
+> 注意：
+> 数据建模时，为了足够的性能要求，建议数据路径（Path）的倒数第二层节点（对应设备数量）不少于 1000 个，且设备数量与并发处理能力挂钩，设备数量充足时，并发读写效率更优。  
+> 若遇到“设备数量较少但单设备测点数量较多”的场景（如仅 3 台设备，每台设备含 10000 个测点），推荐在最后层级新增 `.value` ，以此提升倒数第二层节点总数，示例：`root.db.device01.metric.value`。
 
 #### 3.1.3 建模示例
 

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

@@ -109,7 +109,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的低效结构。
+> 注意：
+> 数据建模时，为了足够的性能要求，建议数据路径（Path）的倒数第二层节点（对应设备数量）不少于 1000 个，且设备数量与并发处理能力挂钩，设备数量充足时，并发读写效率更优。  
+> 若遇到“设备数量较少但单设备测点数量较多”的场景（如仅 3 台设备，每台设备含 10000 个测点），推荐在最后层级新增 `.value` ，以此提升倒数第二层节点总数，示例：`root.db.device01.metric.value`。
 
 #### 3.1.3 建模示例
 

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

@@ -111,8 +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的低效结构。
-
+> 注意：
+> 数据建模时，为了足够的性能要求，建议数据路径（Path）的倒数第二层节点（对应设备数量）不少于 1000 个，且设备数量与并发处理能力挂钩，设备数量充足时，并发读写效率更优。  
+> 若遇到“设备数量较少但单设备测点数量较多”的场景（如仅 3 台设备，每台设备含 10000 个测点），推荐在最后层级新增 `.value` ，以此提升倒数第二层节点总数，示例：`root.db.device01.metric.value`。
 
 #### 3.1.3 建模示例