diff --git a/src/.vuepress/public/img/Data-model-en01.png b/src/.vuepress/public/img/Data-model-en01.png
new file mode 100644
index 000000000..48c85223c
Binary files /dev/null and b/src/.vuepress/public/img/Data-model-en01.png differ
diff --git a/src/.vuepress/public/img/Data-model-en02.png b/src/.vuepress/public/img/Data-model-en02.png
new file mode 100644
index 000000000..6aee3bb05
Binary files /dev/null and b/src/.vuepress/public/img/Data-model-en02.png differ
diff --git a/src/.vuepress/public/img/Data-model-en03.png b/src/.vuepress/public/img/Data-model-en03.png
new file mode 100644
index 000000000..e172a2199
Binary files /dev/null and b/src/.vuepress/public/img/Data-model-en03.png differ
diff --git a/src/.vuepress/public/img/Data-model-en04.png b/src/.vuepress/public/img/Data-model-en04.png
new file mode 100644
index 000000000..46ac0a0bb
Binary files /dev/null and b/src/.vuepress/public/img/Data-model-en04.png differ
diff --git a/src/.vuepress/public/img/Data-model-en05.png b/src/.vuepress/public/img/Data-model-en05.png
new file mode 100644
index 000000000..1b4e22598
Binary files /dev/null and b/src/.vuepress/public/img/Data-model-en05.png differ
diff --git a/src/.vuepress/public/img/Data-model-en06.png b/src/.vuepress/public/img/Data-model-en06.png
new file mode 100644
index 000000000..cec9509dc
Binary files /dev/null and b/src/.vuepress/public/img/Data-model-en06.png differ
diff --git a/src/.vuepress/public/img/Data-model-en07.png b/src/.vuepress/public/img/Data-model-en07.png
new file mode 100644
index 000000000..d8e7b9300
Binary files /dev/null and b/src/.vuepress/public/img/Data-model-en07.png differ
diff --git a/src/.vuepress/public/img/Data-model-en08.png b/src/.vuepress/public/img/Data-model-en08.png
new file mode 100644
index 000000000..e7477c7d1
Binary files /dev/null and b/src/.vuepress/public/img/Data-model-en08.png differ
diff --git a/src/.vuepress/public/img/Data-model-en09.png b/src/.vuepress/public/img/Data-model-en09.png
new file mode 100644
index 000000000..5ada4a22b
Binary files /dev/null and b/src/.vuepress/public/img/Data-model-en09.png differ
diff --git a/src/UserGuide/Master/Table/Background-knowledge/Cluster-Concept.md b/src/UserGuide/Master/Table/Background-knowledge/Cluster-Concept.md
new file mode 100644
index 000000000..b4631022f
--- /dev/null
+++ b/src/UserGuide/Master/Table/Background-knowledge/Cluster-Concept.md
@@ -0,0 +1,23 @@
+---
+redirectTo: Cluster-Concept_apache.html
+---
+
\ No newline at end of file
diff --git a/src/UserGuide/Master/Table/Background-knowledge/Cluster-Concept_apache.md b/src/UserGuide/Master/Table/Background-knowledge/Cluster-Concept_apache.md
new file mode 100644
index 000000000..e6fec93e8
--- /dev/null
+++ b/src/UserGuide/Master/Table/Background-knowledge/Cluster-Concept_apache.md
@@ -0,0 +1,128 @@
+
+
+# Common Concept
+
+## SQL Dialect Related Concepts
+
+### sql_dialect
+
+IoTDB supports two time-series data models (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.
+
+Each dialect comes with its own SQL syntax and query patterns tailored to its data model.
+
+### Schema
+
+Schema refers to the metadata structure of the database, which can follow either a tree or table format. It includes definitions such as measurement point names, data types, and storage configurations.
+
+### Device
+
+A device corresponds to a physical device in a real-world scenario, typically associated with multiple measurement points.
+
+### Timeseries
+
+Also referred to as: physical quantity, time series, timeline, point, signal, metric, measurement value, etc.
+A measurement point is a time series consisting of multiple data points arranged in ascending timestamp order. It typically represents a collection point that periodically gathers physical quantities from its environment.
+
+### Encoding
+
+Encoding is a compression technique that represents data in binary form, improving storage efficiency. IoTDB supports multiple encoding methods for different types of data. For details, refer to: [Compression and Encoding ](../Technical-Insider/Encoding-and-Compression.md)。
+
+### Compression
+
+ After encoding, IoTDB applies additional compression techniques to further reduce data size and improve storage efficiency. Various compression algorithms are supported. For details, refer to: [ Compression and Encoding](../Technical-Insider/Encoding-and-Compression.md)。
+
+## Distributed System Related Concepts
+
+IoTDB supports distributed deployments, typically in a 3C3D cluster model (3 ConfigNodes, 3 DataNodes), as illustrated below:
+
+
+
+### Key Concepts
+
+- **Nodes** (*ConfigNode,* *DataNode**, AINode*)
+- **Regions** (*SchemaRegion, DataRegion*)
+- **Replica Groups**
+
+Below is an introduction to these concepts.
+
+### Nodes
+
+An IoTDB cluster consists of three types of nodes, each with distinct responsibilities:
+
+- **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.
+
+### Data Partitioning
+
+IoTDB divides schema and data into **Regions**, which are managed by DataNodes.
+
+- **SchemaRegion**: Stores schema information (devices and measurement points). Regions with the same RegionID across different DataNodes serve as replicas.
+- **DataRegion**: Stores time-series data for a subset of devices over a specified time period. Regions with the same RegionID across different DataNodes act as replicas.
+
+For more details, see [Cluster Data Partitioning](../Technical-Insider/Cluster-data-partitioning.md)
+
+### Replica Groups
+
+Replica groups ensure high availability by maintaining multiple copies of schema and data. The recommended replication configurations are:
+
+| **Category** | **Configuration Item** | **Standalone Recommended** | **Cluster Recommended** |
+| ------------ | ------------------------- | -------------------------- | ----------------------- |
+| Metadata | schema_replication_factor | 1 | 3 |
+| Data | data_replication_factor | 1 | 2 |
+
+
+## Deployment Related Concepts
+
+IoTDB has two operation modes: standalone mode and cluster mode.
+
+### Standalone Mode
+
+An IoTDB standalone instance includes 1 ConfigNode and 1 DataNode, referred to as 1C1D.
+
+- **Features**: Easy for developers to install and deploy, with lower deployment and maintenance costs, and convenient operation.
+- **Applicable scenarios**: Situations with limited resources or where high availability is not a critical requirement, such as edge servers.
+- **Deployment method**:[Stand-Alone Deployment](../Deployment-and-Maintenance/Stand-Alone-Deployment_apache.md)
+
+
+### Cluster Mode
+
+An IoTDB cluster instance consists of 3 ConfigNodes and no fewer than 3 DataNodes, typically 3 DataNodes, referred to as 3C3D. In the event of partial node failures, the remaining nodes can still provide services, ensuring high availability of the database service, and the database performance can be improved with the addition of nodes.
+
+- **Features**: High availability and scalability, with the ability to enhance system performance by adding DataNodes.
+- **Applicable scenarios**: Enterprise-level application scenarios that require high availability and reliability.
+- **Deployment method**: [Cluster Deployment](../Deployment-and-Maintenance/Cluster-Deployment_apache.md)
+
+### Summary of Features
+
+| **Dimension** | **Stand-Alone Mode** | **Cluster Mode** |
+| :-------------------------- | :----------------------------------------------------- | :----------------------------------------------------------- |
+| Applicable Scenario | Edge deployment, low requirement for high availability | High-availability business, disaster recovery scenarios, etc. |
+| Number of Machines Required | 1 | ≥3 |
+| Security and Reliability | Cannot tolerate single-point failure | High, can tolerate single-point failure |
+| Scalability | Scalable by adding DataNodes to improve performance | Scalable by adding DataNodes to improve performance |
+| Performance | Scalable with the number of DataNodes | Scalable with the number of DataNodes |
+
+- The deployment steps for standalone mode and cluster mode are similar (adding ConfigNodes and DataNodes one by one), with the only differences being the number of replicas and the minimum number of nodes required to provide services.
\ No newline at end of file
diff --git a/src/UserGuide/Master/Table/Background-knowledge/Cluster-Concept_timecho.md b/src/UserGuide/Master/Table/Background-knowledge/Cluster-Concept_timecho.md
new file mode 100644
index 000000000..9229f35db
--- /dev/null
+++ b/src/UserGuide/Master/Table/Background-knowledge/Cluster-Concept_timecho.md
@@ -0,0 +1,140 @@
+
+
+# Common Concept
+
+## SQL Dialect Related Concepts
+
+### sql_dialect
+
+IoTDB supports two time-series data models (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.
+
+Each dialect comes with its own SQL syntax and query patterns tailored to its data model.
+
+### Schema
+
+Schema refers to the metadata structure of the database, which can follow either a tree or table format. It includes definitions such as measurement point names, data types, and storage configurations.
+
+### Device
+
+A device corresponds to a physical device in a real-world scenario, typically associated with multiple measurement points.
+
+### Timeseries
+
+Also referred to as: physical quantity, time series, timeline, point, signal, metric, measurement value, etc.
+A measurement point is a time series consisting of multiple data points arranged in ascending timestamp order. It typically represents a collection point that periodically gathers physical quantities from its environment.
+
+### Encoding
+
+Encoding is a compression technique that represents data in binary form, improving storage efficiency. IoTDB supports multiple encoding methods for different types of data. For details, refer to: [Compression and Encoding ](../Technical-Insider/Encoding-and-Compression.md)。
+
+### Compression
+
+ After encoding, IoTDB applies additional compression techniques to further reduce data size and improve storage efficiency. Various compression algorithms are supported. For details, refer to: [ Compression and Encoding](../Technical-Insider/Encoding-and-Compression.md)。
+
+## Distributed System Related Concepts
+
+IoTDB supports distributed deployments, typically in a 3C3D cluster model (3 ConfigNodes, 3 DataNodes), as illustrated below:
+
+
+
+### Key Concepts
+
+- **Nodes** (*ConfigNode,* *DataNode**, AINode*)
+- **Regions** (*SchemaRegion, DataRegion*)
+- **Replica Groups**
+
+Below is an introduction to these concepts.
+
+
+### Nodes
+
+An IoTDB cluster consists of three types of nodes, each with distinct responsibilities:
+
+- **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.
+
+### Data Partitioning
+
+IoTDB divides schema and data into **Regions**, which are managed by DataNodes.
+
+- **SchemaRegion**: Stores schema information (devices and measurement points). Regions with the same RegionID across different DataNodes serve as replicas.
+- **DataRegion**: Stores time-series data for a subset of devices over a specified time period. Regions with the same RegionID across different DataNodes act as replicas.
+
+For more details, see [Cluster Data Partitioning](../Technical-Insider/Cluster-data-partitioning.md)
+
+### Replica Groups
+
+Replica groups ensure high availability by maintaining multiple copies of schema and data. The recommended replication configurations are:
+
+| **Category** | **Configuration Item** | **Standalone Recommended** | **Cluster Recommended** |
+| ------------ | ------------------------- | -------------------------- | ----------------------- |
+| Metadata | schema_replication_factor | 1 | 3 |
+| Data | data_replication_factor | 1 | 2 |
+
+
+## Deployment Related Concepts
+
+IoTDB has two operation modes: standalone mode and cluster mode.
+
+### Standalone Mode
+
+An IoTDB standalone instance includes 1 ConfigNode and 1 DataNode, i.e., 1C1D.
+
+- **Features**: Easy for developers to install and deploy, with low deployment and maintenance costs and convenient operations.
+- **Use Cases**: Scenarios with limited resources or low high-availability requirements, such as edge servers.
+- **Deployment Method**: [Stand-Alone Deployment](../Deployment-and-Maintenance/Stand-Alone-Deployment_timecho.md)
+
+
+### Dual-Active Mode
+
+Dual-Active Deployment is a feature of TimechoDB, where two independent instances synchronize bidirectionally and can provide services simultaneously. If one instance stops and restarts, the other instance will resume data transfer from the breakpoint.
+
+> An IoTDB Dual-Active instance typically consists of 2 standalone nodes, i.e., 2 sets of 1C1D. Each instance can also be a cluster.
+
+- **Features**: The high-availability solution with the lowest resource consumption.
+- **Use Cases**: Scenarios with limited resources (only two servers) but requiring high availability.
+- **Deployment Method**: [Dual-Active Deployment](../Deployment-and-Maintenance/Dual-Active-Deployment_timecho.md)
+
+### Cluster Mode
+
+An IoTDB cluster instance consists of 3 ConfigNodes and no fewer than 3 DataNodes, typically 3 DataNodes, i.e., 3C3D. If some nodes fail, the remaining nodes can still provide services, ensuring high availability of the database. Performance can be improved by adding DataNodes.
+
+- **Features**: High availability, high scalability, and improved system performance by adding DataNodes.
+- **Use Cases**: Enterprise-level application scenarios requiring high availability and reliability.
+- **Deployment Method**: [Cluster Deployment](../Deployment-and-Maintenance/Cluster-Deployment_timecho.md)
+
+
+### Feature Summary
+
+| **Dimension** | **Stand-Alone Mode** | **Dual-Active Mode** | **Cluster Mode** |
+| :-------------------------- | :------------------------------------------------------- | :------------------------------------------------------ | :------------------------------------------------------ |
+| Use Cases | Edge-side deployment, low high-availability requirements | High-availability services, disaster recovery scenarios | High-availability services, disaster recovery scenarios |
+| Number of Machines Required | 1 | 2 | ≥3 |
+| Security and Reliability | Cannot tolerate single-point failure | High, can tolerate single-point failure | High, can tolerate single-point failure |
+| Scalability | Can expand DataNodes to improve performance | Each instance can be scaled as needed | Can expand DataNodes to improve performance |
+| Performance | Can scale with the number of DataNodes | Same as one of the instances | Can scale with the number of DataNodes |
+
+- Notes: The deployment steps for Stand-Alone Mode and Cluster Mode are similar (adding ConfigNodes and DataNodes one by one), with differences only in the number of replicas and the minimum number of nodes required to provide services.
\ No newline at end of file
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
new file mode 100644
index 000000000..e6664dfdb
--- /dev/null
+++ b/src/UserGuide/Master/Table/Background-knowledge/Data-Model-and-Terminology_apache.md
@@ -0,0 +1,185 @@
+
+
+# Time Series Modeling
+
+This section introduces how to transform time series data application scenarios into IoTDB time series modeling.
+
+## 1 Time Series Data Model
+
+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)
+
+## 2 Two Time Series Model in IoTDB
+
+IoTDB offers two data modeling syntaxes—tree model and table model, 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.
+
+**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.
+
+### 2.1 Model Characteristics
+
+Both model 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.
+
+
+
+ | Dimension |
+ Tree Model |
+ Table Model |
+
+
+ | Applicable Scenarios |
+ Measurements management, monitoring scenarios |
+ Device management, analysis scenarios |
+
+
+ | Typical Operations |
+ Read and write operations by specifying data point paths |
+ Data filtering and analysis through tags |
+
+
+ | Structural Characteristics |
+ Flexible addition and deletion, similar to a file system |
+ Template-based management, facilitating data governance |
+
+
+ | Syntax Characteristics |
+ Concise |
+ Standardized |
+
+
+ | Performance Comparison |
+ Similar |
+
+
+
+**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.
+
+- 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).
+
+
+## 3 Application Scenarios
+
+The application scenarios mainly include two categories:
+
+- Scenario 1: Using the tree model for data reading and writing.
+
+- Scenario 2: Using the table model for data reading and writing.
+
+### 3.1 Scenario 1: Tree Model
+
+#### 3.1.1 Characteristics
+
+- Simple and intuitive, corresponding one-to-one with monitoring points in the physical world.
+
+- Flexible like a file system, allowing the design of any branch structure.
+
+- Suitable for industrial monitoring scenarios such as DCS and SCADA.
+
+#### 3.1.2 Basic Concepts
+
+| **Concept** | **Definition** |
+| ---------------------------- | ------------------------------------------------------------ |
+| **Database** | **Definition**: A path prefixed with `root.`.
**Naming Recommendation**: Only include the next level node under `root`, such as `root.db`.
**Quantity Recommendation**: The upper limit is related to memory. A single database can fully utilize machine resources; there is no need to create multiple databases for performance reasons.
**Creation Method**: Recommended to create manually, but can also be created automatically when a time series is created (defaults to the next level node under `root`). |
+| **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.1 How to model 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.
+
+
+
+
+
+
+
+
Tag information cannot be modified or deleted but can be added.
Recommended to arrange from coarse to fine granularity. |
+| **Data Point Column (FIELD)** \| | A device can collect 1 to multiple data points, with values changing over time.
There is no limit to the number of data point columns; it can reach hundreds of thousands. |
+| **Attribute Column (ATTRIBUTE)** | Supplementary descriptions of devices, not changing over time.
Device attribute information can range from 0 to multiple and can be updated or added.
A small number of static attributes that may need modification can be stored here. |
+
+**Data Filtering Efficiency**: Time Column = Tag Column > Attribute Column > Data Point Column.
+
+#### 3.2.3 Modeling Examples
+
+##### 3.2.3.1 How to model 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.
+
+- Even if devices are related or have hierarchical relationships, it is recommended to create a table for each type of device.
+
+
+
+
+
+
+
+
+
+ | Dimension |
+ Tree Model |
+ Table Model |
+
+
+ | Applicable Scenarios |
+ Measurements management, monitoring scenarios |
+ Device management, analysis scenarios |
+
+
+ | Typical Operations |
+ Read and write operations by specifying data point paths |
+ Data filtering and analysis through tags |
+
+
+ | Structural Characteristics |
+ Flexible addition and deletion, similar to a file system |
+ Template-based management, facilitating data governance |
+
+
+ | Syntax Characteristics |
+ Concise |
+ Standardized |
+
+
+ | Performance Comparison |
+ Similar |
+
+
+
+**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.
+
+- 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).
+
+
+## 3 Application Scenarios
+
+The application scenarios mainly include three categories:
+
+- Scenario 1: Using the tree model for data reading and writing.
+
+- Scenario 2: Using the table model 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.
+
+### 3.1 Scenario 1: Tree Model
+
+#### 3.1.1 Characteristics
+
+- Simple and intuitive, corresponding one-to-one with monitoring points in the physical world.
+
+- Flexible like a file system, allowing the design of any branch structure.
+
+- Suitable for industrial monitoring scenarios such as DCS and SCADA.
+
+#### 3.1.2 Basic Concepts
+
+| **Concept** | **Definition** |
+| ---------------------------- | ------------------------------------------------------------ |
+| **Database** | **Definition**: A path prefixed with `root.`.
**Naming Recommendation**: Only include the next level node under `root`, such as `root.db`.
**Quantity Recommendation**: The upper limit is related to memory. A single database can fully utilize machine resources; there is no need to create multiple databases for performance reasons.
**Creation Method**: Recommended to create manually, but can also be created automatically when a time series is created (defaults to the next level node under `root`). |
+| **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.1 How to model 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.
+
+
+
+
+
+
+
+
Tag information cannot be modified or deleted but can be added.
Recommended to arrange from coarse to fine granularity. |
+| **Data Point Column (FIELD)** \| | A device can collect 1 to multiple data points, with values changing over time.
There is no limit to the number of data point columns; it can reach hundreds of thousands. |
+| **Attribute Column (ATTRIBUTE)** | Supplementary descriptions of devices, not changing over time.
Device attribute information can range from 0 to multiple and can be updated or added.
A small number of static attributes that may need modification can be stored here. |
+
+**Data Filtering Efficiency**: Time Column = Tag Column > Attribute Column > Data Point Column.
+
+#### 3.2.3 Modeling Examples
+
+##### 3.2.3.1 How to model 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.
+
+- Even if devices are related or have hierarchical relationships, it is recommended to create a table for each type of device.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+**DATETIME-INPUT Type Supports Format**
+
+
+| format |
+| :--------------------------- |
+| yyyy-MM-dd HH:mm:ss |
+| yyyy/MM/dd HH:mm:ss |
+| yyyy.MM.dd HH:mm:ss |
+| yyyy-MM-dd HH:mm:ssZZ |
+| yyyy/MM/dd HH:mm:ssZZ |
+| yyyy.MM.dd HH:mm:ssZZ |
+| yyyy/MM/dd HH:mm:ss.SSS |
+| yyyy-MM-dd HH:mm:ss.SSS |
+| yyyy.MM.dd HH:mm:ss.SSS |
+| yyyy-MM-dd HH:mm:ss.SSSZZ |
+| yyyy/MM/dd HH:mm:ss.SSSZZ |
+| yyyy.MM.dd HH:mm:ss.SSSZZ |
+| ISO8601 standard time format |
+
+
+
+
+> **Note:** `ZZ` represents a time zone offset (e.g., `+0800` for Beijing Time, `-0500` for Eastern Standard Time).
+
+IoTDB supports timestamp display in **LONG** format or **DATETIME-DISPLAY** format, allowing users to customize time output.
+
+
+
+**Syntax for Custom Time Formats in DATETIME-DISPLAY**
+
+
+| Symbol | Meaning | Presentation | Examples |
+| :----: | :-------------------------: | :----------: | :--------------------------------: |
+| G | era | era | era |
+| C | century of era (>=0) | number | 20 |
+| Y | year of era (>=0) | year | 1996 |
+| | | | |
+| x | weekyear | year | 1996 |
+| w | week of weekyear | number | 27 |
+| e | day of week | number | 2 |
+| E | day of week | text | Tuesday; Tue |
+| | | | |
+| y | year | year | 1996 |
+| D | day of year | number | 189 |
+| M | month of year | month | July; Jul; 07 |
+| d | day of month | number | 10 |
+| | | | |
+| a | halfday of day | text | PM |
+| K | hour of halfday (0~11) | number | 0 |
+| h | clockhour of halfday (1~12) | number | 12 |
+| | | | |
+| H | hour of day (0~23) | number | 0 |
+| k | clockhour of day (1~24) | number | 24 |
+| m | minute of hour | number | 30 |
+| s | second of minute | number | 55 |
+| S | fraction of second | millis | 978 |
+| | | | |
+| z | time zone | text | Pacific Standard Time; PST |
+| Z | time zone offset/id | zone | -0800; -08:00; America/Los_Angeles |
+| | | | |
+| ' | escape for text | delimiter | |
+| '' | single quote | literal | ' |
+
+
+
+### 2.2 Relative Timestamp
+
+Relative timestamps allow specifying time offsets from **now()** or a **DATETIME** reference.
+
+The formal definition is:
+
+```Plain
+Duration = (Digit+ ('Y'|'MO'|'W'|'D'|'H'|'M'|'S'|'MS'|'US'|'NS'))+
+RelativeTime = (now() | DATETIME) ((+|-) Duration)+
+```
+
+
+
+ **The syntax of the duration unit**
+
+
+ | Symbol | Meaning | Presentation | Examples |
+ | :----: | :---------: | :----------------------: | :------: |
+ | y | year | 1y=365 days | 1y |
+ | mo | month | 1mo=30 days | 1mo |
+ | w | week | 1w=7 days | 1w |
+ | d | day | 1d=1 day | 1d |
+ | | | | |
+ | h | hour | 1h=3600 seconds | 1h |
+ | m | minute | 1m=60 seconds | 1m |
+ | s | second | 1s=1 second | 1s |
+ | | | | |
+ | ms | millisecond | 1ms=1000_000 nanoseconds | 1ms |
+ | us | microsecond | 1us=1000 nanoseconds | 1us |
+ | ns | nanosecond | 1ns=1 nanosecond | 1ns |
+
+
+
+**Examples:**
+
+```Plain
+now() - 1d2h // A time 1 day and 2 hours earlier than the server time
+now() - 1w // A time 1 week earlier than the server time
+```
+
+> **Note:** There must be spaces on both sides of `+` and `-` operators.
\ No newline at end of file
diff --git a/src/UserGuide/Master/Table/Background-knowledge/Navigating_Time_Series_Data.md b/src/UserGuide/Master/Table/Background-knowledge/Navigating_Time_Series_Data.md
new file mode 100644
index 000000000..eed444c82
--- /dev/null
+++ b/src/UserGuide/Master/Table/Background-knowledge/Navigating_Time_Series_Data.md
@@ -0,0 +1,51 @@
+
+# Time Series Data
+
+## 1. What is Time Series Data?
+
+In today's interconnected world, industries such as the Internet of Things (IoT) and manufacturing are undergoing rapid digital transformation. Sensors are widely deployed on various devices to collect real-time operational data. For example:
+
+- **Motors** record voltage and current.
+- **Wind Turbines** track blade speed, angular velocity, and power output.
+- **Vehicles** capture GPS coordinates, speed, and fuel consumption.
+- **Bridges** monitor vibration frequency, deflection, and displacement.
+
+Sensor data collection has permeated almost every industry, generating vast amounts of **time series data**.
+
+
+
+Each data collection point is referred to as a **measurement point** (also known as a physical quantity, time series, signal, metric, or measurement value). As time progresses, new data is continuously recorded for each measurement point, forming a **time series**. In tabular form, a time series consists of two columns: **timestamp** and **value**. When visualized, a time series appears as a trend chart over time, resembling an "electrocardiogram" of a device.
+
+
+
+Given the vast amount of time-series data generated by sensors, structuring this data effectively is essential for digital transformation across industries. Therefore, time-series data modeling is primarily centered around **devices** and **sensors**.
+
+## 2. Key Concepts in Time Series Data
+
+Several fundamental concepts define time-series data:
+
+| **Device** | Also known as an entity or equipment, a device is a real-world object that generates time-series data. In IoTDB, a device serves as a logical grouping of multiple time series. A device could be a physical machine, a measuring instrument, or a collection of sensors. Examples include:
- Energy sector: A wind turbine, identified by parameters such as region, power station, line, model, and instance.
- Manufacturing sector: A robotic arm, uniquely identified by an IoT platform-assigned ID.
- Connected vehicles: A car, identified by its Vehicle Identification Number (VIN).
- Monitoring systems: A CPU, identified by attributes such as data center, rack, hostname, and device type.|
+| ------------------------------- | ------------------------------------------------------------ |
+| **FIELD** | Also referred to as a physical quantity, signal, metric, or status point, a field represents a specific measurable property recorded by a sensor. Each field corresponds to a measurement point that periodically captures environmental data. Examples include:
- Energy and power: Current, voltage, wind speed, rotational speed.
- Connected vehicles: Fuel level, vehicle speed, latitude, longitude.
- Manufacturing: Temperature, humidity.|
+| **Data Point** | A data point consists of a timestamp and a value. The timestamp is typically stored as a long integer, while the value can be of various data types such as BOOLEAN, FLOAT, or INT32.
In tabular format, a data point corresponds to a single row in a time-series dataset, while in graphical representation, it is a single point on a time-series chart.
|
+| **Frequency** | The sampling frequency determines how often a sensor records data within a given timeframe.
For example, if a temperature sensor records data once per second, its sampling frequency is 1Hz (1 sample per second). |
+| **TTL** | TTL (Time-to-Live) defines the retention period of stored data. Once the TTL expires, the data is automatically deleted.
IoTDB allows different TTL values for different datasets, enabling automated, periodic data deletion. Proper TTL configuration helps:
- Manage disk space efficiently, preventing storage overflow.
- Maintain high query performance.
- Reduce memory resource consumption. |
\ No newline at end of file
diff --git a/src/UserGuide/latest-Table/Background-knowledge/Cluster-Concept.md b/src/UserGuide/latest-Table/Background-knowledge/Cluster-Concept.md
new file mode 100644
index 000000000..b4631022f
--- /dev/null
+++ b/src/UserGuide/latest-Table/Background-knowledge/Cluster-Concept.md
@@ -0,0 +1,23 @@
+---
+redirectTo: Cluster-Concept_apache.html
+---
+
\ No newline at end of file
diff --git a/src/UserGuide/latest-Table/Background-knowledge/Cluster-Concept_apache.md b/src/UserGuide/latest-Table/Background-knowledge/Cluster-Concept_apache.md
new file mode 100644
index 000000000..e6fec93e8
--- /dev/null
+++ b/src/UserGuide/latest-Table/Background-knowledge/Cluster-Concept_apache.md
@@ -0,0 +1,128 @@
+
+
+# Common Concept
+
+## SQL Dialect Related Concepts
+
+### sql_dialect
+
+IoTDB supports two time-series data models (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.
+
+Each dialect comes with its own SQL syntax and query patterns tailored to its data model.
+
+### Schema
+
+Schema refers to the metadata structure of the database, which can follow either a tree or table format. It includes definitions such as measurement point names, data types, and storage configurations.
+
+### Device
+
+A device corresponds to a physical device in a real-world scenario, typically associated with multiple measurement points.
+
+### Timeseries
+
+Also referred to as: physical quantity, time series, timeline, point, signal, metric, measurement value, etc.
+A measurement point is a time series consisting of multiple data points arranged in ascending timestamp order. It typically represents a collection point that periodically gathers physical quantities from its environment.
+
+### Encoding
+
+Encoding is a compression technique that represents data in binary form, improving storage efficiency. IoTDB supports multiple encoding methods for different types of data. For details, refer to: [Compression and Encoding ](../Technical-Insider/Encoding-and-Compression.md)。
+
+### Compression
+
+ After encoding, IoTDB applies additional compression techniques to further reduce data size and improve storage efficiency. Various compression algorithms are supported. For details, refer to: [ Compression and Encoding](../Technical-Insider/Encoding-and-Compression.md)。
+
+## Distributed System Related Concepts
+
+IoTDB supports distributed deployments, typically in a 3C3D cluster model (3 ConfigNodes, 3 DataNodes), as illustrated below:
+
+
+
+### Key Concepts
+
+- **Nodes** (*ConfigNode,* *DataNode**, AINode*)
+- **Regions** (*SchemaRegion, DataRegion*)
+- **Replica Groups**
+
+Below is an introduction to these concepts.
+
+### Nodes
+
+An IoTDB cluster consists of three types of nodes, each with distinct responsibilities:
+
+- **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.
+
+### Data Partitioning
+
+IoTDB divides schema and data into **Regions**, which are managed by DataNodes.
+
+- **SchemaRegion**: Stores schema information (devices and measurement points). Regions with the same RegionID across different DataNodes serve as replicas.
+- **DataRegion**: Stores time-series data for a subset of devices over a specified time period. Regions with the same RegionID across different DataNodes act as replicas.
+
+For more details, see [Cluster Data Partitioning](../Technical-Insider/Cluster-data-partitioning.md)
+
+### Replica Groups
+
+Replica groups ensure high availability by maintaining multiple copies of schema and data. The recommended replication configurations are:
+
+| **Category** | **Configuration Item** | **Standalone Recommended** | **Cluster Recommended** |
+| ------------ | ------------------------- | -------------------------- | ----------------------- |
+| Metadata | schema_replication_factor | 1 | 3 |
+| Data | data_replication_factor | 1 | 2 |
+
+
+## Deployment Related Concepts
+
+IoTDB has two operation modes: standalone mode and cluster mode.
+
+### Standalone Mode
+
+An IoTDB standalone instance includes 1 ConfigNode and 1 DataNode, referred to as 1C1D.
+
+- **Features**: Easy for developers to install and deploy, with lower deployment and maintenance costs, and convenient operation.
+- **Applicable scenarios**: Situations with limited resources or where high availability is not a critical requirement, such as edge servers.
+- **Deployment method**:[Stand-Alone Deployment](../Deployment-and-Maintenance/Stand-Alone-Deployment_apache.md)
+
+
+### Cluster Mode
+
+An IoTDB cluster instance consists of 3 ConfigNodes and no fewer than 3 DataNodes, typically 3 DataNodes, referred to as 3C3D. In the event of partial node failures, the remaining nodes can still provide services, ensuring high availability of the database service, and the database performance can be improved with the addition of nodes.
+
+- **Features**: High availability and scalability, with the ability to enhance system performance by adding DataNodes.
+- **Applicable scenarios**: Enterprise-level application scenarios that require high availability and reliability.
+- **Deployment method**: [Cluster Deployment](../Deployment-and-Maintenance/Cluster-Deployment_apache.md)
+
+### Summary of Features
+
+| **Dimension** | **Stand-Alone Mode** | **Cluster Mode** |
+| :-------------------------- | :----------------------------------------------------- | :----------------------------------------------------------- |
+| Applicable Scenario | Edge deployment, low requirement for high availability | High-availability business, disaster recovery scenarios, etc. |
+| Number of Machines Required | 1 | ≥3 |
+| Security and Reliability | Cannot tolerate single-point failure | High, can tolerate single-point failure |
+| Scalability | Scalable by adding DataNodes to improve performance | Scalable by adding DataNodes to improve performance |
+| Performance | Scalable with the number of DataNodes | Scalable with the number of DataNodes |
+
+- The deployment steps for standalone mode and cluster mode are similar (adding ConfigNodes and DataNodes one by one), with the only differences being the number of replicas and the minimum number of nodes required to provide services.
\ No newline at end of file
diff --git a/src/UserGuide/latest-Table/Background-knowledge/Cluster-Concept_timecho.md b/src/UserGuide/latest-Table/Background-knowledge/Cluster-Concept_timecho.md
new file mode 100644
index 000000000..9229f35db
--- /dev/null
+++ b/src/UserGuide/latest-Table/Background-knowledge/Cluster-Concept_timecho.md
@@ -0,0 +1,140 @@
+
+
+# Common Concept
+
+## SQL Dialect Related Concepts
+
+### sql_dialect
+
+IoTDB supports two time-series data models (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.
+
+Each dialect comes with its own SQL syntax and query patterns tailored to its data model.
+
+### Schema
+
+Schema refers to the metadata structure of the database, which can follow either a tree or table format. It includes definitions such as measurement point names, data types, and storage configurations.
+
+### Device
+
+A device corresponds to a physical device in a real-world scenario, typically associated with multiple measurement points.
+
+### Timeseries
+
+Also referred to as: physical quantity, time series, timeline, point, signal, metric, measurement value, etc.
+A measurement point is a time series consisting of multiple data points arranged in ascending timestamp order. It typically represents a collection point that periodically gathers physical quantities from its environment.
+
+### Encoding
+
+Encoding is a compression technique that represents data in binary form, improving storage efficiency. IoTDB supports multiple encoding methods for different types of data. For details, refer to: [Compression and Encoding ](../Technical-Insider/Encoding-and-Compression.md)。
+
+### Compression
+
+ After encoding, IoTDB applies additional compression techniques to further reduce data size and improve storage efficiency. Various compression algorithms are supported. For details, refer to: [ Compression and Encoding](../Technical-Insider/Encoding-and-Compression.md)。
+
+## Distributed System Related Concepts
+
+IoTDB supports distributed deployments, typically in a 3C3D cluster model (3 ConfigNodes, 3 DataNodes), as illustrated below:
+
+
+
+### Key Concepts
+
+- **Nodes** (*ConfigNode,* *DataNode**, AINode*)
+- **Regions** (*SchemaRegion, DataRegion*)
+- **Replica Groups**
+
+Below is an introduction to these concepts.
+
+
+### Nodes
+
+An IoTDB cluster consists of three types of nodes, each with distinct responsibilities:
+
+- **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.
+
+### Data Partitioning
+
+IoTDB divides schema and data into **Regions**, which are managed by DataNodes.
+
+- **SchemaRegion**: Stores schema information (devices and measurement points). Regions with the same RegionID across different DataNodes serve as replicas.
+- **DataRegion**: Stores time-series data for a subset of devices over a specified time period. Regions with the same RegionID across different DataNodes act as replicas.
+
+For more details, see [Cluster Data Partitioning](../Technical-Insider/Cluster-data-partitioning.md)
+
+### Replica Groups
+
+Replica groups ensure high availability by maintaining multiple copies of schema and data. The recommended replication configurations are:
+
+| **Category** | **Configuration Item** | **Standalone Recommended** | **Cluster Recommended** |
+| ------------ | ------------------------- | -------------------------- | ----------------------- |
+| Metadata | schema_replication_factor | 1 | 3 |
+| Data | data_replication_factor | 1 | 2 |
+
+
+## Deployment Related Concepts
+
+IoTDB has two operation modes: standalone mode and cluster mode.
+
+### Standalone Mode
+
+An IoTDB standalone instance includes 1 ConfigNode and 1 DataNode, i.e., 1C1D.
+
+- **Features**: Easy for developers to install and deploy, with low deployment and maintenance costs and convenient operations.
+- **Use Cases**: Scenarios with limited resources or low high-availability requirements, such as edge servers.
+- **Deployment Method**: [Stand-Alone Deployment](../Deployment-and-Maintenance/Stand-Alone-Deployment_timecho.md)
+
+
+### Dual-Active Mode
+
+Dual-Active Deployment is a feature of TimechoDB, where two independent instances synchronize bidirectionally and can provide services simultaneously. If one instance stops and restarts, the other instance will resume data transfer from the breakpoint.
+
+> An IoTDB Dual-Active instance typically consists of 2 standalone nodes, i.e., 2 sets of 1C1D. Each instance can also be a cluster.
+
+- **Features**: The high-availability solution with the lowest resource consumption.
+- **Use Cases**: Scenarios with limited resources (only two servers) but requiring high availability.
+- **Deployment Method**: [Dual-Active Deployment](../Deployment-and-Maintenance/Dual-Active-Deployment_timecho.md)
+
+### Cluster Mode
+
+An IoTDB cluster instance consists of 3 ConfigNodes and no fewer than 3 DataNodes, typically 3 DataNodes, i.e., 3C3D. If some nodes fail, the remaining nodes can still provide services, ensuring high availability of the database. Performance can be improved by adding DataNodes.
+
+- **Features**: High availability, high scalability, and improved system performance by adding DataNodes.
+- **Use Cases**: Enterprise-level application scenarios requiring high availability and reliability.
+- **Deployment Method**: [Cluster Deployment](../Deployment-and-Maintenance/Cluster-Deployment_timecho.md)
+
+
+### Feature Summary
+
+| **Dimension** | **Stand-Alone Mode** | **Dual-Active Mode** | **Cluster Mode** |
+| :-------------------------- | :------------------------------------------------------- | :------------------------------------------------------ | :------------------------------------------------------ |
+| Use Cases | Edge-side deployment, low high-availability requirements | High-availability services, disaster recovery scenarios | High-availability services, disaster recovery scenarios |
+| Number of Machines Required | 1 | 2 | ≥3 |
+| Security and Reliability | Cannot tolerate single-point failure | High, can tolerate single-point failure | High, can tolerate single-point failure |
+| Scalability | Can expand DataNodes to improve performance | Each instance can be scaled as needed | Can expand DataNodes to improve performance |
+| Performance | Can scale with the number of DataNodes | Same as one of the instances | Can scale with the number of DataNodes |
+
+- Notes: The deployment steps for Stand-Alone Mode and Cluster Mode are similar (adding ConfigNodes and DataNodes one by one), with differences only in the number of replicas and the minimum number of nodes required to provide services.
\ No newline at end of file
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
new file mode 100644
index 000000000..e6664dfdb
--- /dev/null
+++ b/src/UserGuide/latest-Table/Background-knowledge/Data-Model-and-Terminology_apache.md
@@ -0,0 +1,185 @@
+
+
+# Time Series Modeling
+
+This section introduces how to transform time series data application scenarios into IoTDB time series modeling.
+
+## 1 Time Series Data Model
+
+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)
+
+## 2 Two Time Series Model in IoTDB
+
+IoTDB offers two data modeling syntaxes—tree model and table model, 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.
+
+**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.
+
+### 2.1 Model Characteristics
+
+Both model 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.
+
+
+
+ | Dimension |
+ Tree Model |
+ Table Model |
+
+
+ | Applicable Scenarios |
+ Measurements management, monitoring scenarios |
+ Device management, analysis scenarios |
+
+
+ | Typical Operations |
+ Read and write operations by specifying data point paths |
+ Data filtering and analysis through tags |
+
+
+ | Structural Characteristics |
+ Flexible addition and deletion, similar to a file system |
+ Template-based management, facilitating data governance |
+
+
+ | Syntax Characteristics |
+ Concise |
+ Standardized |
+
+
+ | Performance Comparison |
+ Similar |
+
+
+
+**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.
+
+- 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).
+
+
+## 3 Application Scenarios
+
+The application scenarios mainly include two categories:
+
+- Scenario 1: Using the tree model for data reading and writing.
+
+- Scenario 2: Using the table model for data reading and writing.
+
+### 3.1 Scenario 1: Tree Model
+
+#### 3.1.1 Characteristics
+
+- Simple and intuitive, corresponding one-to-one with monitoring points in the physical world.
+
+- Flexible like a file system, allowing the design of any branch structure.
+
+- Suitable for industrial monitoring scenarios such as DCS and SCADA.
+
+#### 3.1.2 Basic Concepts
+
+| **Concept** | **Definition** |
+| ---------------------------- | ------------------------------------------------------------ |
+| **Database** | **Definition**: A path prefixed with `root.`.
**Naming Recommendation**: Only include the next level node under `root`, such as `root.db`.
**Quantity Recommendation**: The upper limit is related to memory. A single database can fully utilize machine resources; there is no need to create multiple databases for performance reasons.
**Creation Method**: Recommended to create manually, but can also be created automatically when a time series is created (defaults to the next level node under `root`). |
+| **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.1 How to model 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.
+
+
+
+
+
+
+
+
Tag information cannot be modified or deleted but can be added.
Recommended to arrange from coarse to fine granularity. |
+| **Data Point Column (FIELD)** \| | A device can collect 1 to multiple data points, with values changing over time.
There is no limit to the number of data point columns; it can reach hundreds of thousands. |
+| **Attribute Column (ATTRIBUTE)** | Supplementary descriptions of devices, not changing over time.
Device attribute information can range from 0 to multiple and can be updated or added.
A small number of static attributes that may need modification can be stored here. |
+
+**Data Filtering Efficiency**: Time Column = Tag Column > Attribute Column > Data Point Column.
+
+#### 3.2.3 Modeling Examples
+
+##### 3.2.3.1 How to model 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.
+
+- Even if devices are related or have hierarchical relationships, it is recommended to create a table for each type of device.
+
+
+
+
+
+
+
+
+
+ | Dimension |
+ Tree Model |
+ Table Model |
+
+
+ | Applicable Scenarios |
+ Measurements management, monitoring scenarios |
+ Device management, analysis scenarios |
+
+
+ | Typical Operations |
+ Read and write operations by specifying data point paths |
+ Data filtering and analysis through tags |
+
+
+ | Structural Characteristics |
+ Flexible addition and deletion, similar to a file system |
+ Template-based management, facilitating data governance |
+
+
+ | Syntax Characteristics |
+ Concise |
+ Standardized |
+
+
+ | Performance Comparison |
+ Similar |
+
+
+
+**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.
+
+- 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).
+
+
+## 3 Application Scenarios
+
+The application scenarios mainly include three categories:
+
+- Scenario 1: Using the tree model for data reading and writing.
+
+- Scenario 2: Using the table model 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.
+
+### 3.1 Scenario 1: Tree Model
+
+#### 3.1.1 Characteristics
+
+- Simple and intuitive, corresponding one-to-one with monitoring points in the physical world.
+
+- Flexible like a file system, allowing the design of any branch structure.
+
+- Suitable for industrial monitoring scenarios such as DCS and SCADA.
+
+#### 3.1.2 Basic Concepts
+
+| **Concept** | **Definition** |
+| ---------------------------- | ------------------------------------------------------------ |
+| **Database** | **Definition**: A path prefixed with `root.`.
**Naming Recommendation**: Only include the next level node under `root`, such as `root.db`.
**Quantity Recommendation**: The upper limit is related to memory. A single database can fully utilize machine resources; there is no need to create multiple databases for performance reasons.
**Creation Method**: Recommended to create manually, but can also be created automatically when a time series is created (defaults to the next level node under `root`). |
+| **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.1 How to model 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.
+
+
+
+
+
+
+
+
Tag information cannot be modified or deleted but can be added.
Recommended to arrange from coarse to fine granularity. |
+| **Data Point Column (FIELD)** \| | A device can collect 1 to multiple data points, with values changing over time.
There is no limit to the number of data point columns; it can reach hundreds of thousands. |
+| **Attribute Column (ATTRIBUTE)** | Supplementary descriptions of devices, not changing over time.
Device attribute information can range from 0 to multiple and can be updated or added.
A small number of static attributes that may need modification can be stored here. |
+
+**Data Filtering Efficiency**: Time Column = Tag Column > Attribute Column > Data Point Column.
+
+#### 3.2.3 Modeling Examples
+
+##### 3.2.3.1 How to model 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.
+
+- Even if devices are related or have hierarchical relationships, it is recommended to create a table for each type of device.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+**DATETIME-INPUT Type Supports Format**
+
+
+| format |
+| :--------------------------- |
+| yyyy-MM-dd HH:mm:ss |
+| yyyy/MM/dd HH:mm:ss |
+| yyyy.MM.dd HH:mm:ss |
+| yyyy-MM-dd HH:mm:ssZZ |
+| yyyy/MM/dd HH:mm:ssZZ |
+| yyyy.MM.dd HH:mm:ssZZ |
+| yyyy/MM/dd HH:mm:ss.SSS |
+| yyyy-MM-dd HH:mm:ss.SSS |
+| yyyy.MM.dd HH:mm:ss.SSS |
+| yyyy-MM-dd HH:mm:ss.SSSZZ |
+| yyyy/MM/dd HH:mm:ss.SSSZZ |
+| yyyy.MM.dd HH:mm:ss.SSSZZ |
+| ISO8601 standard time format |
+
+
+
+
+> **Note:** `ZZ` represents a time zone offset (e.g., `+0800` for Beijing Time, `-0500` for Eastern Standard Time).
+
+IoTDB supports timestamp display in **LONG** format or **DATETIME-DISPLAY** format, allowing users to customize time output.
+
+
+
+**Syntax for Custom Time Formats in DATETIME-DISPLAY**
+
+
+| Symbol | Meaning | Presentation | Examples |
+| :----: | :-------------------------: | :----------: | :--------------------------------: |
+| G | era | era | era |
+| C | century of era (>=0) | number | 20 |
+| Y | year of era (>=0) | year | 1996 |
+| | | | |
+| x | weekyear | year | 1996 |
+| w | week of weekyear | number | 27 |
+| e | day of week | number | 2 |
+| E | day of week | text | Tuesday; Tue |
+| | | | |
+| y | year | year | 1996 |
+| D | day of year | number | 189 |
+| M | month of year | month | July; Jul; 07 |
+| d | day of month | number | 10 |
+| | | | |
+| a | halfday of day | text | PM |
+| K | hour of halfday (0~11) | number | 0 |
+| h | clockhour of halfday (1~12) | number | 12 |
+| | | | |
+| H | hour of day (0~23) | number | 0 |
+| k | clockhour of day (1~24) | number | 24 |
+| m | minute of hour | number | 30 |
+| s | second of minute | number | 55 |
+| S | fraction of second | millis | 978 |
+| | | | |
+| z | time zone | text | Pacific Standard Time; PST |
+| Z | time zone offset/id | zone | -0800; -08:00; America/Los_Angeles |
+| | | | |
+| ' | escape for text | delimiter | |
+| '' | single quote | literal | ' |
+
+
+
+### 2.2 Relative Timestamp
+
+Relative timestamps allow specifying time offsets from **now()** or a **DATETIME** reference.
+
+The formal definition is:
+
+```Plain
+Duration = (Digit+ ('Y'|'MO'|'W'|'D'|'H'|'M'|'S'|'MS'|'US'|'NS'))+
+RelativeTime = (now() | DATETIME) ((+|-) Duration)+
+```
+
+
+
+ **The syntax of the duration unit**
+
+
+ | Symbol | Meaning | Presentation | Examples |
+ | :----: | :---------: | :----------------------: | :------: |
+ | y | year | 1y=365 days | 1y |
+ | mo | month | 1mo=30 days | 1mo |
+ | w | week | 1w=7 days | 1w |
+ | d | day | 1d=1 day | 1d |
+ | | | | |
+ | h | hour | 1h=3600 seconds | 1h |
+ | m | minute | 1m=60 seconds | 1m |
+ | s | second | 1s=1 second | 1s |
+ | | | | |
+ | ms | millisecond | 1ms=1000_000 nanoseconds | 1ms |
+ | us | microsecond | 1us=1000 nanoseconds | 1us |
+ | ns | nanosecond | 1ns=1 nanosecond | 1ns |
+
+
+
+**Examples:**
+
+```Plain
+now() - 1d2h // A time 1 day and 2 hours earlier than the server time
+now() - 1w // A time 1 week earlier than the server time
+```
+
+> **Note:** There must be spaces on both sides of `+` and `-` operators.
\ No newline at end of file
diff --git a/src/UserGuide/latest-Table/Background-knowledge/Navigating_Time_Series_Data.md b/src/UserGuide/latest-Table/Background-knowledge/Navigating_Time_Series_Data.md
new file mode 100644
index 000000000..eed444c82
--- /dev/null
+++ b/src/UserGuide/latest-Table/Background-knowledge/Navigating_Time_Series_Data.md
@@ -0,0 +1,51 @@
+
+# Time Series Data
+
+## 1. What is Time Series Data?
+
+In today's interconnected world, industries such as the Internet of Things (IoT) and manufacturing are undergoing rapid digital transformation. Sensors are widely deployed on various devices to collect real-time operational data. For example:
+
+- **Motors** record voltage and current.
+- **Wind Turbines** track blade speed, angular velocity, and power output.
+- **Vehicles** capture GPS coordinates, speed, and fuel consumption.
+- **Bridges** monitor vibration frequency, deflection, and displacement.
+
+Sensor data collection has permeated almost every industry, generating vast amounts of **time series data**.
+
+
+
+Each data collection point is referred to as a **measurement point** (also known as a physical quantity, time series, signal, metric, or measurement value). As time progresses, new data is continuously recorded for each measurement point, forming a **time series**. In tabular form, a time series consists of two columns: **timestamp** and **value**. When visualized, a time series appears as a trend chart over time, resembling an "electrocardiogram" of a device.
+
+
+
+Given the vast amount of time-series data generated by sensors, structuring this data effectively is essential for digital transformation across industries. Therefore, time-series data modeling is primarily centered around **devices** and **sensors**.
+
+## 2. Key Concepts in Time Series Data
+
+Several fundamental concepts define time-series data:
+
+| **Device** | Also known as an entity or equipment, a device is a real-world object that generates time-series data. In IoTDB, a device serves as a logical grouping of multiple time series. A device could be a physical machine, a measuring instrument, or a collection of sensors. Examples include:
- Energy sector: A wind turbine, identified by parameters such as region, power station, line, model, and instance.
- Manufacturing sector: A robotic arm, uniquely identified by an IoT platform-assigned ID.
- Connected vehicles: A car, identified by its Vehicle Identification Number (VIN).
- Monitoring systems: A CPU, identified by attributes such as data center, rack, hostname, and device type.|
+| ------------------------------- | ------------------------------------------------------------ |
+| **FIELD** | Also referred to as a physical quantity, signal, metric, or status point, a field represents a specific measurable property recorded by a sensor. Each field corresponds to a measurement point that periodically captures environmental data. Examples include:
- Energy and power: Current, voltage, wind speed, rotational speed.
- Connected vehicles: Fuel level, vehicle speed, latitude, longitude.
- Manufacturing: Temperature, humidity.|
+| **Data Point** | A data point consists of a timestamp and a value. The timestamp is typically stored as a long integer, while the value can be of various data types such as BOOLEAN, FLOAT, or INT32.
In tabular format, a data point corresponds to a single row in a time-series dataset, while in graphical representation, it is a single point on a time-series chart.
|
+| **Frequency** | The sampling frequency determines how often a sensor records data within a given timeframe.
For example, if a temperature sensor records data once per second, its sampling frequency is 1Hz (1 sample per second). |
+| **TTL** | TTL (Time-to-Live) defines the retention period of stored data. Once the TTL expires, the data is automatically deleted.
IoTDB allows different TTL values for different datasets, enabling automated, periodic data deletion. Proper TTL configuration helps:
- Manage disk space efficiently, preventing storage overflow.
- Maintain high query performance.
- Reduce memory resource consumption. |
\ No newline at end of file
diff --git a/src/zh/UserGuide/Master/Table/Background-knowledge/Data-Model-and-Terminology_apache.md b/src/zh/UserGuide/Master/Table/Background-knowledge/Data-Model-and-Terminology_apache.md
index f55ef4bb5..87d4e5e3e 100644
--- a/src/zh/UserGuide/Master/Table/Background-knowledge/Data-Model-and-Terminology_apache.md
+++ b/src/zh/UserGuide/Master/Table/Background-knowledge/Data-Model-and-Terminology_apache.md
@@ -29,7 +29,7 @@
## 2 IoTDB 的两种时序模型
-> IoTDB 提供了两种数据建模方式——树模型和表模型，其特点分别如下：
+IoTDB 提供了两种数据建模方式——树模型和表模型，其特点分别如下：
**树模型**：以测点为对象进行管理，每个测点对应一条时间序列，测点名按`.`分割可形成一个树形目录结构，与物理世界一一对应，对测点的读写操作简单直观。
diff --git a/src/zh/UserGuide/Master/Table/Background-knowledge/Data-Model-and-Terminology_timecho.md b/src/zh/UserGuide/Master/Table/Background-knowledge/Data-Model-and-Terminology_timecho.md
index 6032862fd..68a120281 100644
--- a/src/zh/UserGuide/Master/Table/Background-knowledge/Data-Model-and-Terminology_timecho.md
+++ b/src/zh/UserGuide/Master/Table/Background-knowledge/Data-Model-and-Terminology_timecho.md
@@ -29,7 +29,7 @@
## 2 IoTDB 的两种时序模型
-> IoTDB 提供了两种数据建模方式——树模型和表模型，其特点分别如下：
+IoTDB 提供了两种数据建模方式——树模型和表模型，其特点分别如下：
**树模型**：以测点为对象进行管理，每个测点对应一条时间序列，测点名按`.`分割可形成一个树形目录结构，与物理世界一一对应，对测点的读写操作简单直观。
@@ -186,7 +186,7 @@
-### 3.3 场景三：双模型结合（企业版功能）
+### 3.3 场景三：双模型结合
#### 3.3.1 特点
diff --git a/src/zh/UserGuide/Master/Table/Background-knowledge/Data-Type.md b/src/zh/UserGuide/Master/Table/Background-knowledge/Data-Type.md
index fc9a12c7c..4e043651a 100644
--- a/src/zh/UserGuide/Master/Table/Background-knowledge/Data-Type.md
+++ b/src/zh/UserGuide/Master/Table/Background-knowledge/Data-Type.md
@@ -21,7 +21,7 @@
# 数据类型
-## 基本数据类型
+## 1 基本数据类型
IoTDB 支持以下十种数据类型：
@@ -38,7 +38,7 @@ IoTDB 支持以下十种数据类型：
其中，STRING 和 TEXT 类型的区别在于，STRING 类型具有更多的统计信息，能够用于优化值过滤查询。TEXT 类型适合用于存储长字符串。
-### 浮点数精度配置
+### 1.1 浮点数精度配置
对于 **FLOAT** 与 **DOUBLE** 类型的序列，如果编码方式采用 `RLE`或 `TS_2DIFF`，可以在创建序列时通过 `MAX_POINT_NUMBER` 属性指定浮点数的小数点后位数。
@@ -47,9 +47,9 @@ IoTDB 支持以下十种数据类型：
CREATE TIMESERIES root.vehicle.d0.s0 WITH DATATYPE=FLOAT, ENCODING=RLE, 'MAX_POINT_NUMBER'='2';
```
-若不指定，系统会按照配置文件 `iotdb-system.properties` 中的 [float_precision](../Reference/Common-Config-Manual.md) 项配置（默认为 2 位）。
+若不指定，系统会按照配置文件 `iotdb-system.properties` 中的 [float_precision](../Reference/System-Config-Manual.md) 项配置（默认为 2 位）。
-### 数据类型兼容性
+### 1.2 数据类型兼容性
当写入数据的类型与序列注册的数据类型不一致时，
- 如果序列数据类型不兼容写入数据类型，系统会给出错误提示。
@@ -70,11 +70,11 @@ CREATE TIMESERIES root.vehicle.d0.s0 WITH DATATYPE=FLOAT, ENCODING=RLE, 'MAX_POI
| TIMESTAMP | INT32 INT64 TIMESTAMP |
| DATE | DATE |
-## 时间戳类型
+## 2 时间戳类型
时间戳是一个数据到来的时间点，其中包括绝对时间戳和相对时间戳。
-### 绝对时间戳
+### 2.1 绝对时间戳
IOTDB 中绝对时间戳分为二种，一种为 LONG 类型，一种为 DATETIME 类型（包含 DATETIME-INPUT, DATETIME-DISPLAY 两个小类）。
@@ -146,7 +146,7 @@ IoTDB 在显示时间戳时可以支持 LONG 类型以及 DATETIME-DISPLAY 类
-### 相对时间戳
+### 2.2 相对时间戳
相对时间是指与服务器时间```now()```和```DATETIME```类型时间相差一定时间间隔的时间。
形式化定义为：
diff --git a/src/zh/UserGuide/latest-Table/Background-knowledge/Data-Model-and-Terminology_apache.md b/src/zh/UserGuide/latest-Table/Background-knowledge/Data-Model-and-Terminology_apache.md
index f55ef4bb5..87d4e5e3e 100644
--- a/src/zh/UserGuide/latest-Table/Background-knowledge/Data-Model-and-Terminology_apache.md
+++ b/src/zh/UserGuide/latest-Table/Background-knowledge/Data-Model-and-Terminology_apache.md
@@ -29,7 +29,7 @@
## 2 IoTDB 的两种时序模型
-> IoTDB 提供了两种数据建模方式——树模型和表模型，其特点分别如下：
+IoTDB 提供了两种数据建模方式——树模型和表模型，其特点分别如下：
**树模型**：以测点为对象进行管理，每个测点对应一条时间序列，测点名按`.`分割可形成一个树形目录结构，与物理世界一一对应，对测点的读写操作简单直观。
diff --git a/src/zh/UserGuide/latest-Table/Background-knowledge/Data-Model-and-Terminology_timecho.md b/src/zh/UserGuide/latest-Table/Background-knowledge/Data-Model-and-Terminology_timecho.md
index 6032862fd..68a120281 100644
--- a/src/zh/UserGuide/latest-Table/Background-knowledge/Data-Model-and-Terminology_timecho.md
+++ b/src/zh/UserGuide/latest-Table/Background-knowledge/Data-Model-and-Terminology_timecho.md
@@ -29,7 +29,7 @@
## 2 IoTDB 的两种时序模型
-> IoTDB 提供了两种数据建模方式——树模型和表模型，其特点分别如下：
+IoTDB 提供了两种数据建模方式——树模型和表模型，其特点分别如下：
**树模型**：以测点为对象进行管理，每个测点对应一条时间序列，测点名按`.`分割可形成一个树形目录结构，与物理世界一一对应，对测点的读写操作简单直观。
@@ -186,7 +186,7 @@
-### 3.3 场景三：双模型结合（企业版功能）
+### 3.3 场景三：双模型结合
#### 3.3.1 特点
diff --git a/src/zh/UserGuide/latest-Table/Background-knowledge/Data-Type.md b/src/zh/UserGuide/latest-Table/Background-knowledge/Data-Type.md
index a033e0909..4e043651a 100644
--- a/src/zh/UserGuide/latest-Table/Background-knowledge/Data-Type.md
+++ b/src/zh/UserGuide/latest-Table/Background-knowledge/Data-Type.md
@@ -21,7 +21,7 @@
# 数据类型
-## 基本数据类型
+## 1 基本数据类型
IoTDB 支持以下十种数据类型：
@@ -38,7 +38,7 @@ IoTDB 支持以下十种数据类型：
其中，STRING 和 TEXT 类型的区别在于，STRING 类型具有更多的统计信息，能够用于优化值过滤查询。TEXT 类型适合用于存储长字符串。
-### 浮点数精度配置
+### 1.1 浮点数精度配置
对于 **FLOAT** 与 **DOUBLE** 类型的序列，如果编码方式采用 `RLE`或 `TS_2DIFF`，可以在创建序列时通过 `MAX_POINT_NUMBER` 属性指定浮点数的小数点后位数。
@@ -49,7 +49,7 @@ CREATE TIMESERIES root.vehicle.d0.s0 WITH DATATYPE=FLOAT, ENCODING=RLE, 'MAX_POI
若不指定，系统会按照配置文件 `iotdb-system.properties` 中的 [float_precision](../Reference/System-Config-Manual.md) 项配置（默认为 2 位）。
-### 数据类型兼容性
+### 1.2 数据类型兼容性
当写入数据的类型与序列注册的数据类型不一致时，
- 如果序列数据类型不兼容写入数据类型，系统会给出错误提示。
@@ -70,11 +70,11 @@ CREATE TIMESERIES root.vehicle.d0.s0 WITH DATATYPE=FLOAT, ENCODING=RLE, 'MAX_POI
| TIMESTAMP | INT32 INT64 TIMESTAMP |
| DATE | DATE |
-## 时间戳类型
+## 2 时间戳类型
时间戳是一个数据到来的时间点，其中包括绝对时间戳和相对时间戳。
-### 绝对时间戳
+### 2.1 绝对时间戳
IOTDB 中绝对时间戳分为二种，一种为 LONG 类型，一种为 DATETIME 类型（包含 DATETIME-INPUT, DATETIME-DISPLAY 两个小类）。
@@ -146,7 +146,7 @@ IoTDB 在显示时间戳时可以支持 LONG 类型以及 DATETIME-DISPLAY 类
-### 相对时间戳
+### 2.2 相对时间戳
相对时间是指与服务器时间```now()```和```DATETIME```类型时间相差一定时间间隔的时间。
形式化定义为：