From e29b83f4c750060d0046c822cc73a674f9dab652 Mon Sep 17 00:00:00 2001 From: Leto_b Date: Tue, 3 Feb 2026 10:17:53 +0800 Subject: [PATCH] adjust tree or table model to mode --- .../Cluster-Concept_apache.md | 10 +-- .../Cluster-Concept_timecho.md | 10 +-- .../Data-Model-and-Terminology_apache.md | 56 ++++++------ .../Data-Model-and-Terminology_timecho.md | 80 ++++++++--------- .../Tree/API/Programming-Go-Native-API.md | 4 +- .../Data-Model-and-Terminology_apache.md | 62 +++++++------- .../Data-Model-and-Terminology_timecho.md | 85 +++++++++---------- .../API/Programming-JDBC_apache.md | 2 +- .../API/Programming-JDBC_timecho.md | 2 +- .../latest-Table/API/Programming-MQTT.md | 16 ++-- .../Cluster-Concept_apache.md | 10 +-- .../Cluster-Concept_timecho.md | 10 +-- .../Data-Model-and-Terminology_apache.md | 56 ++++++------ .../Data-Model-and-Terminology_timecho.md | 80 ++++++++--------- .../Ecosystem-Integration/DBeaver.md | 2 +- .../Release-history_apache.md | 4 +- .../latest-Table/Reference/Sample-Data.md | 2 +- .../latest-Table/SQL-Manual/Basis-Function.md | 12 +-- .../SQL-Manual/From-Join-Clause.md | 2 +- .../latest-Table/SQL-Manual/Keywords.md | 2 +- .../SQL-Manual/SQL-Maintenance-Statements.md | 4 +- .../latest-Table/Tools-System/Benchmark.md | 40 ++++----- .../User-Manual/Data-Sync_apache.md | 2 +- .../User-Manual/Data-Sync_timecho.md | 2 +- .../User-Manual/User-defined-function.md | 4 +- .../latest/API/Programming-Go-Native-API.md | 4 +- src/UserGuide/latest/API/Programming-MQTT.md | 16 ++-- .../latest/API/Programming-OPC-UA_timecho.md | 2 +- .../Cluster-Concept_apache.md | 4 +- .../Cluster-Concept_timecho.md | 4 +- .../Data-Model-and-Terminology_apache.md | 60 ++++++------- .../Data-Model-and-Terminology_timecho.md | 84 +++++++++--------- .../latest/Ecosystem-Integration/DBeaver.md | 2 +- .../Release-history_apache.md | 16 ++-- .../Release-history_timecho.md | 6 +- .../latest/Tools-System/Benchmark.md | 28 +++--- .../latest/User-Manual/Data-Sync_apache.md | 22 ++--- .../latest/User-Manual/Data-Sync_timecho.md | 2 +- .../User-Manual/Maintenance-commands.md | 4 +- 39 files changed, 406 insertions(+), 407 deletions(-) diff --git a/src/UserGuide/Master/Table/Background-knowledge/Cluster-Concept_apache.md b/src/UserGuide/Master/Table/Background-knowledge/Cluster-Concept_apache.md index 931a75b3d..8d4b99869 100644 --- a/src/UserGuide/Master/Table/Background-knowledge/Cluster-Concept_apache.md +++ b/src/UserGuide/Master/Table/Background-knowledge/Cluster-Concept_apache.md @@ -25,12 +25,12 @@ ### 1.1 sql_dialect -IoTDB supports two time-series data models (SQL dialects), both managing devices and measurement points: +IoTDB supports two time-series data mode (SQL dialects), both managing devices and measurement points: -- **Tree** **Model**: Organizes data in a hierarchical path structure, where each path represents a measurement point of a device. -- **Table** **Model**: Organizes data in a relational table format, where each table corresponds to a type of device. +- **Tree** **Mode**: Organizes data in a hierarchical path structure, where each path represents a measurement point of a device. +- **Table** **Mode**: Organizes data in a relational table format, where each table corresponds to a type of device. -Each dialect comes with its own SQL syntax and query patterns tailored to its data model. +Each dialect comes with its own SQL syntax and query patterns tailored to its data mode. ### 1.2 Schema @@ -73,7 +73,7 @@ An IoTDB cluster consists of three types of nodes, each with distinct responsibi - **ConfigNode (Management Node)** Manages cluster metadata, configuration, user permissions, schema, and partitioning. It also handles distributed scheduling and load balancing. All ConfigNodes are replicated for high availability. - **DataNode (Storage and Computation Node)** Handles client requests, stores data, and executes computations. -- **AINode (Analytics Node)** Provides machine learning capabilities, allowing users to register pre-trained models and perform inference via SQL. It includes built-in time-series models and common ML algorithms for tasks like prediction and anomaly detection. +- **AINode (Analytics Node)** Provides machine learning capabilities, allowing users to register pre-trained models and perform inference via SQL. It includes built-in time-series mode and common ML algorithms for tasks like prediction and anomaly detection. ### 2.3 Data Partitioning diff --git a/src/UserGuide/Master/Table/Background-knowledge/Cluster-Concept_timecho.md b/src/UserGuide/Master/Table/Background-knowledge/Cluster-Concept_timecho.md index 236489032..651a353cd 100644 --- a/src/UserGuide/Master/Table/Background-knowledge/Cluster-Concept_timecho.md +++ b/src/UserGuide/Master/Table/Background-knowledge/Cluster-Concept_timecho.md @@ -25,12 +25,12 @@ ### 1.1 sql_dialect -IoTDB supports two time-series data models (SQL dialects), both managing devices and measurement points: +IoTDB supports two time-series data mode (SQL dialects), both managing devices and measurement points: -- **Tree** **Model**: Organizes data in a hierarchical path structure, where each path represents a measurement point of a device. -- **Table** **Model**: Organizes data in a relational table format, where each table corresponds to a type of device. +- **Tree** **Mode**: Organizes data in a hierarchical path structure, where each path represents a measurement point of a device. +- **Table** **Mode**: Organizes data in a relational table format, where each table corresponds to a type of device. -Each dialect comes with its own SQL syntax and query patterns tailored to its data model. +Each dialect comes with its own SQL syntax and query patterns tailored to its data mode. ### 1.2 Schema @@ -74,7 +74,7 @@ An IoTDB cluster consists of three types of nodes, each with distinct responsibi - **ConfigNode (Management Node)** Manages cluster metadata, configuration, user permissions, schema, and partitioning. It also handles distributed scheduling and load balancing. All ConfigNodes are replicated for high availability. - **DataNode (Storage and Computation Node)** Handles client requests, stores data, and executes computations. -- **AINode (Analytics Node)** Provides machine learning capabilities, allowing users to register pre-trained models and perform inference via SQL. It includes built-in time-series models and common ML algorithms for tasks like prediction and anomaly detection. +- **AINode (Analytics Node)** Provides machine learning capabilities, allowing users to register pre-trained models and perform inference via SQL. It includes built-in time-series modes and common ML algorithms for tasks like prediction and anomaly detection. ### 2.3 Data Partitioning diff --git a/src/UserGuide/Master/Table/Background-knowledge/Data-Model-and-Terminology_apache.md b/src/UserGuide/Master/Table/Background-knowledge/Data-Model-and-Terminology_apache.md index c6d7e9739..f044ecd7f 100644 --- a/src/UserGuide/Master/Table/Background-knowledge/Data-Model-and-Terminology_apache.md +++ b/src/UserGuide/Master/Table/Background-knowledge/Data-Model-and-Terminology_apache.md @@ -21,31 +21,31 @@ # Modeling Scheme Design -This section introduces how to transform time series data application scenarios into IoTDB time series modeling. +This section introduces how to transform time series data application scenarios into IoTDB time series mode. -## 1. Time Series Data Model +## 1. Time Series Data Mode -Before designing an IoTDB data model, it's essential to understand time series data and its underlying structure. For more details, refer to: [Time Series Data Model](../Background-knowledge/Navigating_Time_Series_Data.md) +Before designing an IoTDB data mode, it's essential to understand time series data and its underlying structure. For more details, refer to: [Time Series Data Mode](../Background-knowledge/Navigating_Time_Series_Data.md) -## 2. Two Time Series Model in IoTDB +## 2. Two Time Series Mode in IoTDB -IoTDB offers two data modeling syntaxes—tree model and table model, each with its distinct characteristics as follows: +IoTDB offers two data mode syntaxes—tree mode and table mode, each with its distinct characteristics as follows: -**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. +**Tree Mode**: 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. -**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. +**Table Mode**: 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. -### 2.1 Model Characteristics +### 2.1 Mode Characteristics -Both model syntaxes have their own applicable scenarios. +Both mode syntaxes have their own applicable scenarios. -The following table compares the tree model and the table model from various dimensions, including applicable scenarios and typical operations. Users can choose the appropriate model based on their specific usage requirements to achieve efficient data storage and management. +The following table compares the tree mode and the table mode from various dimensions, including applicable scenarios and typical operations. Users can choose the appropriate mode based on their specific usage requirements to achieve efficient data storage and management. - - + + @@ -75,20 +75,20 @@ The following table compares the tree model and the table model from various dim **Notes:** -- Both model spaces can coexist within the same cluster instance. Each model follows distinct syntax and database naming conventions, and they remain isolated by default. +- Both mode spaces can coexist within the same cluster instance. Each mode follows distinct syntax and database naming conventions, and they remain isolated by default. -- When establishing a database connection via client tools (Cli) or SDKs, specify the model syntax using the `sql_dialect` parameter (Tree syntax is used by default). +- When establishing a database connection via client tools (Cli) or SDKs, specify the mode syntax using the `sql_dialect` parameter (Tree syntax is used by default). ## 3. Application Scenarios The application scenarios mainly include two categories: -- Scenario 1: Using the tree model for data reading and writing. +- Scenario 1: Using the tree mode for data reading and writing. -- Scenario 2: Using the table model for data reading and writing. +- Scenario 2: Using the table mode for data reading and writing. -### 3.1 Scenario 1: Tree Model +### 3.1 Scenario 1: Tree Mode #### 3.1.1 Characteristics @@ -106,9 +106,9 @@ The application scenarios mainly include two categories: | **Time Series (Data Point)** | **Definition**:
A path prefixed with the database path, segmented by `.`, and can contain any number of levels, such as `root.db.turbine.device1.metric1`.
Each time series can have different data types.
**Naming Recommendation**:
Only include unique identifiers (similar to a composite primary key) in the path, generally not exceeding 10 levels.
Typically, place tags with low cardinality (fewer distinct values) at the front to facilitate system compression of common prefixes.
**Quantity Recommendation**:
The total number of time series manageable by the cluster is related to total memory; refer to the resource recommendation section.
There is no limit to the number of child nodes at any level.
**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`.
**Creation Method**: Cannot create a device alone; it exists as time series are created. | -#### 3.1.3 Modeling Examples +#### 3.1.3 Mode Examples -##### 3.1.3.1 How to model when managing multiple types of devices? +##### 3.1.3.1 How to mode when managing multiple types of devices? - If different types of devices in the scenario have different hierarchical paths and data point sets, create branches under the database node by device type. Each device type can have a different data point structure. @@ -116,7 +116,7 @@ The application scenarios mainly include two categories: -##### 3.1.3.2 How to model when there are no devices, only data points? +##### 3.1.3.2 How to mode when there are no devices, only data points? - For example, in a monitoring system for a station, each data point has a unique number but does not correspond to any specific device. @@ -124,20 +124,20 @@ The application scenarios mainly include two categories: -##### 3.1.3.3 How to model when a device has both sub-devices and data points? +##### 3.1.3.3 How to mode when a device has both sub-devices and data points? -- For example, in an energy storage scenario, each layer of the structure monitors its voltage and current. The following modeling approach can be used. +- For example, in an energy storage scenario, each layer of the structure monitors its voltage and current. The following mode approach can be used.
-### 3.2 Scenario 2: Table Model +### 3.2 Scenario 2: Table Mode #### 3.2.1 Characteristics -- Models and manages device time series data using time series tables, facilitating analysis with standard SQL. +- Modes and manages device time series data using time series tables, facilitating analysis with standard SQL. - Suitable for device data analysis or migrating data from other databases to IoTDB. @@ -156,9 +156,9 @@ The application scenarios mainly include two categories: **Data Filtering Efficiency**: Time Column = Tag Column > Attribute Column > Data Point Column. -#### 3.2.3 Modeling Examples +#### 3.2.3 Mode Examples -##### 3.2.3.1 How to model when managing multiple types of devices? +##### 3.2.3.1 How to mode when managing multiple types of devices? - Recommended to create a table for each type of device, with each table having different tags and data point sets. @@ -168,7 +168,7 @@ The application scenarios mainly include two categories: -##### 3.2.3.2 How to model when there are no device identifier columns or attribute columns? +##### 3.2.3.2 How to mode when there are no device identifier columns or attribute columns? - There is no limit to the number of columns; it can reach hundreds of thousands. @@ -176,7 +176,7 @@ The application scenarios mainly include two categories: -##### 3.2.3.3 How to model when a device has both sub-devices and data points? +##### 3.2.3.3 How to mode when a device has both sub-devices and data points? - Each device has multiple sub-devices and data point information. It is recommended to create a table for each type of device for management. diff --git a/src/UserGuide/Master/Table/Background-knowledge/Data-Model-and-Terminology_timecho.md b/src/UserGuide/Master/Table/Background-knowledge/Data-Model-and-Terminology_timecho.md index df755ac48..9b0cfd84e 100644 --- a/src/UserGuide/Master/Table/Background-knowledge/Data-Model-and-Terminology_timecho.md +++ b/src/UserGuide/Master/Table/Background-knowledge/Data-Model-and-Terminology_timecho.md @@ -21,31 +21,31 @@ # Modeling Scheme Design -This section introduces how to transform time series data application scenarios into IoTDB time series modeling. +This section introduces how to transform time series data application scenarios into IoTDB time series mode. -## 1. Time Series Data Model +## 1. Time Series Data Mode -Before designing an IoTDB data model, it's essential to understand time series data and its underlying structure. For more details, refer to: [Time Series Data Model](../Background-knowledge/Navigating_Time_Series_Data.md) +Before designing an IoTDB data mode, it's essential to understand time series data and its underlying structure. For more details, refer to: [Time Series Data Mode](../Background-knowledge/Navigating_Time_Series_Data.md) -## 2. Two Time Series Model in IoTDB +## 2. Two Time Series Mode in IoTDB -IoTDB offers two data modeling syntaxes—tree model and table model, each with its distinct characteristics as follows: +IoTDB offers two data mode syntaxes—tree mode and table mode, each with its distinct characteristics as follows: -**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. +**Tree Mode**: 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. -**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. +**Table Mode**: 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. -### 2.1 Model Characteristics +### 2.1 Mode Characteristics -Both model syntaxes have their own applicable scenarios. +Both mode syntaxes have their own applicable scenarios. -The following table compares the tree model and the table model from various dimensions, including applicable scenarios and typical operations. Users can choose the appropriate model based on their specific usage requirements to achieve efficient data storage and management. +The following table compares the tree mode and the table mode from various dimensions, including applicable scenarios and typical operations. Users can choose the appropriate mode based on their specific usage requirements to achieve efficient data storage and management.
DimensionTree ModelTable ModelTree ModeTable Mode
Applicable Scenarios
- - + + @@ -75,22 +75,22 @@ The following table compares the tree model and the table model from various dim **Notes:** -- Both model spaces can coexist within the same cluster instance. Each model follows distinct syntax and database naming conventions, and they remain isolated by default. +- Both mode spaces can coexist within the same cluster instance. Each mode follows distinct syntax and database naming conventions, and they remain isolated by default. -- When establishing a database connection via client tools (Cli) or SDKs, specify the model syntax using the `sql_dialect` parameter (Tree syntax is used by default). +- When establishing a database connection via client tools (Cli) or SDKs, specify the mode syntax using the `sql_dialect` parameter (Tree syntax is used by default). ## 3. Application Scenarios The application scenarios mainly include three categories: -- Scenario 1: Using the tree model for data reading and writing. +- Scenario 1: Using the tree mode for data reading and writing. -- Scenario 2: Using the table model for data reading and writing. +- Scenario 2: Using the table mode for data reading and writing. -- Scenario 3: Sharing the same dataset, using the tree model for data reading and writing, and the table model for data analysis. +- Scenario 3: Sharing the same dataset, using the tree mode for data reading and writing, and the table mode for data analysis. -### 3.1 Scenario 1: Tree Model +### 3.1 Scenario 1: Tree Mode #### 3.1.1 Characteristics @@ -108,9 +108,9 @@ The application scenarios mainly include three categories: | **Time Series (Data Point)** | **Definition**:
A path prefixed with the database path, segmented by `.`, and can contain any number of levels, such as `root.db.turbine.device1.metric1`.
Each time series can have different data types.
**Naming Recommendation**:
Only include unique identifiers (similar to a composite primary key) in the path, generally not exceeding 10 levels.
Typically, place tags with low cardinality (fewer distinct values) at the front to facilitate system compression of common prefixes.
**Quantity Recommendation**:
The total number of time series manageable by the cluster is related to total memory; refer to the resource recommendation section.
There is no limit to the number of child nodes at any level.
**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`.
**Creation Method**: Cannot create a device alone; it exists as time series are created. | -#### 3.1.3 Modeling Examples +#### 3.1.3 Mode Examples -##### 3.1.3.1 How to model when managing multiple types of devices? +##### 3.1.3.1 How to mode when managing multiple types of devices? - If different types of devices in the scenario have different hierarchical paths and data point sets, create branches under the database node by device type. Each device type can have a different data point structure. @@ -118,7 +118,7 @@ The application scenarios mainly include three categories: -##### 3.1.3.2 How to model when there are no devices, only data points? +##### 3.1.3.2 How to mode when there are no devices, only data points? - For example, in a monitoring system for a station, each data point has a unique number but does not correspond to any specific device. @@ -126,20 +126,20 @@ The application scenarios mainly include three categories: -##### 3.1.3.3 How to model when a device has both sub-devices and data points? +##### 3.1.3.3 How to mode when a device has both sub-devices and data points? -- For example, in an energy storage scenario, each layer of the structure monitors its voltage and current. The following modeling approach can be used. +- For example, in an energy storage scenario, each layer of the structure monitors its voltage and current. The following mode approach can be used.
-### 3.2 Scenario 2: Table Model +### 3.2 Scenario 2: Table Mode #### 3.2.1 Characteristics -- Models and manages device time series data using time series tables, facilitating analysis with standard SQL. +- Modes and manages device time series data using time series tables, facilitating analysis with standard SQL. - Suitable for device data analysis or migrating data from other databases to IoTDB. @@ -158,9 +158,9 @@ The application scenarios mainly include three categories: **Data Filtering Efficiency**: Time Column = Tag Column > Attribute Column > Data Point Column. -#### 3.2.3 Modeling Examples +#### 3.2.3 Mode Examples -##### 3.2.3.1 How to model when managing multiple types of devices? +##### 3.2.3.1 How to mode when managing multiple types of devices? - Recommended to create a table for each type of device, with each table having different tags and data point sets. @@ -170,7 +170,7 @@ The application scenarios mainly include three categories: -##### 3.2.3.2 How to model when there are no device identifier columns or attribute columns? +##### 3.2.3.2 How to mode when there are no device identifier columns or attribute columns? - There is no limit to the number of columns; it can reach hundreds of thousands. @@ -178,7 +178,7 @@ The application scenarios mainly include three categories: -##### 3.2.3.3 How to model when a device has both sub-devices and data points? +##### 3.2.3.3 How to mode when a device has both sub-devices and data points? - Each device has multiple sub-devices and data point information. It is recommended to create a table for each type of device for management. @@ -186,23 +186,23 @@ The application scenarios mainly include three categories: -### 3.3 Scenario 3: Dual-Model Integration +### 3.3 Scenario 3: Dual-Mode Integration #### 3.3.1 Characteristics -- Ingeniously combines the advantages of the tree model and table model, sharing the same dataset, with flexible writing and rich querying. +- Ingeniously combines the advantages of the tree mode and table mode, sharing the same dataset, with flexible writing and rich querying. -- During the data writing phase, the tree model syntax is used, supporting flexible data access and expansion. +- During the data writing phase, the tree mode syntax is used, supporting flexible data access and expansion. -- During the data analysis phase, the table model syntax is used, allowing users to perform complex data analysis using standard SQL queries. +- During the data analysis phase, the table mode syntax is used, allowing users to perform complex data analysis using standard SQL queries. -#### 3.3.2 Modeling Examples +#### 3.3.2 Mode Examples -##### 3.3.2.1 How to model when managing multiple types of devices? +##### 3.3.2.1 How to mode when managing multiple types of devices? - Different types of devices in the scenario have different hierarchical paths and data point sets. -- **Tree Model**T: Create branches under the database node by device type, with each device type having a different data point structure. +- **Tree Mode**T: Create branches under the database node by device type, with each device type having a different data point structure. - **Table View**T: Create a table view for each type of device, with each table view having different tags and data point sets. @@ -210,18 +210,18 @@ The application scenarios mainly include three categories: -##### 3.3.2.2 How to model when there are no device identifier columns or attribute columns? +##### 3.3.2.2 How to mode when there are no device identifier columns or attribute columns? -- **Tree Model**: Each data point has a unique number but does not correspond to any specific device. +- **Tree Mode**: Each data point has a unique number but does not correspond to any specific device. - **Table View**: Place all data points into a single table. There is no limit to the number of data point columns; it can reach hundreds of thousands. If data points have the same data type, they can be treated as the same type of device.
-##### 3.3.2.3 How to model when a device has both sub-devices and data points? +##### 3.3.2.3 How to mode when a device has both sub-devices and data points? -- **Tree Model**: Model each layer of the structure according to the monitoring points in the physical world. +- **Tree Mode**: Mode each layer of the structure according to the monitoring points in the physical world. - **Table View**: Create multiple tables to manage each layer of structural information according to device classification.
diff --git a/src/UserGuide/Master/Tree/API/Programming-Go-Native-API.md b/src/UserGuide/Master/Tree/API/Programming-Go-Native-API.md index a4afa6c4f..9004e9417 100644 --- a/src/UserGuide/Master/Tree/API/Programming-Go-Native-API.md +++ b/src/UserGuide/Master/Tree/API/Programming-Go-Native-API.md @@ -409,8 +409,8 @@ func checkError(status *common.TSStatus, err error) { | `Host` | `string` | Choose one with `NodeUrls` | Single-node host address. | | `Port` | `string` | Choose one with `NodeUrls` | Single-node port. | | `NodeUrls` | `[]string` | Choose one with `Host`/`Port` | Cluster node address list, format: `"host:port"`. | -| `UserName` | `string` | Yes | Username. | +| `UserName` | `string` | Yes | Username. | | `Password` | `string` | Yes | Password. | | `FetchSize` | `int32` | No | Query result set fetch size, default 1024. | | `TimeZone` | `string` | No | Session time zone, e.g., "Asia/Shanghai". Default uses server time zone. | -| `Database` | `string` | No | For table model; used to set the session's default database. | +| `Database` | `string` | No | For table mode; used to set the session's default database. | 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 9e9946b5b..bc1db965d 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 @@ -21,35 +21,35 @@ # Modeling Scheme Design -This section introduces how to transform time series data application scenarios into IoTDB time series modeling. +This section introduces how to transform time series data application scenarios into IoTDB time series mode. -## 1. Time Series Data Model +## 1. Time Series Data Mode -Before designing an IoTDB data model, it's essential to understand time series data and its underlying structure. For more details, refer to: [Time Series Data Model](../Background-knowledge/Navigating_Time_Series_Data.md) +Before designing an IoTDB data mode, it's essential to understand time series data and its underlying structure. For more details, refer to: [Time Series Data Mode](../Background-knowledge/Navigating_Time_Series_Data.md) -## 2. Two Time Series Model in IoTDB +## 2. Two Time Series Mode in IoTDB -IoTDB offers two data modeling syntaxes—tree model and table model, each with its distinct characteristics as follows: +IoTDB offers two data mode syntaxes—tree mode and table mode, each with its distinct characteristics as follows: -**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. +**Tree Mode**: 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. -> 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. +> 1. When performing data mode, 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 mode [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. +**Table Mode**: 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. -### 2.1 Model Characteristics +### 2.1 Mode Characteristics -Both model syntaxes have their own applicable scenarios. +Both mode syntaxes have their own applicable scenarios. -The following table compares the tree model and the table model from various dimensions, including applicable scenarios and typical operations. Users can choose the appropriate model based on their specific usage requirements to achieve efficient data storage and management. +The following table compares the tree mode and the table mode from various dimensions, including applicable scenarios and typical operations. Users can choose the appropriate mode based on their specific usage requirements to achieve efficient data storage and management.
DimensionTree ModelTable ModelTree ModeTable Mode
Applicable Scenarios
- - + + @@ -79,20 +79,20 @@ The following table compares the tree model and the table model from various dim **Notes:** -- Both model spaces can coexist within the same cluster instance. Each model follows distinct syntax and database naming conventions, and they remain isolated by default. +- Both mode spaces can coexist within the same cluster instance. Each mode follows distinct syntax and database naming conventions, and they remain isolated by default. -- When establishing a database connection via client tools (Cli) or SDKs, specify the model syntax using the `sql_dialect` parameter (Tree syntax is used by default). +- When establishing a database connection via client tools (Cli) or SDKs, specify the mode syntax using the `sql_dialect` parameter (Tree syntax is used by default). ## 3. Application Scenarios The application scenarios mainly include two categories: -- Scenario 1: Using the tree model for data reading and writing. +- Scenario 1: Using the tree mode for data reading and writing. -- Scenario 2: Using the table model for data reading and writing. +- Scenario 2: Using the table mode for data reading and writing. -### 3.1 Scenario 1: Tree Model +### 3.1 Scenario 1: Tree Mode #### 3.1.1 Characteristics @@ -111,9 +111,9 @@ The application scenarios mainly include two categories: | **Device** | **Definition**: The second-to-last level is the device, such as `device1` in `root.db.turbine.device1.metric1`.
**Creation Method**: Cannot create a device alone; it exists as time series are created. | -#### 3.1.3 Modeling Examples +#### 3.1.3 Mode Examples -##### 3.1.3.1 How to model when managing multiple types of devices? +##### 3.1.3.1 How to mode when managing multiple types of devices? - If different types of devices in the scenario have different hierarchical paths and data point sets, create branches under the database node by device type. Each device type can have a different data point structure. @@ -121,7 +121,7 @@ The application scenarios mainly include two categories: -##### 3.1.3.2 How to model when there are no devices, only data points? +##### 3.1.3.2 How to when there are no devices, only data points? - For example, in a monitoring system for a station, each data point has a unique number but does not correspond to any specific device. @@ -129,20 +129,20 @@ The application scenarios mainly include two categories: -##### 3.1.3.3 How to model when a device has both sub-devices and data points? +##### 3.1.3.3 How to mode when a device has both sub-devices and data points? -- For example, in an energy storage scenario, each layer of the structure monitors its voltage and current. The following modeling approach can be used. +- For example, in an energy storage scenario, each layer of the structure monitors its voltage and current. The following mode approach can be used.
-### 3.2 Scenario 2: Table Model +### 3.2 Scenario 2: Table Mode #### 3.2.1 Characteristics -- Models and manages device time series data using time series tables, facilitating analysis with standard SQL. +- Modes and manages device time series data using time series tables, facilitating analysis with standard SQL. - Suitable for device data analysis or migrating data from other databases to IoTDB. @@ -161,9 +161,9 @@ The application scenarios mainly include two categories: **Data Filtering Efficiency**: Time Column = Tag Column > Attribute Column > Data Point Column. -#### 3.2.3 Modeling Examples +#### 3.2.3 Mode Examples -##### 3.2.3.1 How to model when managing multiple types of devices? +##### 3.2.3.1 How to mode when managing multiple types of devices? - Recommended to create a table for each type of device, with each table having different tags and data point sets. @@ -173,7 +173,7 @@ The application scenarios mainly include two categories: -##### 3.2.3.2 How to model when there are no device identifier columns or attribute columns? +##### 3.2.3.2 How to mode when there are no device identifier columns or attribute columns? - There is no limit to the number of columns; it can reach hundreds of thousands. @@ -181,7 +181,7 @@ The application scenarios mainly include two categories: -##### 3.2.3.3 How to model when a device has both sub-devices and data points? +##### 3.2.3.3 How to mode when a device has both sub-devices and data points? - Each device has multiple sub-devices and data point information. It is recommended to create a table for each type of device for management. 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 d8d294aed..9f930f86d 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 @@ -21,35 +21,35 @@ # Modeling Scheme Design -This section introduces how to transform time series data application scenarios into IoTDB time series modeling. +This section introduces how to transform time series data application scenarios into IoTDB time series mode. -## 1. Time Series Data Model +## 1. Time Series Data Mode -Before designing an IoTDB data model, it's essential to understand time series data and its underlying structure. For more details, refer to: [Time Series Data Model](../Background-knowledge/Navigating_Time_Series_Data.md) +Before designing an IoTDB data mode, it's essential to understand time series data and its underlying structure. For more details, refer to: [Time Series Data Mode](../Background-knowledge/Navigating_Time_Series_Data.md) -## 2. Two Time Series Model in IoTDB +## 2. Two Time Series Mode in IoTDB -IoTDB offers two data modeling syntaxes—tree model and table model, each with its distinct characteristics as follows: +IoTDB offers two data mode syntaxes—tree mode and table mode, each with its distinct characteristics as follows: -**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. +**Tree Mode**: 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. -> 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. +> 1. When performing data mode, 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. +> 2. When constructing tree mode [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. +**Table Mode**: 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. -### 2.1 Model Characteristics +### 2.1 Mode Characteristics -Both model syntaxes have their own applicable scenarios. +Both mode syntaxes have their own applicable scenarios. -The following table compares the tree model and the table model from various dimensions, including applicable scenarios and typical operations. Users can choose the appropriate model based on their specific usage requirements to achieve efficient data storage and management. +The following table compares the tree mode and the table mode from various dimensions, including applicable scenarios and typical operations. Users can choose the appropriate mode based on their specific usage requirements to achieve efficient data storage and management.
DimensionTree ModelTable ModelTree ModeTable Mode
Applicable Scenarios
- - + + @@ -79,22 +79,22 @@ The following table compares the tree model and the table model from various dim **Notes:** -- Both model spaces can coexist within the same cluster instance. Each model follows distinct syntax and database naming conventions, and they remain isolated by default. +- Both mode spaces can coexist within the same cluster instance. Each mode follows distinct syntax and database naming conventions, and they remain isolated by default. -- When establishing a database connection via client tools (Cli) or SDKs, specify the model syntax using the `sql_dialect` parameter (Tree syntax is used by default). +- When establishing a database connection via client tools (Cli) or SDKs, specify the mode syntax using the `sql_dialect` parameter (Tree syntax is used by default). ## 3. Application Scenarios The application scenarios mainly include three categories: -- Scenario 1: Using the tree model for data reading and writing. +- Scenario 1: Using the tree mode for data reading and writing. -- Scenario 2: Using the table model for data reading and writing. +- Scenario 2: Using the table mode for data reading and writing. -- Scenario 3: Sharing the same dataset, using the tree model for data reading and writing, and the table model for data analysis. +- Scenario 3: Sharing the same dataset, using the tree mode for data reading and writing, and the table mode for data analysis. -### 3.1 Scenario 1: Tree Model +### 3.1 Scenario 1: Tree Mode #### 3.1.1 Characteristics @@ -112,10 +112,9 @@ The application scenarios mainly include three categories: | **Time Series (Data Point)** | **Definition**:
A path prefixed with the database path, segmented by `.`, and can contain any number of levels, such as `root.db.turbine.device1.metric1`.
Each time series can have different data types.
**Naming Recommendation**:
Only include unique identifiers (similar to a composite primary key) in the path, generally not exceeding 10 levels.
Typically, place tags with low cardinality (fewer distinct values) at the front to facilitate system compression of common prefixes.
**Quantity Recommendation**:
The total number of time series manageable by the cluster is related to total memory; refer to the resource recommendation section.
There is no limit to the number of child nodes at any level.
**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`.
**Creation Method**: Cannot create a device alone; it exists as time series are created. | +#### 3.1.3 Mode Examples -#### 3.1.3 Modeling Examples - -##### 3.1.3.1 How to model when managing multiple types of devices? +##### 3.1.3.1 How to mode when managing multiple types of devices? - If different types of devices in the scenario have different hierarchical paths and data point sets, create branches under the database node by device type. Each device type can have a different data point structure. @@ -123,7 +122,7 @@ The application scenarios mainly include three categories: -##### 3.1.3.2 How to model when there are no devices, only data points? +##### 3.1.3.2 How to mode when there are no devices, only data points? - For example, in a monitoring system for a station, each data point has a unique number but does not correspond to any specific device. @@ -131,20 +130,20 @@ The application scenarios mainly include three categories: -##### 3.1.3.3 How to model when a device has both sub-devices and data points? +##### 3.1.3.3 How to mode when a device has both sub-devices and data points? -- For example, in an energy storage scenario, each layer of the structure monitors its voltage and current. The following modeling approach can be used. +- For example, in an energy storage scenario, each layer of the structure monitors its voltage and current. The following mode approach can be used.
-### 3.2 Scenario 2: Table Model +### 3.2 Scenario 2: Table Mode #### 3.2.1 Characteristics -- Models and manages device time series data using time series tables, facilitating analysis with standard SQL. +- Modes and manages device time series data using time series tables, facilitating analysis with standard SQL. - Suitable for device data analysis or migrating data from other databases to IoTDB. @@ -163,9 +162,9 @@ The application scenarios mainly include three categories: **Data Filtering Efficiency**: Time Column = Tag Column > Attribute Column > Data Point Column. -#### 3.2.3 Modeling Examples +#### 3.2.3 Mode Examples -##### 3.2.3.1 How to model when managing multiple types of devices? +##### 3.2.3.1 How to mode when managing multiple types of devices? - Recommended to create a table for each type of device, with each table having different tags and data point sets. @@ -175,7 +174,7 @@ The application scenarios mainly include three categories: -##### 3.2.3.2 How to model when there are no device identifier columns or attribute columns? +##### 3.2.3.2 How to mode when there are no device identifier columns or attribute columns? - There is no limit to the number of columns; it can reach hundreds of thousands. @@ -183,7 +182,7 @@ The application scenarios mainly include three categories: -##### 3.2.3.3 How to model when a device has both sub-devices and data points? +##### 3.2.3.3 How to mode when a device has both sub-devices and data points? - Each device has multiple sub-devices and data point information. It is recommended to create a table for each type of device for management. @@ -191,23 +190,23 @@ The application scenarios mainly include three categories: -### 3.3 Scenario 3: Dual-Model Integration +### 3.3 Scenario 3: Dual-Mode Integration #### 3.3.1 Characteristics -- Ingeniously combines the advantages of the tree model and table model, sharing the same dataset, with flexible writing and rich querying. +- Ingeniously combines the advantages of the tree mode and table mode, sharing the same dataset, with flexible writing and rich querying. -- During the data writing phase, the tree model syntax is used, supporting flexible data access and expansion. +- During the data writing phase, the tree mode syntax is used, supporting flexible data access and expansion. -- During the data analysis phase, the table model syntax is used, allowing users to perform complex data analysis using standard SQL queries. +- During the data analysis phase, the table mode syntax is used, allowing users to perform complex data analysis using standard SQL queries. -#### 3.3.2 Modeling Examples +#### 3.3.2 Mode Examples -##### 3.3.2.1 How to model when managing multiple types of devices? +##### 3.3.2.1 How to mode when managing multiple types of devices? - Different types of devices in the scenario have different hierarchical paths and data point sets. -- **Tree Model**T: Create branches under the database node by device type, with each device type having a different data point structure. +- **Tree Mode**T: Create branches under the database node by device type, with each device type having a different data point structure. - **Table View**T: Create a table view for each type of device, with each table view having different tags and data point sets. @@ -215,18 +214,18 @@ The application scenarios mainly include three categories: -##### 3.3.2.2 How to model when there are no device identifier columns or attribute columns? +##### 3.3.2.2 How to mode when there are no device identifier columns or attribute columns? -- **Tree Model**: Each data point has a unique number but does not correspond to any specific device. +- **Tree Mode**: Each data point has a unique number but does not correspond to any specific device. - **Table View**: Place all data points into a single table. There is no limit to the number of data point columns; it can reach hundreds of thousands. If data points have the same data type, they can be treated as the same type of device.
-##### 3.3.2.3 How to model when a device has both sub-devices and data points? +##### 3.3.2.3 How to mode when a device has both sub-devices and data points? -- **Tree Model**: Model each layer of the structure according to the monitoring points in the physical world. +- **Tree Mode**: Mode each layer of the structure according to the monitoring points in the physical world. - **Table View**: Create multiple tables to manage each layer of structural information according to device classification.
diff --git a/src/UserGuide/latest-Table/API/Programming-JDBC_apache.md b/src/UserGuide/latest-Table/API/Programming-JDBC_apache.md index c19725a8d..1cc0c170d 100644 --- a/src/UserGuide/latest-Table/API/Programming-JDBC_apache.md +++ b/src/UserGuide/latest-Table/API/Programming-JDBC_apache.md @@ -66,7 +66,7 @@ Add the following dependency to your Maven `pom.xml` file: ## 3. Sample Code -**Note:** When using the Table Model, you must specify the `sql_dialect` parameter as `table` in the URL. Example: +**Note:** When using the Table Mode, you must specify the `sql_dialect` parameter as `table` in the URL. Example: ```Java String url = "jdbc:iotdb://127.0.0.1:6667?sql_dialect=table"; diff --git a/src/UserGuide/latest-Table/API/Programming-JDBC_timecho.md b/src/UserGuide/latest-Table/API/Programming-JDBC_timecho.md index 5ef239cc9..e2ae883de 100644 --- a/src/UserGuide/latest-Table/API/Programming-JDBC_timecho.md +++ b/src/UserGuide/latest-Table/API/Programming-JDBC_timecho.md @@ -66,7 +66,7 @@ Add the following dependency to your Maven `pom.xml` file: ## 3. Sample Code -**Note:** When using the Table Model, you must specify the `sql_dialect` parameter as `table` in the URL. Example: +**Note:** When using the Table Mode, you must specify the `sql_dialect` parameter as `table` in the URL. Example: ```Java String url = "jdbc:iotdb://127.0.0.1:6667?sql_dialect=table"; diff --git a/src/UserGuide/latest-Table/API/Programming-MQTT.md b/src/UserGuide/latest-Table/API/Programming-MQTT.md index 239159ab9..c7e4e438c 100644 --- a/src/UserGuide/latest-Table/API/Programming-MQTT.md +++ b/src/UserGuide/latest-Table/API/Programming-MQTT.md @@ -33,14 +33,14 @@ IoTDB provides deep integration with the MQTT protocol, fully compliant with MQT By default, the IoTDB MQTT service loads configurations from `${IOTDB_HOME}/${IOTDB_CONF}/iotdb-system.properties`. -| **Property** | **Description** | **Default** | -| ------------------------ | ---------------------------------------------------------------------------------------------------------------------- | ------------------- | -| `enable_mqtt_service` | Enable/ disable the MQTT service. | FALSE | -| `mqtt_host` | Host address bound to the MQTT service. | 127.0.0.1 | -| `mqtt_port` | Port bound to the MQTT service. | 1883 | -| `mqtt_handler_pool_size` | Thread pool size for processing MQTT messages. | 1 | -| **`mqtt_payload_formatter`** | **Formatting method for MQTT message payloads. ​**​**Options: `json` (tree model), `line` (table model).** | **json** | -| `mqtt_max_message_size` | Maximum allowed MQTT message size (bytes). | 1048576 | +| **Property** | **Description** | **Default** | +| ------------------------ | -------------------------------------------------------------------------------------------------------------------- | ------------------- | +| `enable_mqtt_service` | Enable/ disable the MQTT service. | FALSE | +| `mqtt_host` | Host address bound to the MQTT service. | 127.0.0.1 | +| `mqtt_port` | Port bound to the MQTT service. | 1883 | +| `mqtt_handler_pool_size` | Thread pool size for processing MQTT messages. | 1 | +| **`mqtt_payload_formatter`** | **Formatting method for MQTT message payloads. ​**​**Options: `json` (tree mode), `line` (table mode).** | **json** | +| `mqtt_max_message_size` | Maximum allowed MQTT message size (bytes). | 1048576 | ## 3. Write Protocol diff --git a/src/UserGuide/latest-Table/Background-knowledge/Cluster-Concept_apache.md b/src/UserGuide/latest-Table/Background-knowledge/Cluster-Concept_apache.md index 931a75b3d..8d4b99869 100644 --- a/src/UserGuide/latest-Table/Background-knowledge/Cluster-Concept_apache.md +++ b/src/UserGuide/latest-Table/Background-knowledge/Cluster-Concept_apache.md @@ -25,12 +25,12 @@ ### 1.1 sql_dialect -IoTDB supports two time-series data models (SQL dialects), both managing devices and measurement points: +IoTDB supports two time-series data mode (SQL dialects), both managing devices and measurement points: -- **Tree** **Model**: Organizes data in a hierarchical path structure, where each path represents a measurement point of a device. -- **Table** **Model**: Organizes data in a relational table format, where each table corresponds to a type of device. +- **Tree** **Mode**: Organizes data in a hierarchical path structure, where each path represents a measurement point of a device. +- **Table** **Mode**: Organizes data in a relational table format, where each table corresponds to a type of device. -Each dialect comes with its own SQL syntax and query patterns tailored to its data model. +Each dialect comes with its own SQL syntax and query patterns tailored to its data mode. ### 1.2 Schema @@ -73,7 +73,7 @@ An IoTDB cluster consists of three types of nodes, each with distinct responsibi - **ConfigNode (Management Node)** Manages cluster metadata, configuration, user permissions, schema, and partitioning. It also handles distributed scheduling and load balancing. All ConfigNodes are replicated for high availability. - **DataNode (Storage and Computation Node)** Handles client requests, stores data, and executes computations. -- **AINode (Analytics Node)** Provides machine learning capabilities, allowing users to register pre-trained models and perform inference via SQL. It includes built-in time-series models and common ML algorithms for tasks like prediction and anomaly detection. +- **AINode (Analytics Node)** Provides machine learning capabilities, allowing users to register pre-trained models and perform inference via SQL. It includes built-in time-series mode and common ML algorithms for tasks like prediction and anomaly detection. ### 2.3 Data Partitioning diff --git a/src/UserGuide/latest-Table/Background-knowledge/Cluster-Concept_timecho.md b/src/UserGuide/latest-Table/Background-knowledge/Cluster-Concept_timecho.md index 236489032..651a353cd 100644 --- a/src/UserGuide/latest-Table/Background-knowledge/Cluster-Concept_timecho.md +++ b/src/UserGuide/latest-Table/Background-knowledge/Cluster-Concept_timecho.md @@ -25,12 +25,12 @@ ### 1.1 sql_dialect -IoTDB supports two time-series data models (SQL dialects), both managing devices and measurement points: +IoTDB supports two time-series data mode (SQL dialects), both managing devices and measurement points: -- **Tree** **Model**: Organizes data in a hierarchical path structure, where each path represents a measurement point of a device. -- **Table** **Model**: Organizes data in a relational table format, where each table corresponds to a type of device. +- **Tree** **Mode**: Organizes data in a hierarchical path structure, where each path represents a measurement point of a device. +- **Table** **Mode**: Organizes data in a relational table format, where each table corresponds to a type of device. -Each dialect comes with its own SQL syntax and query patterns tailored to its data model. +Each dialect comes with its own SQL syntax and query patterns tailored to its data mode. ### 1.2 Schema @@ -74,7 +74,7 @@ An IoTDB cluster consists of three types of nodes, each with distinct responsibi - **ConfigNode (Management Node)** Manages cluster metadata, configuration, user permissions, schema, and partitioning. It also handles distributed scheduling and load balancing. All ConfigNodes are replicated for high availability. - **DataNode (Storage and Computation Node)** Handles client requests, stores data, and executes computations. -- **AINode (Analytics Node)** Provides machine learning capabilities, allowing users to register pre-trained models and perform inference via SQL. It includes built-in time-series models and common ML algorithms for tasks like prediction and anomaly detection. +- **AINode (Analytics Node)** Provides machine learning capabilities, allowing users to register pre-trained models and perform inference via SQL. It includes built-in time-series modes and common ML algorithms for tasks like prediction and anomaly detection. ### 2.3 Data Partitioning diff --git a/src/UserGuide/latest-Table/Background-knowledge/Data-Model-and-Terminology_apache.md b/src/UserGuide/latest-Table/Background-knowledge/Data-Model-and-Terminology_apache.md index c6d7e9739..f044ecd7f 100644 --- a/src/UserGuide/latest-Table/Background-knowledge/Data-Model-and-Terminology_apache.md +++ b/src/UserGuide/latest-Table/Background-knowledge/Data-Model-and-Terminology_apache.md @@ -21,31 +21,31 @@ # Modeling Scheme Design -This section introduces how to transform time series data application scenarios into IoTDB time series modeling. +This section introduces how to transform time series data application scenarios into IoTDB time series mode. -## 1. Time Series Data Model +## 1. Time Series Data Mode -Before designing an IoTDB data model, it's essential to understand time series data and its underlying structure. For more details, refer to: [Time Series Data Model](../Background-knowledge/Navigating_Time_Series_Data.md) +Before designing an IoTDB data mode, it's essential to understand time series data and its underlying structure. For more details, refer to: [Time Series Data Mode](../Background-knowledge/Navigating_Time_Series_Data.md) -## 2. Two Time Series Model in IoTDB +## 2. Two Time Series Mode in IoTDB -IoTDB offers two data modeling syntaxes—tree model and table model, each with its distinct characteristics as follows: +IoTDB offers two data mode syntaxes—tree mode and table mode, each with its distinct characteristics as follows: -**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. +**Tree Mode**: 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. -**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. +**Table Mode**: 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. -### 2.1 Model Characteristics +### 2.1 Mode Characteristics -Both model syntaxes have their own applicable scenarios. +Both mode syntaxes have their own applicable scenarios. -The following table compares the tree model and the table model from various dimensions, including applicable scenarios and typical operations. Users can choose the appropriate model based on their specific usage requirements to achieve efficient data storage and management. +The following table compares the tree mode and the table mode from various dimensions, including applicable scenarios and typical operations. Users can choose the appropriate mode based on their specific usage requirements to achieve efficient data storage and management.
DimensionTree ModelTable ModelTree ModeTable Mode
Applicable Scenarios
- - + + @@ -75,20 +75,20 @@ The following table compares the tree model and the table model from various dim **Notes:** -- Both model spaces can coexist within the same cluster instance. Each model follows distinct syntax and database naming conventions, and they remain isolated by default. +- Both mode spaces can coexist within the same cluster instance. Each mode follows distinct syntax and database naming conventions, and they remain isolated by default. -- When establishing a database connection via client tools (Cli) or SDKs, specify the model syntax using the `sql_dialect` parameter (Tree syntax is used by default). +- When establishing a database connection via client tools (Cli) or SDKs, specify the mode syntax using the `sql_dialect` parameter (Tree syntax is used by default). ## 3. Application Scenarios The application scenarios mainly include two categories: -- Scenario 1: Using the tree model for data reading and writing. +- Scenario 1: Using the tree mode for data reading and writing. -- Scenario 2: Using the table model for data reading and writing. +- Scenario 2: Using the table mode for data reading and writing. -### 3.1 Scenario 1: Tree Model +### 3.1 Scenario 1: Tree Mode #### 3.1.1 Characteristics @@ -106,9 +106,9 @@ The application scenarios mainly include two categories: | **Time Series (Data Point)** | **Definition**:
A path prefixed with the database path, segmented by `.`, and can contain any number of levels, such as `root.db.turbine.device1.metric1`.
Each time series can have different data types.
**Naming Recommendation**:
Only include unique identifiers (similar to a composite primary key) in the path, generally not exceeding 10 levels.
Typically, place tags with low cardinality (fewer distinct values) at the front to facilitate system compression of common prefixes.
**Quantity Recommendation**:
The total number of time series manageable by the cluster is related to total memory; refer to the resource recommendation section.
There is no limit to the number of child nodes at any level.
**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`.
**Creation Method**: Cannot create a device alone; it exists as time series are created. | -#### 3.1.3 Modeling Examples +#### 3.1.3 Mode Examples -##### 3.1.3.1 How to model when managing multiple types of devices? +##### 3.1.3.1 How to mode when managing multiple types of devices? - If different types of devices in the scenario have different hierarchical paths and data point sets, create branches under the database node by device type. Each device type can have a different data point structure. @@ -116,7 +116,7 @@ The application scenarios mainly include two categories: -##### 3.1.3.2 How to model when there are no devices, only data points? +##### 3.1.3.2 How to mode when there are no devices, only data points? - For example, in a monitoring system for a station, each data point has a unique number but does not correspond to any specific device. @@ -124,20 +124,20 @@ The application scenarios mainly include two categories: -##### 3.1.3.3 How to model when a device has both sub-devices and data points? +##### 3.1.3.3 How to mode when a device has both sub-devices and data points? -- For example, in an energy storage scenario, each layer of the structure monitors its voltage and current. The following modeling approach can be used. +- For example, in an energy storage scenario, each layer of the structure monitors its voltage and current. The following mode approach can be used.
-### 3.2 Scenario 2: Table Model +### 3.2 Scenario 2: Table Mode #### 3.2.1 Characteristics -- Models and manages device time series data using time series tables, facilitating analysis with standard SQL. +- Modes and manages device time series data using time series tables, facilitating analysis with standard SQL. - Suitable for device data analysis or migrating data from other databases to IoTDB. @@ -156,9 +156,9 @@ The application scenarios mainly include two categories: **Data Filtering Efficiency**: Time Column = Tag Column > Attribute Column > Data Point Column. -#### 3.2.3 Modeling Examples +#### 3.2.3 Mode Examples -##### 3.2.3.1 How to model when managing multiple types of devices? +##### 3.2.3.1 How to mode when managing multiple types of devices? - Recommended to create a table for each type of device, with each table having different tags and data point sets. @@ -168,7 +168,7 @@ The application scenarios mainly include two categories: -##### 3.2.3.2 How to model when there are no device identifier columns or attribute columns? +##### 3.2.3.2 How to mode when there are no device identifier columns or attribute columns? - There is no limit to the number of columns; it can reach hundreds of thousands. @@ -176,7 +176,7 @@ The application scenarios mainly include two categories: -##### 3.2.3.3 How to model when a device has both sub-devices and data points? +##### 3.2.3.3 How to mode when a device has both sub-devices and data points? - Each device has multiple sub-devices and data point information. It is recommended to create a table for each type of device for management. diff --git a/src/UserGuide/latest-Table/Background-knowledge/Data-Model-and-Terminology_timecho.md b/src/UserGuide/latest-Table/Background-knowledge/Data-Model-and-Terminology_timecho.md index df755ac48..9b0cfd84e 100644 --- a/src/UserGuide/latest-Table/Background-knowledge/Data-Model-and-Terminology_timecho.md +++ b/src/UserGuide/latest-Table/Background-knowledge/Data-Model-and-Terminology_timecho.md @@ -21,31 +21,31 @@ # Modeling Scheme Design -This section introduces how to transform time series data application scenarios into IoTDB time series modeling. +This section introduces how to transform time series data application scenarios into IoTDB time series mode. -## 1. Time Series Data Model +## 1. Time Series Data Mode -Before designing an IoTDB data model, it's essential to understand time series data and its underlying structure. For more details, refer to: [Time Series Data Model](../Background-knowledge/Navigating_Time_Series_Data.md) +Before designing an IoTDB data mode, it's essential to understand time series data and its underlying structure. For more details, refer to: [Time Series Data Mode](../Background-knowledge/Navigating_Time_Series_Data.md) -## 2. Two Time Series Model in IoTDB +## 2. Two Time Series Mode in IoTDB -IoTDB offers two data modeling syntaxes—tree model and table model, each with its distinct characteristics as follows: +IoTDB offers two data mode syntaxes—tree mode and table mode, each with its distinct characteristics as follows: -**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. +**Tree Mode**: 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. -**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. +**Table Mode**: 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. -### 2.1 Model Characteristics +### 2.1 Mode Characteristics -Both model syntaxes have their own applicable scenarios. +Both mode syntaxes have their own applicable scenarios. -The following table compares the tree model and the table model from various dimensions, including applicable scenarios and typical operations. Users can choose the appropriate model based on their specific usage requirements to achieve efficient data storage and management. +The following table compares the tree mode and the table mode from various dimensions, including applicable scenarios and typical operations. Users can choose the appropriate mode based on their specific usage requirements to achieve efficient data storage and management.
DimensionTree ModelTable ModelTree ModeTable Mode
Applicable Scenarios
- - + + @@ -75,22 +75,22 @@ The following table compares the tree model and the table model from various dim **Notes:** -- Both model spaces can coexist within the same cluster instance. Each model follows distinct syntax and database naming conventions, and they remain isolated by default. +- Both mode spaces can coexist within the same cluster instance. Each mode follows distinct syntax and database naming conventions, and they remain isolated by default. -- When establishing a database connection via client tools (Cli) or SDKs, specify the model syntax using the `sql_dialect` parameter (Tree syntax is used by default). +- When establishing a database connection via client tools (Cli) or SDKs, specify the mode syntax using the `sql_dialect` parameter (Tree syntax is used by default). ## 3. Application Scenarios The application scenarios mainly include three categories: -- Scenario 1: Using the tree model for data reading and writing. +- Scenario 1: Using the tree mode for data reading and writing. -- Scenario 2: Using the table model for data reading and writing. +- Scenario 2: Using the table mode for data reading and writing. -- Scenario 3: Sharing the same dataset, using the tree model for data reading and writing, and the table model for data analysis. +- Scenario 3: Sharing the same dataset, using the tree mode for data reading and writing, and the table mode for data analysis. -### 3.1 Scenario 1: Tree Model +### 3.1 Scenario 1: Tree Mode #### 3.1.1 Characteristics @@ -108,9 +108,9 @@ The application scenarios mainly include three categories: | **Time Series (Data Point)** | **Definition**:
A path prefixed with the database path, segmented by `.`, and can contain any number of levels, such as `root.db.turbine.device1.metric1`.
Each time series can have different data types.
**Naming Recommendation**:
Only include unique identifiers (similar to a composite primary key) in the path, generally not exceeding 10 levels.
Typically, place tags with low cardinality (fewer distinct values) at the front to facilitate system compression of common prefixes.
**Quantity Recommendation**:
The total number of time series manageable by the cluster is related to total memory; refer to the resource recommendation section.
There is no limit to the number of child nodes at any level.
**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`.
**Creation Method**: Cannot create a device alone; it exists as time series are created. | -#### 3.1.3 Modeling Examples +#### 3.1.3 Mode Examples -##### 3.1.3.1 How to model when managing multiple types of devices? +##### 3.1.3.1 How to mode when managing multiple types of devices? - If different types of devices in the scenario have different hierarchical paths and data point sets, create branches under the database node by device type. Each device type can have a different data point structure. @@ -118,7 +118,7 @@ The application scenarios mainly include three categories: -##### 3.1.3.2 How to model when there are no devices, only data points? +##### 3.1.3.2 How to mode when there are no devices, only data points? - For example, in a monitoring system for a station, each data point has a unique number but does not correspond to any specific device. @@ -126,20 +126,20 @@ The application scenarios mainly include three categories: -##### 3.1.3.3 How to model when a device has both sub-devices and data points? +##### 3.1.3.3 How to mode when a device has both sub-devices and data points? -- For example, in an energy storage scenario, each layer of the structure monitors its voltage and current. The following modeling approach can be used. +- For example, in an energy storage scenario, each layer of the structure monitors its voltage and current. The following mode approach can be used.
-### 3.2 Scenario 2: Table Model +### 3.2 Scenario 2: Table Mode #### 3.2.1 Characteristics -- Models and manages device time series data using time series tables, facilitating analysis with standard SQL. +- Modes and manages device time series data using time series tables, facilitating analysis with standard SQL. - Suitable for device data analysis or migrating data from other databases to IoTDB. @@ -158,9 +158,9 @@ The application scenarios mainly include three categories: **Data Filtering Efficiency**: Time Column = Tag Column > Attribute Column > Data Point Column. -#### 3.2.3 Modeling Examples +#### 3.2.3 Mode Examples -##### 3.2.3.1 How to model when managing multiple types of devices? +##### 3.2.3.1 How to mode when managing multiple types of devices? - Recommended to create a table for each type of device, with each table having different tags and data point sets. @@ -170,7 +170,7 @@ The application scenarios mainly include three categories: -##### 3.2.3.2 How to model when there are no device identifier columns or attribute columns? +##### 3.2.3.2 How to mode when there are no device identifier columns or attribute columns? - There is no limit to the number of columns; it can reach hundreds of thousands. @@ -178,7 +178,7 @@ The application scenarios mainly include three categories: -##### 3.2.3.3 How to model when a device has both sub-devices and data points? +##### 3.2.3.3 How to mode when a device has both sub-devices and data points? - Each device has multiple sub-devices and data point information. It is recommended to create a table for each type of device for management. @@ -186,23 +186,23 @@ The application scenarios mainly include three categories: -### 3.3 Scenario 3: Dual-Model Integration +### 3.3 Scenario 3: Dual-Mode Integration #### 3.3.1 Characteristics -- Ingeniously combines the advantages of the tree model and table model, sharing the same dataset, with flexible writing and rich querying. +- Ingeniously combines the advantages of the tree mode and table mode, sharing the same dataset, with flexible writing and rich querying. -- During the data writing phase, the tree model syntax is used, supporting flexible data access and expansion. +- During the data writing phase, the tree mode syntax is used, supporting flexible data access and expansion. -- During the data analysis phase, the table model syntax is used, allowing users to perform complex data analysis using standard SQL queries. +- During the data analysis phase, the table mode syntax is used, allowing users to perform complex data analysis using standard SQL queries. -#### 3.3.2 Modeling Examples +#### 3.3.2 Mode Examples -##### 3.3.2.1 How to model when managing multiple types of devices? +##### 3.3.2.1 How to mode when managing multiple types of devices? - Different types of devices in the scenario have different hierarchical paths and data point sets. -- **Tree Model**T: Create branches under the database node by device type, with each device type having a different data point structure. +- **Tree Mode**T: Create branches under the database node by device type, with each device type having a different data point structure. - **Table View**T: Create a table view for each type of device, with each table view having different tags and data point sets. @@ -210,18 +210,18 @@ The application scenarios mainly include three categories: -##### 3.3.2.2 How to model when there are no device identifier columns or attribute columns? +##### 3.3.2.2 How to mode when there are no device identifier columns or attribute columns? -- **Tree Model**: Each data point has a unique number but does not correspond to any specific device. +- **Tree Mode**: Each data point has a unique number but does not correspond to any specific device. - **Table View**: Place all data points into a single table. There is no limit to the number of data point columns; it can reach hundreds of thousands. If data points have the same data type, they can be treated as the same type of device.
-##### 3.3.2.3 How to model when a device has both sub-devices and data points? +##### 3.3.2.3 How to mode when a device has both sub-devices and data points? -- **Tree Model**: Model each layer of the structure according to the monitoring points in the physical world. +- **Tree Mode**: Mode each layer of the structure according to the monitoring points in the physical world. - **Table View**: Create multiple tables to manage each layer of structural information according to device classification.
diff --git a/src/UserGuide/latest-Table/Ecosystem-Integration/DBeaver.md b/src/UserGuide/latest-Table/Ecosystem-Integration/DBeaver.md index 0661f61f2..75f965607 100644 --- a/src/UserGuide/latest-Table/Ecosystem-Integration/DBeaver.md +++ b/src/UserGuide/latest-Table/Ecosystem-Integration/DBeaver.md @@ -45,7 +45,7 @@ Ensure DBeaver and IoTDB are installed: ![](/img/dbeaver-2520-3-en.png) -3. Complete the connection settings, and choose the appropriate sql dialect based on whether the target IoTDB uses a ​​Tree Model​​ or ​​Table Model​​. +3. Complete the connection settings, and choose the appropriate sql dialect based on whether the target IoTDB uses a ​​Tree Mode​​ or ​​Table Mode​​. ![](/img/dbeaver-2520-4-en.png) diff --git a/src/UserGuide/latest-Table/IoTDB-Introduction/Release-history_apache.md b/src/UserGuide/latest-Table/IoTDB-Introduction/Release-history_apache.md index 2e4f65aff..7d4069b2a 100644 --- a/src/UserGuide/latest-Table/IoTDB-Introduction/Release-history_apache.md +++ b/src/UserGuide/latest-Table/IoTDB-Introduction/Release-history_apache.md @@ -24,7 +24,7 @@ > Release Date: 2026.01.20 -V2.0.6 is the official release of the dual-model (tree and table) architecture. It introduces **query-writeback capability for the table model**, new **bitwise operation functions** (built-in scalar functions), and **push-down-capable time functions**, while delivering comprehensive improvements in database monitoring, performance, and stability. Specific release contents are as follows: +V2.0.6 is the official release of the dual-mode (tree and table) architecture. It introduces **query-writeback capability for the table mode**, new **bitwise operation functions** (built-in scalar functions), and **push-down-capable time functions**, while delivering comprehensive improvements in database monitoring, performance, and stability. Specific release contents are as follows: * **Query Module**: Added support for query-writeback functionality in the table model. * **Query Module**: Enhanced row-pattern recognition in the table model to support aggregate functions, enabling analysis and computation over consecutive data sequences. @@ -37,7 +37,7 @@ V2.0.6 is the official release of the dual-model (tree and table) architecture. > Release Date: 2025.08.21 -V2.0.5, as the official release of the Dual-Model Tree-Table system, primarily introduces the tree-to-table view, window functions for the table model, the aggregate function approx_most_frequent, and supports LEFT & RIGHT JOIN as well as ASOF LEFT JOIN. The AINode now includes two new built-in models, Timer-XL and Timer-Sundial, and supports inference capabilities for both tree and table models. Additionally, this version brings comprehensive improvements to database monitoring, performance, and stability. The specific updates are as follows: +V2.0.5, as the official release of the Dual-Mode Tree-Table system, primarily introduces the tree-to-table view, window functions for the table model, the aggregate function approx_most_frequent, and supports LEFT & RIGHT JOIN as well as ASOF LEFT JOIN. The AINode now includes two new built-in models, Timer-XL and Timer-Sundial, and supports inference capabilities for both tree and table models. Additionally, this version brings comprehensive improvements to database monitoring, performance, and stability. The specific updates are as follows: * **Query Module**: Supports manual creation of tree-to-table views * **Query Module**: Adds window functions for the table model diff --git a/src/UserGuide/latest-Table/Reference/Sample-Data.md b/src/UserGuide/latest-Table/Reference/Sample-Data.md index 8b5b6ef02..872c3fdd7 100644 --- a/src/UserGuide/latest-Table/Reference/Sample-Data.md +++ b/src/UserGuide/latest-Table/Reference/Sample-Data.md @@ -20,7 +20,7 @@ --> # Sample Data -This section introduces a simple time-series data application scenario, along with the modeling and sample data for this scenario. All example SQL statements in the IoTDB Table Model User Guide can be executed using this modeling and sample data. +This section introduces a simple time-series data application scenario, along with the modeling and sample data for this scenario. All example SQL statements in the IoTDB Table Mode User Guide can be executed using this modeling and sample data. ## 1. Data Structure diff --git a/src/UserGuide/latest-Table/SQL-Manual/Basis-Function.md b/src/UserGuide/latest-Table/SQL-Manual/Basis-Function.md index 1cad9d0cc..4fdb3e047 100644 --- a/src/UserGuide/latest-Table/SQL-Manual/Basis-Function.md +++ b/src/UserGuide/latest-Table/SQL-Manual/Basis-Function.md @@ -1737,7 +1737,7 @@ IoTDB> SELECT * FROM HOP(DATA => bid,TIMECOL => 'time',SLIDE => 5m,SIZE => 10m); |2021-01-01T09:15:00.000+08:00|2021-01-01T09:25:00.000+08:00|2021-01-01T09:15:00.000+08:00| TESL|195.0| +-----------------------------+-----------------------------+-----------------------------+--------+-----+ --- Equivalent to tree model's GROUP BY TIME when combined with GROUP BY +-- Equivalent to tree mode's GROUP BY TIME when combined with GROUP BY IoTDB> SELECT window_start, window_end, stock_id, avg(price) as avg FROM HOP(DATA => bid,TIMECOL => 'time',SLIDE => 5m,SIZE => 10m) GROUP BY window_start, window_end, stock_id; +-----------------------------+-----------------------------+--------+------------------+ | window_start| window_end|stock_id| avg| @@ -1793,7 +1793,7 @@ IoTDB> SELECT * FROM SESSION(DATA => bid PARTITION BY stock_id ORDER BY time,TIM |2021-01-01T09:05:00.000+08:00|2021-01-01T09:09:00.000+08:00|2021-01-01T09:09:00.000+08:00| AAPL|102.0| +-----------------------------+-----------------------------+-----------------------------+--------+-----+ --- Equivalent to tree model's GROUP BY SESSION when combined with GROUP BY +-- Equivalent to tree mode's GROUP BY SESSION when combined with GROUP BY IoTDB> SELECT window_start, window_end, stock_id, avg(price) as avg FROM SESSION(DATA => bid PARTITION BY stock_id ORDER BY time,TIMECOL => 'time',GAP => 2m) GROUP BY window_start, window_end, stock_id; +-----------------------------+-----------------------------+--------+------------------+ | window_start| window_end|stock_id| avg| @@ -1846,7 +1846,7 @@ IoTDB> SELECT * FROM VARIATION(DATA => bid PARTITION BY stock_id ORDER BY time,C | 1|2021-01-01T09:09:00.000+08:00| AAPL|102.0| +------------+-----------------------------+--------+-----+ --- Equivalent to tree model's GROUP BY VARIATION when combined with GROUP BY +-- Equivalent to tree mode's GROUP BY VARIATION when combined with GROUP BY IoTDB> SELECT first(time) as window_start, last(time) as window_end, stock_id, avg(price) as avg FROM VARIATION(DATA => bid PARTITION BY stock_id ORDER BY time,COL => 'price', DELTA => 2.0) GROUP BY window_index, stock_id; +-----------------------------+-----------------------------+--------+-----+ | window_start| window_end|stock_id| avg| @@ -1899,7 +1899,7 @@ IoTDB> SELECT * FROM CAPACITY(DATA => bid PARTITION BY stock_id ORDER BY time, S | 1|2021-01-01T09:09:00.000+08:00| AAPL|102.0| +------------+-----------------------------+--------+-----+ --- Equivalent to tree model's GROUP BY COUNT when combined with GROUP BY +-- Equivalent to tree mode's GROUP BY COUNT when combined with GROUP BY IoTDB> SELECT first(time) as start_time, last(time) as end_time, stock_id, avg(price) as avg FROM CAPACITY(DATA => bid PARTITION BY stock_id ORDER BY time, SIZE => 2) GROUP BY window_index, stock_id; +-----------------------------+-----------------------------+--------+-----+ | start_time| end_time|stock_id| avg| @@ -1954,7 +1954,7 @@ IoTDB> SELECT * FROM TUMBLE( DATA => bid, TIMECOL => 'time', SIZE => 10m); |2021-01-01T09:00:00.000+08:00|2021-01-01T09:10:00.000+08:00|2021-01-01T09:09:00.000+08:00| AAPL|102.0| +-----------------------------+-----------------------------+-----------------------------+--------+-----+ --- Equivalent to tree model's GROUP BY TIME when combined with GROUP BY +-- Equivalent to tree mode's GROUP BY TIME when combined with GROUP BY IoTDB> SELECT window_start, window_end, stock_id, avg(price) as avg FROM TUMBLE(DATA => bid, TIMECOL => 'time', SIZE => 10m) GROUP BY window_start, window_end, stock_id; +-----------------------------+-----------------------------+--------+------------------+ | window_start| window_end|stock_id| avg| @@ -2019,7 +2019,7 @@ IoTDB> SELECT * FROM CUMULATE(DATA => bid,TIMECOL => 'time',STEP => 2m,SIZE => 1 |2021-01-01T09:00:00.000+08:00|2021-01-01T09:10:00.000+08:00|2021-01-01T09:09:00.000+08:00| AAPL|102.0| +-----------------------------+-----------------------------+-----------------------------+--------+-----+ --- Equivalent to tree model's GROUP BY TIME when combined with GROUP BY +-- Equivalent to tree mode's GROUP BY TIME when combined with GROUP BY IoTDB> SELECT window_start, window_end, stock_id, avg(price) as avg FROM CUMULATE(DATA => bid,TIMECOL => 'time',STEP => 2m, SIZE => 10m) GROUP BY window_start, window_end, stock_id; +-----------------------------+-----------------------------+--------+------------------+ | window_start| window_end|stock_id| avg| diff --git a/src/UserGuide/latest-Table/SQL-Manual/From-Join-Clause.md b/src/UserGuide/latest-Table/SQL-Manual/From-Join-Clause.md index ceaa9d70e..bc24942a8 100644 --- a/src/UserGuide/latest-Table/SQL-Manual/From-Join-Clause.md +++ b/src/UserGuide/latest-Table/SQL-Manual/From-Join-Clause.md @@ -217,7 +217,7 @@ comparisonOperator A semi join is a special join operation whose purpose is to determine whether rows in one table exist in another table. The result set returned by a semi join contains rows from the first table that meet the join condition, but does not include the actual data from the second table. Corresponding to semi join is anti-semi join, which is used to identify rows that have no matches between two tables. The result set returned by an anti-semi join contains rows from the first table that satisfy the join condition, but excludes rows from the second table that match those rows. -In the IoTDB table model, the `SEMI JOIN` syntax is not provided; instead, IN subqueries or EXISTS subqueries are supported to implement semi joins. Similarly, the `ANTI SEMI JOIN` syntax is not provided, and NOT IN or NOT EXISTS subqueries are supported to implement anti-semi joins. For detailed explanations of subqueries, refer to [Nested Queries](../SQL-Manual/Nested-Queries.md). +In the IoTDB table mode, the `SEMI JOIN` syntax is not provided; instead, IN subqueries or EXISTS subqueries are supported to implement semi joins. Similarly, the `ANTI SEMI JOIN` syntax is not provided, and NOT IN or NOT EXISTS subqueries are supported to implement anti-semi joins. For detailed explanations of subqueries, refer to [Nested Queries](../SQL-Manual/Nested-Queries.md). * Examples of semi join syntax are as follows: diff --git a/src/UserGuide/latest-Table/SQL-Manual/Keywords.md b/src/UserGuide/latest-Table/SQL-Manual/Keywords.md index 34d530637..a6531ef77 100644 --- a/src/UserGuide/latest-Table/SQL-Manual/Keywords.md +++ b/src/UserGuide/latest-Table/SQL-Manual/Keywords.md @@ -21,7 +21,7 @@ # Keywords -Reserved keywords must be enclosed in double quotes (" ") to be used as identifiers. Below is a list of all reserved keywords in the IoTDB table model. +Reserved keywords must be enclosed in double quotes (" ") to be used as identifiers. Below is a list of all reserved keywords in the IoTDB table mode. - ALTER - AND diff --git a/src/UserGuide/latest-Table/SQL-Manual/SQL-Maintenance-Statements.md b/src/UserGuide/latest-Table/SQL-Manual/SQL-Maintenance-Statements.md index 1a72ce7fe..e1cdadc12 100644 --- a/src/UserGuide/latest-Table/SQL-Manual/SQL-Maintenance-Statements.md +++ b/src/UserGuide/latest-Table/SQL-Manual/SQL-Maintenance-Statements.md @@ -23,7 +23,7 @@ ## 1. Status Inspection -### 1.1 View Current Tree/Table Model +### 1.1 View Current Tree/Table Mode **Syntax:** @@ -228,7 +228,7 @@ IoTDB> SHOW REGIONS ## 2. Status Configuration -### 2.1 Set Connection Tree/Table Model +### 2.1 Set Connection Tree/Table Mode **Syntax:** diff --git a/src/UserGuide/latest-Table/Tools-System/Benchmark.md b/src/UserGuide/latest-Table/Tools-System/Benchmark.md index bf32467f3..c2fd1939c 100644 --- a/src/UserGuide/latest-Table/Tools-System/Benchmark.md +++ b/src/UserGuide/latest-Table/Tools-System/Benchmark.md @@ -157,12 +157,12 @@ The `IoTDB_DIALECT_MODE` parameter supports two modes: `tree` and `table`. The d Key Parameters for IoTDB Service Model -| **Parameter name** | **Type** | **Example** | **System description** | -| :---------------------- | :------- | :---------- | :----------------------------------------------------------- | +| **Parameter name** | **Type** | **Example** | **System description** | +| :---------------------- | :------- | :---------- |:--------------------------------------------------------------------| | IoTDB_TABLE_NAME_PREFIX | String | `table_` | Prefix for table names when `IoTDB_DIALECT_MODE` is set to `table`. | -| DATA_CLIENT_NUMBER | Integer | `10` | Number of clients, must be an integer multiple of the table count. | -| SENSOR_NUMBER | Integer | `10` | Controls the number of attribute columns in the table model. | -| IoTDB_TABLE_NUMBER | Integer | `1` | Specifies the number of tables when using the table model. | +| DATA_CLIENT_NUMBER | Integer | `10` | Number of clients, must be an integer multiple of the table count. | +| SENSOR_NUMBER | Integer | `10` | Controls the number of attribute columns in the table mode. | +| IoTDB_TABLE_NUMBER | Integer | `1` | Specifies the number of tables when using the table mode. | ### 3.2 **Working** **Mode** @@ -198,21 +198,21 @@ Once the working mode is specified, the following parameters must be configured ### 3.4 **Write Scenario Parameters** -| **Parameter** | **Type** | **Example** | D**escription** | -| :------------------------- | :-------------------- | :-------------------------- | :----------------------------------------------------------- | -| CLIENT_NUMBER | Integer | `100` | Total number of clients used for writing. | -| GROUP_NUMBER | Integer | `20` | Number of databases (only applicable for IoTDB). | -| DEVICE_NUMBER | Integer | `100` | Total number of devices. | -| SENSOR_NUMBER | Integer | `300` | Total number of sensors per device. (Control the number of attribute columns if you use the IoTDB table model) | -| INSERT_DATATYPE_PROPORTION | String | `1:1:1:1:1:1:0:0:0:0` | Ratio of data types: `BOOLEAN:INT32:INT64:FLOAT:DOUBLE:TEXT:STRING:BLOB:TIMESTAMP:DATE`. | -| POINT_STEP | Integer | `1000` | Time interval (in ms) between generated data points. | +| **Parameter** | **Type** | **Example** | D**escription** | +| :------------------------- | :-------------------- | :-------------------------- |:-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------| +| CLIENT_NUMBER | Integer | `100` | Total number of clients used for writing. | +| GROUP_NUMBER | Integer | `20` | Number of databases (only applicable for IoTDB). | +| DEVICE_NUMBER | Integer | `100` | Total number of devices. | +| SENSOR_NUMBER | Integer | `300` | Total number of sensors per device. (Control the number of attribute columns if you use the IoTDB table mode) | +| INSERT_DATATYPE_PROPORTION | String | `1:1:1:1:1:1:0:0:0:0` | Ratio of data types: `BOOLEAN:INT32:INT64:FLOAT:DOUBLE:TEXT:STRING:BLOB:TIMESTAMP:DATE`. | +| POINT_STEP | Integer | `1000` | Time interval (in ms) between generated data points. | | OP_MIN_INTERVAL | Integer | `0` | Minimum execution interval for operations (ms): if the operation takes more than the value, the next one will be executed immediately, otherwise wait (OP_MIN_INTERVAL - actual execution time) ms; if it is 0, the parameter is not effective; if it is -1, its value is consistent with POINT_STEP | -| IS_OUT_OF_ORDER | Boolean | `false` | Specifies whether to write data out of order. | -| OUT_OF_ORDER_RATIO | Floating point number | `0.3` | Proportion of out-of-order data. | -| BATCH_SIZE_PER_WRITE | Integer | `1` | Number of data rows written per batch. | -| START_TIME | Time | `2022-10-30T00:00:00+08:00` | Start timestamp for data generation. | -| LOOP | Integer | `86400` | Total number of write operations: Each type of operation will be divided according to the proportion defined by `OPERATION_PROPORTION` | -| OPERATION_PROPORTION | Character | `1:0:0:0:0:0:0:0:0:0:0` | Ratio of operation types (write:Q1:Q2:...:Q10). | +| IS_OUT_OF_ORDER | Boolean | `false` | Specifies whether to write data out of order. | +| OUT_OF_ORDER_RATIO | Floating point number | `0.3` | Proportion of out-of-order data. | +| BATCH_SIZE_PER_WRITE | Integer | `1` | Number of data rows written per batch. | +| START_TIME | Time | `2022-10-30T00:00:00+08:00` | Start timestamp for data generation. | +| LOOP | Integer | `86400` | Total number of write operations: Each type of operation will be divided according to the proportion defined by `OPERATION_PROPORTION` | +| OPERATION_PROPORTION | Character | `1:0:0:0:0:0:0:0:0:0:0` | Ratio of operation types (write:Q1:Q2:...:Q10). | ### 3.5 **Query Scenario Parameters** @@ -352,7 +352,7 @@ Test results will be displayed in the terminal. ## 4. Test Example -This example demonstrates how to configure and run an IoT-benchmark test with IoTDB 2.0 using the table model for writing and querying. +This example demonstrates how to configure and run an IoT-benchmark test with IoTDB 2.0 using the table mode for writing and querying. ```Properties ----------------------Main Configurations---------------------- diff --git a/src/UserGuide/latest-Table/User-Manual/Data-Sync_apache.md b/src/UserGuide/latest-Table/User-Manual/Data-Sync_apache.md index ea7a19f63..f9afa879d 100644 --- a/src/UserGuide/latest-Table/User-Manual/Data-Sync_apache.md +++ b/src/UserGuide/latest-Table/User-Manual/Data-Sync_apache.md @@ -81,7 +81,7 @@ By declaratively configuring these three parts in an SQL statement, flexible dat - Data synchronization between IoTDB of 1. x series version and IoTDB of 2. x and above series versions is not supported. - When performing data synchronization tasks, avoid executing any deletion operations to prevent inconsistencies between the two ends. -- The `pipe` and `pipe plugins` for tree models and table models are designed to be isolated from each other. Before creating a `pipe`, it is recommended to first use the `show` command to query the built-in plugins available under the current `-sql_dialect` parameter configuration to ensure syntax compatibility and functional support. +- The `pipe` and `pipe plugins` for tree modes and table modes are designed to be isolated from each other. Before creating a `pipe`, it is recommended to first use the `show` command to query the built-in plugins available under the current `-sql_dialect` parameter configuration to ensure syntax compatibility and functional support. ## 2. Usage Instructions diff --git a/src/UserGuide/latest-Table/User-Manual/Data-Sync_timecho.md b/src/UserGuide/latest-Table/User-Manual/Data-Sync_timecho.md index 73594769c..b6906bc64 100644 --- a/src/UserGuide/latest-Table/User-Manual/Data-Sync_timecho.md +++ b/src/UserGuide/latest-Table/User-Manual/Data-Sync_timecho.md @@ -80,7 +80,7 @@ By declaratively configuring these three parts in an SQL statement, flexible dat - Data synchronization between IoTDB of 1. x series version and IoTDB of 2. x and above series versions is not supported. - When performing data synchronization tasks, avoid executing any deletion operations to prevent inconsistencies between the two ends. -- The `pipe` and `pipe plugins` for tree models and table models are designed to be isolated from each other. Before creating a `pipe`, it is recommended to first use the `show` command to query the built-in plugins available under the current `-sql_dialect` parameter configuration to ensure syntax compatibility and functional support. +- The `pipe` and `pipe plugins` for tree modes and table modes are designed to be isolated from each other. Before creating a `pipe`, it is recommended to first use the `show` command to query the built-in plugins available under the current `-sql_dialect` parameter configuration to ensure syntax compatibility and functional support. ## 2. Usage Instructions diff --git a/src/UserGuide/latest-Table/User-Manual/User-defined-function.md b/src/UserGuide/latest-Table/User-Manual/User-defined-function.md index c14442755..ca276f39a 100644 --- a/src/UserGuide/latest-Table/User-Manual/User-defined-function.md +++ b/src/UserGuide/latest-Table/User-Manual/User-defined-function.md @@ -25,7 +25,7 @@ UDF refers to user-defined functions. IoTDB offers a variety of built-in time-series processing functions while supporting custom function extensions to fulfill advanced computational needs. -IoTDB's table model supports three types of UDFs, as detailed below: +IoTDB's table mode supports three types of UDFs, as detailed below: | UDF Type | Function Type | Description | |-----------------------------------------|---------------|--------------------------------| @@ -84,7 +84,7 @@ Key Notes: * Must not conflict with built-in function names. -3. Model Isolation: UDFs in ​Table Model and ​Tree Model operate in separate namespaces. +3. Mode Isolation: UDFs in ​Table Mode and ​Tree Mode operate in separate namespaces. 4. Class Collision Warning: Avoid implementing UDF classes with identical full names but different logic across JARs. If present, IoTDB may randomly load one, causing inconsistent behavior. diff --git a/src/UserGuide/latest/API/Programming-Go-Native-API.md b/src/UserGuide/latest/API/Programming-Go-Native-API.md index a4afa6c4f..9004e9417 100644 --- a/src/UserGuide/latest/API/Programming-Go-Native-API.md +++ b/src/UserGuide/latest/API/Programming-Go-Native-API.md @@ -409,8 +409,8 @@ func checkError(status *common.TSStatus, err error) { | `Host` | `string` | Choose one with `NodeUrls` | Single-node host address. | | `Port` | `string` | Choose one with `NodeUrls` | Single-node port. | | `NodeUrls` | `[]string` | Choose one with `Host`/`Port` | Cluster node address list, format: `"host:port"`. | -| `UserName` | `string` | Yes | Username. | +| `UserName` | `string` | Yes | Username. | | `Password` | `string` | Yes | Password. | | `FetchSize` | `int32` | No | Query result set fetch size, default 1024. | | `TimeZone` | `string` | No | Session time zone, e.g., "Asia/Shanghai". Default uses server time zone. | -| `Database` | `string` | No | For table model; used to set the session's default database. | +| `Database` | `string` | No | For table mode; used to set the session's default database. | diff --git a/src/UserGuide/latest/API/Programming-MQTT.md b/src/UserGuide/latest/API/Programming-MQTT.md index f99e0cdda..f170b502f 100644 --- a/src/UserGuide/latest/API/Programming-MQTT.md +++ b/src/UserGuide/latest/API/Programming-MQTT.md @@ -62,14 +62,14 @@ The IoTDB MQTT service load configurations from `${IOTDB_HOME}/${IOTDB_CONF}/iot Configurations are as follows: -| **Property** | **Description** | **Default** | -| ------------------------ | ---------------------------------------------------------------------------------------------------------------------- | ------------------- | -| `enable_mqtt_service` | Enable/ disable the MQTT service. | FALSE | -| `mqtt_host` | Host address bound to the MQTT service. | 127.0.0.1 | -| `mqtt_port` | Port bound to the MQTT service. | 1883 | -| `mqtt_handler_pool_size` | Thread pool size for processing MQTT messages. | 1 | -| **`mqtt_payload_formatter`** | **Formatting method for MQTT message payloads. ​**​**Options: `json` (tree model), `line` (table model).** | **json** | -| `mqtt_max_message_size` | Maximum allowed MQTT message size (bytes). | 1048576 | +| **Property** | **Description** | **Default** | +| ------------------------ | -------------------------------------------------------------------------------------------------------------------- | ------------------- | +| `enable_mqtt_service` | Enable/ disable the MQTT service. | FALSE | +| `mqtt_host` | Host address bound to the MQTT service. | 127.0.0.1 | +| `mqtt_port` | Port bound to the MQTT service. | 1883 | +| `mqtt_handler_pool_size` | Thread pool size for processing MQTT messages. | 1 | +| **`mqtt_payload_formatter`** | **Formatting method for MQTT message payloads. ​**​**Options: `json` (tree mode), `line` (table mode).** | **json** | +| `mqtt_max_message_size` | Maximum allowed MQTT message size (bytes). | 1048576 | ## 4. Coding Examples The following is an example which a mqtt client send messages to IoTDB server. diff --git a/src/UserGuide/latest/API/Programming-OPC-UA_timecho.md b/src/UserGuide/latest/API/Programming-OPC-UA_timecho.md index 47a6ce5b2..e5a456f1d 100644 --- a/src/UserGuide/latest/API/Programming-OPC-UA_timecho.md +++ b/src/UserGuide/latest/API/Programming-OPC-UA_timecho.md @@ -84,7 +84,7 @@ start pipe p1; In this mode, IoTDB's stream processing engine establishes a connection with the OPC UA Server via an OPC UA Sink. The OPC UA Server maintains data within its Address Space, from which IoTDB can request and retrieve data. Additionally, other OPC UA Clients can access the data on the server. * Features: - * OPC UA organizes device information received from the Sink into folders under the Objects folder according to a tree model. + * OPC UA organizes device information received from the Sink into folders under the Objects folder according to a tree mode. * Each measurement point is recorded as a variable node, storing the latest value from the current database. * OPC UA cannot delete data or change data type settings. diff --git a/src/UserGuide/latest/Background-knowledge/Cluster-Concept_apache.md b/src/UserGuide/latest/Background-knowledge/Cluster-Concept_apache.md index 5a2b4652c..11e734753 100644 --- a/src/UserGuide/latest/Background-knowledge/Cluster-Concept_apache.md +++ b/src/UserGuide/latest/Background-knowledge/Cluster-Concept_apache.md @@ -25,8 +25,8 @@ | Concept | Meaning | | ----------------------- | ------------------------------------------------------------ | -| sql_dialect | IoTDB supports two time-series data models (SQL dialects), both managing devices and measurement points. Tree: Manages data in a hierarchical path manner, where one path corresponds to one measurement point of a device. Table: Manages data in a relational table manner, where one table corresponds to a category of devices. | -| Schema | Schema is the data model information of the database, i.e., tree structure or table structure. It includes definitions such as the names and data types of measurement points. | +| sql_dialect | IoTDB supports two time-series data modes (SQL dialects), both managing devices and measurement points. Tree: Manages data in a hierarchical path manner, where one path corresponds to one measurement point of a device. Table: Manages data in a relational table manner, where one table corresponds to a category of devices. | +| Schema | Schema is the data mode information of the database, i.e., tree structure or table structure. It includes definitions such as the names and data types of measurement points. | | Device | Corresponds to a physical device in an actual scenario, usually containing multiple measurement points. | | Timeseries | Also known as: physical quantity, time series, timeline, point location, semaphore, indicator, measurement value, etc. It is a time series formed by arranging multiple data points in ascending order of timestamps. Usually, a Timeseries represents a collection point that can periodically collect physical quantities of the environment it is in. | | Encoding | Encoding is a compression technique that represents data in binary form to improve storage efficiency. IoTDB supports various encoding methods for different types of data. For more detailed information, please refer to:[Encoding-and-Compression](../Technical-Insider/Encoding-and-Compression.md) | diff --git a/src/UserGuide/latest/Background-knowledge/Cluster-Concept_timecho.md b/src/UserGuide/latest/Background-knowledge/Cluster-Concept_timecho.md index 2307c4a71..deef3cdb5 100644 --- a/src/UserGuide/latest/Background-knowledge/Cluster-Concept_timecho.md +++ b/src/UserGuide/latest/Background-knowledge/Cluster-Concept_timecho.md @@ -25,8 +25,8 @@ | Concept | Meaning | | ----------------------- | ------------------------------------------------------------ | -| sql_dialect | IoTDB supports two time-series data models (SQL dialects), both managing devices and measurement points. Tree: Manages data in a hierarchical path manner, where one path corresponds to one measurement point of a device. Table: Manages data in a relational table manner, where one table corresponds to a category of devices. | -| Schema | Schema is the data model information of the database, i.e., tree structure or table structure. It includes definitions such as the names and data types of measurement points. | +| sql_dialect | IoTDB supports two time-series data mode (SQL dialects), both managing devices and measurement points. Tree: Manages data in a hierarchical path manner, where one path corresponds to one measurement point of a device. Table: Manages data in a relational table manner, where one table corresponds to a category of devices. | +| Schema | Schema is the data mode information of the database, i.e., tree structure or table structure. It includes definitions such as the names and data types of measurement points. | | Device | Corresponds to a physical device in an actual scenario, usually containing multiple measurement points. | | Timeseries | Also known as: physical quantity, time series, timeline, point location, semaphore, indicator, measurement value, etc. It is a time series formed by arranging multiple data points in ascending order of timestamps. Usually, a Timeseries represents a collection point that can periodically collect physical quantities of the environment it is in. | | Encoding | Encoding is a compression technique that represents data in binary form to improve storage efficiency. IoTDB supports various encoding methods for different types of data. For more detailed information, please refer to:[Encoding-and-Compression](../Technical-Insider/Encoding-and-Compression.md) | 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 c3c6b9b8a..bc1db965d 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 @@ -21,35 +21,35 @@ # Modeling Scheme Design -This section introduces how to transform time series data application scenarios into IoTDB time series modeling. +This section introduces how to transform time series data application scenarios into IoTDB time series mode. -## 1. Time Series Data Model +## 1. Time Series Data Mode -Before designing an IoTDB data model, it's essential to understand time series data and its underlying structure. For more details, refer to: [Time Series Data Model](../Background-knowledge/Navigating_Time_Series_Data.md) +Before designing an IoTDB data mode, it's essential to understand time series data and its underlying structure. For more details, refer to: [Time Series Data Mode](../Background-knowledge/Navigating_Time_Series_Data.md) -## 2. Two Time Series Model in IoTDB +## 2. Two Time Series Mode in IoTDB -IoTDB offers two data modeling syntaxes—tree model and table model, each with its distinct characteristics as follows: +IoTDB offers two data mode syntaxes—tree mode and table mode, each with its distinct characteristics as follows: -**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. +**Tree Mode**: 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. -> 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. +> 1. When performing data mode, 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. +> 2. When constructing tree mode [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. +**Table Mode**: 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. -### 2.1 Model Characteristics +### 2.1 Mode Characteristics -Both model syntaxes have their own applicable scenarios. +Both mode syntaxes have their own applicable scenarios. -The following table compares the tree model and the table model from various dimensions, including applicable scenarios and typical operations. Users can choose the appropriate model based on their specific usage requirements to achieve efficient data storage and management. +The following table compares the tree mode and the table mode from various dimensions, including applicable scenarios and typical operations. Users can choose the appropriate mode based on their specific usage requirements to achieve efficient data storage and management.
DimensionTree ModelTable ModelTree ModeTable Mode
Applicable Scenarios
- - + + @@ -79,20 +79,20 @@ The following table compares the tree model and the table model from various dim **Notes:** -- Both model spaces can coexist within the same cluster instance. Each model follows distinct syntax and database naming conventions, and they remain isolated by default. +- Both mode spaces can coexist within the same cluster instance. Each mode follows distinct syntax and database naming conventions, and they remain isolated by default. -- When establishing a database connection via client tools (Cli) or SDKs, specify the model syntax using the `sql_dialect` parameter (Tree syntax is used by default). +- When establishing a database connection via client tools (Cli) or SDKs, specify the mode syntax using the `sql_dialect` parameter (Tree syntax is used by default). ## 3. Application Scenarios The application scenarios mainly include two categories: -- Scenario 1: Using the tree model for data reading and writing. +- Scenario 1: Using the tree mode for data reading and writing. -- Scenario 2: Using the table model for data reading and writing. +- Scenario 2: Using the table mode for data reading and writing. -### 3.1 Scenario 1: Tree Model +### 3.1 Scenario 1: Tree Mode #### 3.1.1 Characteristics @@ -111,9 +111,9 @@ The application scenarios mainly include two categories: | **Device** | **Definition**: The second-to-last level is the device, such as `device1` in `root.db.turbine.device1.metric1`.
**Creation Method**: Cannot create a device alone; it exists as time series are created. | -#### 3.1.3 Modeling Examples +#### 3.1.3 Mode Examples -##### 3.1.3.1 How to model when managing multiple types of devices? +##### 3.1.3.1 How to mode when managing multiple types of devices? - If different types of devices in the scenario have different hierarchical paths and data point sets, create branches under the database node by device type. Each device type can have a different data point structure. @@ -121,7 +121,7 @@ The application scenarios mainly include two categories: -##### 3.1.3.2 How to model when there are no devices, only data points? +##### 3.1.3.2 How to when there are no devices, only data points? - For example, in a monitoring system for a station, each data point has a unique number but does not correspond to any specific device. @@ -129,20 +129,20 @@ The application scenarios mainly include two categories: -##### 3.1.3.3 How to model when a device has both sub-devices and data points? +##### 3.1.3.3 How to mode when a device has both sub-devices and data points? -- For example, in an energy storage scenario, each layer of the structure monitors its voltage and current. The following modeling approach can be used. +- For example, in an energy storage scenario, each layer of the structure monitors its voltage and current. The following mode approach can be used.
-### 3.2 Scenario 2: Table Model +### 3.2 Scenario 2: Table Mode #### 3.2.1 Characteristics -- Models and manages device time series data using time series tables, facilitating analysis with standard SQL. +- Modes and manages device time series data using time series tables, facilitating analysis with standard SQL. - Suitable for device data analysis or migrating data from other databases to IoTDB. @@ -161,9 +161,9 @@ The application scenarios mainly include two categories: **Data Filtering Efficiency**: Time Column = Tag Column > Attribute Column > Data Point Column. -#### 3.2.3 Modeling Examples +#### 3.2.3 Mode Examples -##### 3.2.3.1 How to model when managing multiple types of devices? +##### 3.2.3.1 How to mode when managing multiple types of devices? - Recommended to create a table for each type of device, with each table having different tags and data point sets. @@ -173,7 +173,7 @@ The application scenarios mainly include two categories: -##### 3.2.3.2 How to model when there are no device identifier columns or attribute columns? +##### 3.2.3.2 How to mode when there are no device identifier columns or attribute columns? - There is no limit to the number of columns; it can reach hundreds of thousands. @@ -181,7 +181,7 @@ The application scenarios mainly include two categories: -##### 3.2.3.3 How to model when a device has both sub-devices and data points? +##### 3.2.3.3 How to mode when a device has both sub-devices and data points? - Each device has multiple sub-devices and data point information. It is recommended to create a table for each type of device for management. 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 bf1308202..9f930f86d 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 @@ -21,35 +21,35 @@ # Modeling Scheme Design -This section introduces how to transform time series data application scenarios into IoTDB time series modeling. +This section introduces how to transform time series data application scenarios into IoTDB time series mode. -## 1. Time Series Data Model +## 1. Time Series Data Mode -Before designing an IoTDB data model, it's essential to understand time series data and its underlying structure. For more details, refer to: [Time Series Data Model](../Background-knowledge/Navigating_Time_Series_Data.md) +Before designing an IoTDB data mode, it's essential to understand time series data and its underlying structure. For more details, refer to: [Time Series Data Mode](../Background-knowledge/Navigating_Time_Series_Data.md) -## 2. Two Time Series Model in IoTDB +## 2. Two Time Series Mode in IoTDB -IoTDB offers two data modeling syntaxes—tree model and table model, each with its distinct characteristics as follows: +IoTDB offers two data mode syntaxes—tree mode and table mode, each with its distinct characteristics as follows: -**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. +**Tree Mode**: 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. -> 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. +> 1. When performing data mode, 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. +> 2. When constructing tree mode [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. +**Table Mode**: 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. -### 2.1 Model Characteristics +### 2.1 Mode Characteristics -Both model syntaxes have their own applicable scenarios. +Both mode syntaxes have their own applicable scenarios. -The following table compares the tree model and the table model from various dimensions, including applicable scenarios and typical operations. Users can choose the appropriate model based on their specific usage requirements to achieve efficient data storage and management. +The following table compares the tree mode and the table mode from various dimensions, including applicable scenarios and typical operations. Users can choose the appropriate mode based on their specific usage requirements to achieve efficient data storage and management.
DimensionTree ModelTable ModelTree ModeTable Mode
Applicable Scenarios
- - + + @@ -79,22 +79,22 @@ The following table compares the tree model and the table model from various dim **Notes:** -- Both model spaces can coexist within the same cluster instance. Each model follows distinct syntax and database naming conventions, and they remain isolated by default. +- Both mode spaces can coexist within the same cluster instance. Each mode follows distinct syntax and database naming conventions, and they remain isolated by default. -- When establishing a database connection via client tools (Cli) or SDKs, specify the model syntax using the `sql_dialect` parameter (Tree syntax is used by default). +- When establishing a database connection via client tools (Cli) or SDKs, specify the mode syntax using the `sql_dialect` parameter (Tree syntax is used by default). ## 3. Application Scenarios The application scenarios mainly include three categories: -- Scenario 1: Using the tree model for data reading and writing. +- Scenario 1: Using the tree mode for data reading and writing. -- Scenario 2: Using the table model for data reading and writing. +- Scenario 2: Using the table mode for data reading and writing. -- Scenario 3: Sharing the same dataset, using the tree model for data reading and writing, and the table model for data analysis. +- Scenario 3: Sharing the same dataset, using the tree mode for data reading and writing, and the table mode for data analysis. -### 3.1 Scenario 1: Tree Model +### 3.1 Scenario 1: Tree Mode #### 3.1.1 Characteristics @@ -112,9 +112,9 @@ The application scenarios mainly include three categories: | **Time Series (Data Point)** | **Definition**:
A path prefixed with the database path, segmented by `.`, and can contain any number of levels, such as `root.db.turbine.device1.metric1`.
Each time series can have different data types.
**Naming Recommendation**:
Only include unique identifiers (similar to a composite primary key) in the path, generally not exceeding 10 levels.
Typically, place tags with low cardinality (fewer distinct values) at the front to facilitate system compression of common prefixes.
**Quantity Recommendation**:
The total number of time series manageable by the cluster is related to total memory; refer to the resource recommendation section.
There is no limit to the number of child nodes at any level.
**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`.
**Creation Method**: Cannot create a device alone; it exists as time series are created. | -#### 3.1.3 Modeling Examples +#### 3.1.3 Mode Examples -##### 3.1.3.1 How to model when managing multiple types of devices? +##### 3.1.3.1 How to mode when managing multiple types of devices? - If different types of devices in the scenario have different hierarchical paths and data point sets, create branches under the database node by device type. Each device type can have a different data point structure. @@ -122,7 +122,7 @@ The application scenarios mainly include three categories: -##### 3.1.3.2 How to model when there are no devices, only data points? +##### 3.1.3.2 How to mode when there are no devices, only data points? - For example, in a monitoring system for a station, each data point has a unique number but does not correspond to any specific device. @@ -130,20 +130,20 @@ The application scenarios mainly include three categories: -##### 3.1.3.3 How to model when a device has both sub-devices and data points? +##### 3.1.3.3 How to mode when a device has both sub-devices and data points? -- For example, in an energy storage scenario, each layer of the structure monitors its voltage and current. The following modeling approach can be used. +- For example, in an energy storage scenario, each layer of the structure monitors its voltage and current. The following mode approach can be used.
-### 3.2 Scenario 2: Table Model +### 3.2 Scenario 2: Table Mode #### 3.2.1 Characteristics -- Models and manages device time series data using time series tables, facilitating analysis with standard SQL. +- Modes and manages device time series data using time series tables, facilitating analysis with standard SQL. - Suitable for device data analysis or migrating data from other databases to IoTDB. @@ -162,9 +162,9 @@ The application scenarios mainly include three categories: **Data Filtering Efficiency**: Time Column = Tag Column > Attribute Column > Data Point Column. -#### 3.2.3 Modeling Examples +#### 3.2.3 Mode Examples -##### 3.2.3.1 How to model when managing multiple types of devices? +##### 3.2.3.1 How to mode when managing multiple types of devices? - Recommended to create a table for each type of device, with each table having different tags and data point sets. @@ -174,7 +174,7 @@ The application scenarios mainly include three categories: -##### 3.2.3.2 How to model when there are no device identifier columns or attribute columns? +##### 3.2.3.2 How to mode when there are no device identifier columns or attribute columns? - There is no limit to the number of columns; it can reach hundreds of thousands. @@ -182,7 +182,7 @@ The application scenarios mainly include three categories: -##### 3.2.3.3 How to model when a device has both sub-devices and data points? +##### 3.2.3.3 How to mode when a device has both sub-devices and data points? - Each device has multiple sub-devices and data point information. It is recommended to create a table for each type of device for management. @@ -190,23 +190,23 @@ The application scenarios mainly include three categories: -### 3.3 Scenario 3: Dual-Model Integration +### 3.3 Scenario 3: Dual-Mode Integration #### 3.3.1 Characteristics -- Ingeniously combines the advantages of the tree model and table model, sharing the same dataset, with flexible writing and rich querying. +- Ingeniously combines the advantages of the tree mode and table mode, sharing the same dataset, with flexible writing and rich querying. -- During the data writing phase, the tree model syntax is used, supporting flexible data access and expansion. +- During the data writing phase, the tree mode syntax is used, supporting flexible data access and expansion. -- During the data analysis phase, the table model syntax is used, allowing users to perform complex data analysis using standard SQL queries. +- During the data analysis phase, the table mode syntax is used, allowing users to perform complex data analysis using standard SQL queries. -#### 3.3.2 Modeling Examples +#### 3.3.2 Mode Examples -##### 3.3.2.1 How to model when managing multiple types of devices? +##### 3.3.2.1 How to mode when managing multiple types of devices? - Different types of devices in the scenario have different hierarchical paths and data point sets. -- **Tree Model**T: Create branches under the database node by device type, with each device type having a different data point structure. +- **Tree Mode**T: Create branches under the database node by device type, with each device type having a different data point structure. - **Table View**T: Create a table view for each type of device, with each table view having different tags and data point sets. @@ -214,18 +214,18 @@ The application scenarios mainly include three categories: -##### 3.3.2.2 How to model when there are no device identifier columns or attribute columns? +##### 3.3.2.2 How to mode when there are no device identifier columns or attribute columns? -- **Tree Model**: Each data point has a unique number but does not correspond to any specific device. +- **Tree Mode**: Each data point has a unique number but does not correspond to any specific device. - **Table View**: Place all data points into a single table. There is no limit to the number of data point columns; it can reach hundreds of thousands. If data points have the same data type, they can be treated as the same type of device.
-##### 3.3.2.3 How to model when a device has both sub-devices and data points? +##### 3.3.2.3 How to mode when a device has both sub-devices and data points? -- **Tree Model**: Model each layer of the structure according to the monitoring points in the physical world. +- **Tree Mode**: Mode each layer of the structure according to the monitoring points in the physical world. - **Table View**: Create multiple tables to manage each layer of structural information according to device classification.
diff --git a/src/UserGuide/latest/Ecosystem-Integration/DBeaver.md b/src/UserGuide/latest/Ecosystem-Integration/DBeaver.md index f801162b3..63b20df75 100644 --- a/src/UserGuide/latest/Ecosystem-Integration/DBeaver.md +++ b/src/UserGuide/latest/Ecosystem-Integration/DBeaver.md @@ -45,7 +45,7 @@ Ensure DBeaver and IoTDB are installed: ![](/img/dbeaver-2520-3-en.png) -3. Complete the connection settings, and choose the appropriate sql dialect based on whether the target IoTDB uses a ​​Tree Model​​ or ​​Table Model​​. +3. Complete the connection settings, and choose the appropriate sql dialect based on whether the target IoTDB uses a ​​Tree Mode​​ or ​​Table Mode​​. ![](/img/dbeaver-2520-4-en.png) diff --git a/src/UserGuide/latest/IoTDB-Introduction/Release-history_apache.md b/src/UserGuide/latest/IoTDB-Introduction/Release-history_apache.md index 07fef6080..7a39c6250 100644 --- a/src/UserGuide/latest/IoTDB-Introduction/Release-history_apache.md +++ b/src/UserGuide/latest/IoTDB-Introduction/Release-history_apache.md @@ -24,22 +24,22 @@ > Release Date: 2026.01.20 -V2.0.6 is the official release of the dual-model (tree and table) architecture. It introduces **query-writeback capability for the table model**, new **bitwise operation functions** (built-in scalar functions), and **push-down-capable time functions**, while delivering comprehensive improvements in database monitoring, performance, and stability. Specific release contents are as follows: +V2.0.6 is the official release of the dual-mode (tree and table) architecture. It introduces **query-writeback capability for the table mode**, new **bitwise operation functions** (built-in scalar functions), and **push-down-capable time functions**, while delivering comprehensive improvements in database monitoring, performance, and stability. Specific release contents are as follows: -* **Query Module**: Added support for query-writeback functionality in the table model. -* **Query Module**: Enhanced row-pattern recognition in the table model to support aggregate functions, enabling analysis and computation over consecutive data sequences. -* **Query Module**: Introduced built-in scalar bitwise operation functions for the table model. -* **Query Module**: Added a push-down-capable `EXTRACT` time function for the table model. +* **Query Module**: Added support for query-writeback functionality in the table mode. +* **Query Module**: Enhanced row-pattern recognition in the table mode to support aggregate functions, enabling analysis and computation over consecutive data sequences. +* **Query Module**: Introduced built-in scalar bitwise operation functions for the table mode. +* **Query Module**: Added a push-down-capable `EXTRACT` time function for the table mode. * **Others**: Fixed security vulnerabilities CVE-2025-12183, CVE-2025-66566, and CVE-2025-11226. ## V2.0.5 > Release Date: 2025.08.21 -V2.0.5, as the official release of the Dual-Model Tree-Table system, primarily introduces the tree-to-table view, window functions for the table model, the aggregate function approx_most_frequent, and supports LEFT & RIGHT JOIN as well as ASOF LEFT JOIN. The AINode now includes two new built-in models, Timer-XL and Timer-Sundial, and supports inference capabilities for both tree and table models. Additionally, this version brings comprehensive improvements to database monitoring, performance, and stability. The specific updates are as follows: +V2.0.5, as the official release of the Dual-Mode Tree-Table system, primarily introduces the tree-to-table view, window functions for the table mode, the aggregate function approx_most_frequent, and supports LEFT & RIGHT JOIN as well as ASOF LEFT JOIN. The AINode now includes two new built-in models, Timer-XL and Timer-Sundial, and supports inference capabilities for both tree and table models. Additionally, this version brings comprehensive improvements to database monitoring, performance, and stability. The specific updates are as follows: * **Query Module**: Supports manual creation of tree-to-table views -* **Query Module**: Adds window functions for the table model +* **Query Module**: Adds window functions for the table mode * **Query Module**: Adds the aggregate function approx_most_frequent for the table model * **Query Module**: Extends JOIN functionality for the table model, supporting LEFT & RIGHT JOIN and ASOF LEFT JOIN * **Query Module**: The table model now supports row pattern recognition, enabling the capture of continuous data for analysis and computation @@ -114,7 +114,7 @@ As the official release of the dual tree-table model, V2.0.2 introduces table mo V2.0.1-beta introduces dual tree-table model configuration, supporting standard SQL query syntax, various functions/operators, stream processing, and Benchmark capabilities for the table model. Additional updates include: -* ​**​Table Model​**​: +* ​**​Table Mode​**​: * Supports standard SQL syntax (SELECT/WHERE/JOIN/GROUP BY/ORDER BY/LIMIT/subqueries) * Various functions including logical operators, mathematical functions, and time-series functions like DIFF * ​**​Storage Module​**​: diff --git a/src/UserGuide/latest/IoTDB-Introduction/Release-history_timecho.md b/src/UserGuide/latest/IoTDB-Introduction/Release-history_timecho.md index 6acc271b7..9fbc6f153 100644 --- a/src/UserGuide/latest/IoTDB-Introduction/Release-history_timecho.md +++ b/src/UserGuide/latest/IoTDB-Introduction/Release-history_timecho.md @@ -30,7 +30,7 @@ > Package Name: timechodb-2.0.6.6-bin.zip
> SHA512 Checksum: d12e60b8119690d63c501d0c2afcd527e39df8a8786198e35b53338e21939e1a9244805e710d81cbb62d02c2739909d7e8227c029660a0cd9ea7ca718cf9bdf6 -V2.0.6.6 primarily optimizes query performance for time series in the tree model, while delivering comprehensive improvements in database monitoring, performance, and stability. Specific release contents are as follows: +V2.0.6.6 primarily optimizes query performance for time series in the tree mode, while delivering comprehensive improvements in database monitoring, performance, and stability. Specific release contents are as follows: * **Query Module**: Improved query performance for `SHOW/COUNT TIMESERIES/DEVICES` statements. * **Others**: Fixed security vulnerabilities CVE-2025-12183, CVE-2025-66566, and CVE-2025-11226. @@ -45,7 +45,7 @@ V2.0.6.6 primarily optimizes query performance for time series in the tree model V2.0.6.4 focuses on enhancements to the storage and AINode modules, resolves several product defects, and provides comprehensive improvements in database monitoring, performance, and stability. Specific release contents are as follows: -* **Storage Module**: Added support for modifying the encoding and compression methods of time series in the tree model. +* **Storage Module**: Added support for modifying the encoding and compression methods of time series in the tree mode. * **AINode**: Introduced one-click deployment and optimized model inference capabilities. @@ -206,7 +206,7 @@ V2.0.2.1 adds ​**​table model permission management​**​, ​**​user ma V2.0.1.2 officially implements ​**​dual-model configuration (tree + table)​**​. The table model supports ​**​standard SQL queries​**​, diverse functions/operators, stream processing, and Benchmarking. Python client adds four new data types, and script tools support TsFile/CSV/SQL import/export. Key updates: -* ​**​Time-Series Table Model:​**​ +* ​**​Time-Series Table Mode:​**​ * Standard SQL: SELECT, WHERE, JOIN, GROUP BY, ORDER BY, LIMIT, nested queries * ​**​Query Module:​**​ * Logical operators, math functions, time-series functions (e.g., DIFF) diff --git a/src/UserGuide/latest/Tools-System/Benchmark.md b/src/UserGuide/latest/Tools-System/Benchmark.md index 2f6bd86d6..19fbdf1bd 100644 --- a/src/UserGuide/latest/Tools-System/Benchmark.md +++ b/src/UserGuide/latest/Tools-System/Benchmark.md @@ -189,21 +189,21 @@ Once the working mode is specified, the following parameters must be configured ### 3.4 **Write Scenario Parameters** -| **Parameter** | **Type** | **Example** | D**escription** | -| :------------------------- | :-------------------- | :-------------------------- | :----------------------------------------------------------- | -| CLIENT_NUMBER | Integer | `100` | Total number of clients used for writing. | -| GROUP_NUMBER | Integer | `20` | Number of databases (only applicable for IoTDB). | -| DEVICE_NUMBER | Integer | `100` | Total number of devices. | -| SENSOR_NUMBER | Integer | `300` | Total number of sensors per device. (Control the number of attribute columns if you use the IoTDB table model) | -| INSERT_DATATYPE_PROPORTION | String | `1:1:1:1:1:1:0:0:0:0` | Ratio of data types: `BOOLEAN:INT32:INT64:FLOAT:DOUBLE:TEXT:STRING:BLOB:TIMESTAMP:DATE`. | -| POINT_STEP | Integer | `1000` | Time interval (in ms) between generated data points. | +| **Parameter** | **Type** | **Example** | D**escription** | +| :------------------------- | :-------------------- | :-------------------------- |:-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------| +| CLIENT_NUMBER | Integer | `100` | Total number of clients used for writing. | +| GROUP_NUMBER | Integer | `20` | Number of databases (only applicable for IoTDB). | +| DEVICE_NUMBER | Integer | `100` | Total number of devices. | +| SENSOR_NUMBER | Integer | `300` | Total number of sensors per device. (Control the number of attribute columns if you use the IoTDB table mode) | +| INSERT_DATATYPE_PROPORTION | String | `1:1:1:1:1:1:0:0:0:0` | Ratio of data types: `BOOLEAN:INT32:INT64:FLOAT:DOUBLE:TEXT:STRING:BLOB:TIMESTAMP:DATE`. | +| POINT_STEP | Integer | `1000` | Time interval (in ms) between generated data points. | | OP_MIN_INTERVAL | Integer | `0` | Minimum execution interval for operations (ms): if the operation takes more than the value, the next one will be executed immediately, otherwise wait (OP_MIN_INTERVAL - actual execution time) ms; if it is 0, the parameter is not effective; if it is -1, its value is consistent with POINT_STEP | -| IS_OUT_OF_ORDER | Boolean | `false` | Specifies whether to write data out of order. | -| OUT_OF_ORDER_RATIO | Floating point number | `0.3` | Proportion of out-of-order data. | -| BATCH_SIZE_PER_WRITE | Integer | `1` | Number of data rows written per batch. | -| START_TIME | Time | `2022-10-30T00:00:00+08:00` | Start timestamp for data generation. | -| LOOP | Integer | `86400` | Total number of write operations: Each type of operation will be divided according to the proportion defined by `OPERATION_PROPORTION` | -| OPERATION_PROPORTION | Character | `1:0:0:0:0:0:0:0:0:0:0` | Ratio of operation types (write:Q1:Q2:...:Q10). | +| IS_OUT_OF_ORDER | Boolean | `false` | Specifies whether to write data out of order. | +| OUT_OF_ORDER_RATIO | Floating point number | `0.3` | Proportion of out-of-order data. | +| BATCH_SIZE_PER_WRITE | Integer | `1` | Number of data rows written per batch. | +| START_TIME | Time | `2022-10-30T00:00:00+08:00` | Start timestamp for data generation. | +| LOOP | Integer | `86400` | Total number of write operations: Each type of operation will be divided according to the proportion defined by `OPERATION_PROPORTION` | +| OPERATION_PROPORTION | Character | `1:0:0:0:0:0:0:0:0:0:0` | Ratio of operation types (write:Q1:Q2:...:Q10). | ### 3.5 **Query Scenario Parameters** diff --git a/src/UserGuide/latest/User-Manual/Data-Sync_apache.md b/src/UserGuide/latest/User-Manual/Data-Sync_apache.md index 39db1203d..2683ef7ec 100644 --- a/src/UserGuide/latest/User-Manual/Data-Sync_apache.md +++ b/src/UserGuide/latest/User-Manual/Data-Sync_apache.md @@ -483,18 +483,18 @@ pipe_all_sinks_rate_limit_bytes_per_second=-1 ### 5.1 source parameter -| key | value | value range | required or not | default value | -| :------------------------------ | :----------------------------------------------------------- |:-----------------------------------------------------------------------| :------- | :------------- | -| source | iotdb-source | String: iotdb-source | Required | - | -| inclusion | Used to specify the range of data to be synchronized in the data synchronization task, including data, schema, and auth | String:all, data(insert,delete), schema(database,timeseries,ttl), auth | Optional | data.insert | -| inclusion.exclusion | Used to exclude specific operations from the range specified by inclusion, reducing the amount of data synchronized | String:all, data(insert,delete), schema(database,timeseries,ttl), auth | Optional | - | +| key | value | value range | required or not | default value | +| :------------------------------ |:-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|:-----------------------------------------------------------------------| :------- | :------------- | +| source | iotdb-source | String: iotdb-source | Required | - | +| inclusion | Used to specify the range of data to be synchronized in the data synchronization task, including data, schema, and auth | String:all, data(insert,delete), schema(database,timeseries,ttl), auth | Optional | data.insert | +| inclusion.exclusion | Used to exclude specific operations from the range specified by inclusion, reducing the amount of data synchronized | String:all, data(insert,delete), schema(database,timeseries,ttl), auth | Optional | - | | mode.streaming | Specifies the capture source for time-series data writes. Applicable when mode.streamingis false, determining the source for capturing data.insertspecified in inclusion. Offers two strategies:- true: ​​Dynamic capture selection.​​ The system adaptively chooses between capturing individual write requests or only TsFile sealing requests based on downstream processing speed. Prioritizes capturing write requests for lower latency when processing is fast; captures only file sealing requests to avoid backlog when slow. Suitable for most scenarios, balancing latency and throughput optimally.- false: ​​Fixed batch capture.​​ Captures only TsFile sealing requests. Suitable for resource-constrained scenarios to reduce system load. Note: The snapshot data captured upon pipe startup is only provided to downstream processing in file format. | Boolean: true / false | Optional | true | -| mode.strict | Determines the strictness when filtering data using time/ path/ database-name/ table-nameparameters:- true: ​​Strict filtering.​​ The system strictly filters captured data according to the given conditions, ensuring only matching data is selected.- false: ​​Non-strict filtering.​​ The system may include some extra data during filtering. Suitable for performance-sensitive scenarios to reduce CPU and I/O consumption. | Boolean: true / false | Optional | true | -| mode.snapshot | Determines the capture mode for time-series data, affecting the dataspecified in inclusion. Offers two modes:- true: ​​Static data capture.​​ Upon pipe startup, a one-time data snapshot is captured. ​​The pipe will automatically terminate (DROP PIPE SQL is executed automatically) after the snapshot data is fully consumed.​​- false: ​​Dynamic data capture.​​ In addition to capturing a snapshot upon startup, the pipe continuously captures subsequent data changes. The pipe runs continuously to handle the dynamic data stream. | Boolean: true / false | Optional | false | -| path | Can be specified when the user connects with sql_dialectset to tree. For upgraded user pipes, the default sql_dialectis tree. This parameter determines the capture scope for time-series data, affecting the dataspecified in inclusion, as well as some sequence-related metadata. Data is selected into the streaming pipe if its tree model path matches the specified path. | String: IoTDB-standard tree path pattern, wildcards allowed | Optional | root.** | -| start-time | The start event time for synchronizing all data, including start-time | Long: [Long.MIN_VALUE, Long.MAX_VALUE] | Optional | Long.MIN_VALUE | -| end-time | The end event time for synchronizing all data, including end-time | Long: [Long.MIN_VALUE, Long.MAX_VALUE] | Optional | Long.MAX_VALUE | -| forwarding-pipe-requests | Whether to forward data written by other Pipes (usually data synchronization) | Boolean: true /false | Optional | true | +| mode.strict | Determines the strictness when filtering data using time/ path/ database-name/ table-nameparameters:- true: ​​Strict filtering.​​ The system strictly filters captured data according to the given conditions, ensuring only matching data is selected.- false: ​​Non-strict filtering.​​ The system may include some extra data during filtering. Suitable for performance-sensitive scenarios to reduce CPU and I/O consumption. | Boolean: true / false | Optional | true | +| mode.snapshot | Determines the capture mode for time-series data, affecting the dataspecified in inclusion. Offers two modes:- true: ​​Static data capture.​​ Upon pipe startup, a one-time data snapshot is captured. ​​The pipe will automatically terminate (DROP PIPE SQL is executed automatically) after the snapshot data is fully consumed.​​- false: ​​Dynamic data capture.​​ In addition to capturing a snapshot upon startup, the pipe continuously captures subsequent data changes. The pipe runs continuously to handle the dynamic data stream. | Boolean: true / false | Optional | false | +| path | Can be specified when the user connects with sql_dialectset to tree. For upgraded user pipes, the default sql_dialectis tree. This parameter determines the capture scope for time-series data, affecting the dataspecified in inclusion, as well as some sequence-related metadata. Data is selected into the streaming pipe if its tree mode path matches the specified path. | String: IoTDB-standard tree path pattern, wildcards allowed | Optional | root.** | +| start-time | The start event time for synchronizing all data, including start-time | Long: [Long.MIN_VALUE, Long.MAX_VALUE] | Optional | Long.MIN_VALUE | +| end-time | The end event time for synchronizing all data, including end-time | Long: [Long.MIN_VALUE, Long.MAX_VALUE] | Optional | Long.MAX_VALUE | +| forwarding-pipe-requests | Whether to forward data written by other Pipes (usually data synchronization) | Boolean: true /false | Optional | true | | mods | Same as mods.enable, whether to send the MODS file for TSFile. | Boolean: true / false | Optional | false | > 💎 **Note:** The difference between the values of true and false for the data extraction mode `mode.streaming` diff --git a/src/UserGuide/latest/User-Manual/Data-Sync_timecho.md b/src/UserGuide/latest/User-Manual/Data-Sync_timecho.md index 5bc5852ca..770833400 100644 --- a/src/UserGuide/latest/User-Manual/Data-Sync_timecho.md +++ b/src/UserGuide/latest/User-Manual/Data-Sync_timecho.md @@ -577,7 +577,7 @@ pipe_all_sinks_rate_limit_bytes_per_second=-1 | mode.streaming | Specifies the capture source for time-series data writes. Applicable when mode.streamingis false, determining the source for capturing data.insertspecified in inclusion. Offers two strategies:- true: ​​Dynamic capture selection.​​ The system adaptively chooses between capturing individual write requests or only TsFile sealing requests based on downstream processing speed. Prioritizes capturing write requests for lower latency when processing is fast; captures only file sealing requests to avoid backlog when slow. Suitable for most scenarios, balancing latency and throughput optimally.- false: ​​Fixed batch capture.​​ Captures only TsFile sealing requests. Suitable for resource-constrained scenarios to reduce system load. Note: The snapshot data captured upon pipe startup is only provided to downstream processing in file format. | Boolean: true / false |Optional | true | | mode.strict | Determines the strictness when filtering data using time/ path/ database-name/ table-nameparameters:- true: ​​Strict filtering.​​ The system strictly filters captured data according to the given conditions, ensuring only matching data is selected.- false: ​​Non-strict filtering.​​ The system may include some extra data during filtering. Suitable for performance-sensitive scenarios to reduce CPU and I/O consumption. | Boolean: true / false | Optional | true | | mode.snapshot | Determines the capture mode for time-series data, affecting the dataspecified in inclusion. Offers two modes:- true: ​​Static data capture.​​ Upon pipe startup, a one-time data snapshot is captured. ​​The pipe will automatically terminate (DROP PIPE SQL is executed automatically) after the snapshot data is fully consumed.​​- false: ​​Dynamic data capture.​​ In addition to capturing a snapshot upon startup, the pipe continuously captures subsequent data changes. The pipe runs continuously to handle the dynamic data stream. | Boolean: true / false | Optional | false | -| path | Can be specified when the user connects with sql_dialectset to tree. For upgraded user pipes, the default sql_dialectis tree. This parameter determines the capture scope for time-series data, affecting the dataspecified in inclusion, as well as some sequence-related metadata. Data is selected into the streaming pipe if its tree model path matches the specified path. | String: IoTDB-standard tree path pattern, wildcards allowed | Optional | root.** | +| path | Can be specified when the user connects with sql_dialectset to tree. For upgraded user pipes, the default sql_dialectis tree. This parameter determines the capture scope for time-series data, affecting the dataspecified in inclusion, as well as some sequence-related metadata. Data is selected into the streaming pipe if its tree mode path matches the specified path. | String: IoTDB-standard tree path pattern, wildcards allowed | Optional | root.** | | start-time | The start event time for synchronizing all data, including start-time | Long: [Long.MIN_VALUE, Long.MAX_VALUE] | Optional | Long.MIN_VALUE | | end-time | The end event time for synchronizing all data, including end-time | Long: [Long.MIN_VALUE, Long.MAX_VALUE] | Optional | Long.MAX_VALUE | | forwarding-pipe-requests | Whether to forward data written by other Pipes (usually data synchronization) | Boolean: true / false | Optional | true | diff --git a/src/UserGuide/latest/User-Manual/Maintenance-commands.md b/src/UserGuide/latest/User-Manual/Maintenance-commands.md index 070c0d242..ce4819350 100644 --- a/src/UserGuide/latest/User-Manual/Maintenance-commands.md +++ b/src/UserGuide/latest/User-Manual/Maintenance-commands.md @@ -24,7 +24,7 @@ ### 1.1 Viewing the Connected Model -**Description**: Returns the current SQL dialect model (`Tree` or `Table`). +**Description**: Returns the current SQL dialect mode (`Tree` or `Table`). **Syntax**: @@ -248,7 +248,7 @@ IoTDB> SHOW REGIONS ### 2.1 Setting the Connected Model -**Description**: Sets the current SQL dialect model to `Tree` or `Table` which can be used in both tree and table models. +**Description**: Sets the current SQL dialect mode to `Tree` or `Table` which can be used in both tree and table modes. **Syntax**:
DimensionTree ModelTable ModelTree ModeTable Mode
Applicable Scenarios