diff --git a/src/.vuepress/sidebar/V1.3.0-2/en.ts b/src/.vuepress/sidebar/V1.3.0-2/en.ts index 8eb2eeaa9..290e3d672 100644 --- a/src/.vuepress/sidebar/V1.3.0-2/en.ts +++ b/src/.vuepress/sidebar/V1.3.0-2/en.ts @@ -51,6 +51,7 @@ export const enSidebar = { { text: 'Data Model', link: 'Data-Model-and-Terminology' }, { text: 'Data Type', link: 'Data-Type' }, { text: 'Encoding and Compression', link: 'Encoding-and-Compression' }, + { text: 'Cluster-related Concepts', link: 'Cluster-Concept' }, { text: 'Data Partitioning & Load Balancing', link: 'Cluster-data-partitioning' }, ], }, diff --git a/src/.vuepress/sidebar/V1.3.0-2/zh.ts b/src/.vuepress/sidebar/V1.3.0-2/zh.ts index fb604a437..f92c21ab3 100644 --- a/src/.vuepress/sidebar/V1.3.0-2/zh.ts +++ b/src/.vuepress/sidebar/V1.3.0-2/zh.ts @@ -51,6 +51,7 @@ export const zhSidebar = { { text: '数据模型', link: 'Data-Model-and-Terminology' }, { text: '数据类型', link: 'Data-Type' }, { text: '编码和压缩', link: 'Encoding-and-Compression' }, + { text: '集群相关概念', link: 'Cluster-Concept' }, { text: '数据分区与负载均衡', link: 'Cluster-data-partitioning' }, ], }, diff --git a/src/.vuepress/sidebar/V1.3.x/en.ts b/src/.vuepress/sidebar/V1.3.x/en.ts index be4b7b289..a2faea767 100644 --- a/src/.vuepress/sidebar/V1.3.x/en.ts +++ b/src/.vuepress/sidebar/V1.3.x/en.ts @@ -39,6 +39,7 @@ export const enSidebar = { prefix: 'Preparatory-knowledge/', children: [ { text: 'Data Type', link: 'Data-Type' }, + { text: 'Cluster-related Concepts', link: 'Cluster-Concept' }, ], }, { diff --git a/src/.vuepress/sidebar/V1.3.x/zh.ts b/src/.vuepress/sidebar/V1.3.x/zh.ts index 84f2ab313..6f6642bb4 100644 --- a/src/.vuepress/sidebar/V1.3.x/zh.ts +++ b/src/.vuepress/sidebar/V1.3.x/zh.ts @@ -39,6 +39,7 @@ export const zhSidebar = { prefix: 'Preparatory-knowledge/', children: [ { text: '数据类型', link: 'Data-Type' }, + { text: '集群相关概念', link: 'Cluster-Concept' }, ], }, { diff --git a/src/.vuepress/sidebar_timecho/V1.3.0-2/en.ts b/src/.vuepress/sidebar_timecho/V1.3.0-2/en.ts index 09d5d748f..947bb4421 100644 --- a/src/.vuepress/sidebar_timecho/V1.3.0-2/en.ts +++ b/src/.vuepress/sidebar_timecho/V1.3.0-2/en.ts @@ -51,6 +51,7 @@ export const enSidebar = { { text: 'Data Model', link: 'Data-Model-and-Terminology' }, { text: 'Data Type', link: 'Data-Type' }, { text: 'Encoding and Compression', link: 'Encoding-and-Compression' }, + { text: 'Cluster-related Concepts', link: 'Cluster-Concept' }, { text: 'Data Partitioning & Load Balancing', link: 'Cluster-data-partitioning' }, ], }, diff --git a/src/.vuepress/sidebar_timecho/V1.3.0-2/zh.ts b/src/.vuepress/sidebar_timecho/V1.3.0-2/zh.ts index 222f4e068..1a53de312 100644 --- a/src/.vuepress/sidebar_timecho/V1.3.0-2/zh.ts +++ b/src/.vuepress/sidebar_timecho/V1.3.0-2/zh.ts @@ -51,6 +51,7 @@ export const zhSidebar = { { text: '数据模型', link: 'Data-Model-and-Terminology' }, { text: '数据类型', link: 'Data-Type' }, { text: '编码和压缩', link: 'Encoding-and-Compression' }, + { text: '集群相关概念', link: 'Cluster-Concept' }, { text: '数据分区与负载均衡', link: 'Cluster-data-partitioning' }, ], }, diff --git a/src/.vuepress/sidebar_timecho/V1.3.x/en.ts b/src/.vuepress/sidebar_timecho/V1.3.x/en.ts index 253b4a38c..1b95f5b25 100644 --- a/src/.vuepress/sidebar_timecho/V1.3.x/en.ts +++ b/src/.vuepress/sidebar_timecho/V1.3.x/en.ts @@ -39,6 +39,7 @@ export const enSidebar = { prefix: 'Preparatory-knowledge/', children: [ { text: 'Data Type', link: 'Data-Type' }, + { text: 'Cluster-related Concepts', link: 'Cluster-Concept' }, ], }, { diff --git a/src/.vuepress/sidebar_timecho/V1.3.x/zh.ts b/src/.vuepress/sidebar_timecho/V1.3.x/zh.ts index f97f79c0f..bc914a89a 100644 --- a/src/.vuepress/sidebar_timecho/V1.3.x/zh.ts +++ b/src/.vuepress/sidebar_timecho/V1.3.x/zh.ts @@ -39,6 +39,7 @@ export const zhSidebar = { prefix: 'Preparatory-knowledge/', children: [ { text: '数据类型', link: 'Data-Type' }, + { text: '集群相关概念', link: 'Cluster-Concept' }, ], }, { diff --git a/src/UserGuide/Master/Tree/Preparatory-knowledge/Cluster-Concept.md b/src/UserGuide/Master/Tree/Preparatory-knowledge/Cluster-Concept.md new file mode 100644 index 000000000..42e47ffeb --- /dev/null +++ b/src/UserGuide/Master/Tree/Preparatory-knowledge/Cluster-Concept.md @@ -0,0 +1,59 @@ + + +# Cluster-related Concepts +The figure below illustrates a typical IoTDB 3C3D1A cluster deployment mode, comprising 3 ConfigNodes, 3 DataNodes, and 1 AINode: + + +This deployment involves several key concepts that users commonly encounter when working with IoTDB clusters, including: +- **Nodes** (ConfigNode, DataNode, AINode); +- **Slots** (SchemaSlot, DataSlot); +- **Regions** (SchemaRegion, DataRegion); +- **Replica Groups**. + +The following sections will provide a detailed introduction to these concepts. + +## Nodes + +An IoTDB cluster consists of three types of nodes (processes): **ConfigNode** (the main node), **DataNode**, and **AINode**, as detailed below: +- **ConfigNode:** ConfigNodes store cluster configurations, database metadata, the routing information of time series' schema and data. They also monitor cluster nodes and conduct load balancing. All ConfigNodes maintain full mutual backups, as shown in the figure with ConfigNode-1, ConfigNode-2, and ConfigNode-3. ConfigNodes do not directly handle client read or write requests. Instead, they guide the distribution of time series' schema and data within the cluster using a series of [load balancing algorithms](https://iotdb.apache.org/UserGuide/latest/Technical-Insider/Cluster-data-partitioning.html). +- **DataNode:** DataNodes are responsible for reading and writing time series' schema and data. Each DataNode can accept client read and write requests and provide corresponding services, as illustrated with DataNode-1, DataNode-2, and DataNode-3 in the above figure. When a DataNode receives client requests, it can process them directly or forward them if it has the relevant routing information cached locally. Otherwise, it queries the ConfigNode for routing details and caches the information to improve the efficiency of subsequent requests. +- **AINode:** AINodes interact with ConfigNodes and DataNodes to extend IoTDB's capabilities for data intelligence analysis on time series data. They support registering pre-trained machine learning models from external sources and performing time series analysis tasks using simple SQL statements on specified data. This process integrates model creation, management, and inference within the database engine. Currently, the system provides built-in algorithms or self-training models for common time series analysis scenarios, such as forecasting and anomaly detection. + +## Slots + +IoTDB divides time series' schema and data into smaller, more manageable units called **slots**. Slots are logical entities, and in an IoTDB cluster, the **SchemaSlots** and **DataSlots** are defined as follows: +- **SchemaSlot:** A SchemaSlot represents a subset of the time series' schema collection. The total number of SchemaSlots is fixed, with a default value of 1000. IoTDB uses a hashing algorithm to evenly distribute all devices across these SchemaSlots. +- **DataSlot:** A DataSlot represents a subset of the time series' data collection. Based on the SchemaSlots, the data for corresponding devices is further divided into DataSlots by a fixed time interval. The default time interval for a DataSlot is 7 days. + +## Region + +In IoTDB, time series' schema and data are replicated across DataNodes to ensure high availability in the cluster. However, replicating data at the slot level can increase management complexity and reduce write throughput. To address this, IoTDB introduces the concept of **Region**, which groups SchemaSlots and DataSlots into **SchemaRegions** and **DataRegions** respectively. Replication is then performed at the Region level. The definitions of SchemaRegion and DataRegion are as follows: +- **SchemaRegion**: A SchemaRegion is the basic unit for storing and replicating time series' schema. All SchemaSlots in a database are evenly distributed across the database's SchemaRegions. SchemaRegions with the same RegionID are replicas of each other. For example, in the figure above, SchemaRegion-1 has three replicas located on DataNode-1, DataNode-2, and DataNode-3. +- **DataRegion**: A DataRegion is the basic unit for storing and replicating time series' data. All DataSlots in a database are evenly distributed across the database's DataRegions. DataRegions with the same RegionID are replicas of each other. For instance, in the figure above, DataRegion-2 has two replicas located on DataNode-1 and DataNode-2. + +## Replica Groups +Region replicas are critical for the fault tolerance of the cluster. Each Region's replicas are organized into **replica groups**, where the replicas are assigned roles as either **leader** or **follower**, working together to provide read and write services. Recommended replica group configurations under different architectures are as follows: + +| Category | Parameter | Single-node Recommended Configuration | Distributed Recommended Configuration | +|:------------:|:-----------------------:|:------------------------------------:|:-------------------------------------:| +| Schema | `schema_replication_factor` | 1 | 3 | +| Data | `data_replication_factor` | 1 | 2 | \ No newline at end of file diff --git a/src/UserGuide/V1.3.0-2/Preparatory-knowledge/Cluster-Concept.md b/src/UserGuide/V1.3.0-2/Preparatory-knowledge/Cluster-Concept.md new file mode 100644 index 000000000..42e47ffeb --- /dev/null +++ b/src/UserGuide/V1.3.0-2/Preparatory-knowledge/Cluster-Concept.md @@ -0,0 +1,59 @@ + + +# Cluster-related Concepts +The figure below illustrates a typical IoTDB 3C3D1A cluster deployment mode, comprising 3 ConfigNodes, 3 DataNodes, and 1 AINode: + + +This deployment involves several key concepts that users commonly encounter when working with IoTDB clusters, including: +- **Nodes** (ConfigNode, DataNode, AINode); +- **Slots** (SchemaSlot, DataSlot); +- **Regions** (SchemaRegion, DataRegion); +- **Replica Groups**. + +The following sections will provide a detailed introduction to these concepts. + +## Nodes + +An IoTDB cluster consists of three types of nodes (processes): **ConfigNode** (the main node), **DataNode**, and **AINode**, as detailed below: +- **ConfigNode:** ConfigNodes store cluster configurations, database metadata, the routing information of time series' schema and data. They also monitor cluster nodes and conduct load balancing. All ConfigNodes maintain full mutual backups, as shown in the figure with ConfigNode-1, ConfigNode-2, and ConfigNode-3. ConfigNodes do not directly handle client read or write requests. Instead, they guide the distribution of time series' schema and data within the cluster using a series of [load balancing algorithms](https://iotdb.apache.org/UserGuide/latest/Technical-Insider/Cluster-data-partitioning.html). +- **DataNode:** DataNodes are responsible for reading and writing time series' schema and data. Each DataNode can accept client read and write requests and provide corresponding services, as illustrated with DataNode-1, DataNode-2, and DataNode-3 in the above figure. When a DataNode receives client requests, it can process them directly or forward them if it has the relevant routing information cached locally. Otherwise, it queries the ConfigNode for routing details and caches the information to improve the efficiency of subsequent requests. +- **AINode:** AINodes interact with ConfigNodes and DataNodes to extend IoTDB's capabilities for data intelligence analysis on time series data. They support registering pre-trained machine learning models from external sources and performing time series analysis tasks using simple SQL statements on specified data. This process integrates model creation, management, and inference within the database engine. Currently, the system provides built-in algorithms or self-training models for common time series analysis scenarios, such as forecasting and anomaly detection. + +## Slots + +IoTDB divides time series' schema and data into smaller, more manageable units called **slots**. Slots are logical entities, and in an IoTDB cluster, the **SchemaSlots** and **DataSlots** are defined as follows: +- **SchemaSlot:** A SchemaSlot represents a subset of the time series' schema collection. The total number of SchemaSlots is fixed, with a default value of 1000. IoTDB uses a hashing algorithm to evenly distribute all devices across these SchemaSlots. +- **DataSlot:** A DataSlot represents a subset of the time series' data collection. Based on the SchemaSlots, the data for corresponding devices is further divided into DataSlots by a fixed time interval. The default time interval for a DataSlot is 7 days. + +## Region + +In IoTDB, time series' schema and data are replicated across DataNodes to ensure high availability in the cluster. However, replicating data at the slot level can increase management complexity and reduce write throughput. To address this, IoTDB introduces the concept of **Region**, which groups SchemaSlots and DataSlots into **SchemaRegions** and **DataRegions** respectively. Replication is then performed at the Region level. The definitions of SchemaRegion and DataRegion are as follows: +- **SchemaRegion**: A SchemaRegion is the basic unit for storing and replicating time series' schema. All SchemaSlots in a database are evenly distributed across the database's SchemaRegions. SchemaRegions with the same RegionID are replicas of each other. For example, in the figure above, SchemaRegion-1 has three replicas located on DataNode-1, DataNode-2, and DataNode-3. +- **DataRegion**: A DataRegion is the basic unit for storing and replicating time series' data. All DataSlots in a database are evenly distributed across the database's DataRegions. DataRegions with the same RegionID are replicas of each other. For instance, in the figure above, DataRegion-2 has two replicas located on DataNode-1 and DataNode-2. + +## Replica Groups +Region replicas are critical for the fault tolerance of the cluster. Each Region's replicas are organized into **replica groups**, where the replicas are assigned roles as either **leader** or **follower**, working together to provide read and write services. Recommended replica group configurations under different architectures are as follows: + +| Category | Parameter | Single-node Recommended Configuration | Distributed Recommended Configuration | +|:------------:|:-----------------------:|:------------------------------------:|:-------------------------------------:| +| Schema | `schema_replication_factor` | 1 | 3 | +| Data | `data_replication_factor` | 1 | 2 | \ No newline at end of file diff --git a/src/UserGuide/latest/Preparatory-knowledge/Cluster-Concept.md b/src/UserGuide/latest/Preparatory-knowledge/Cluster-Concept.md new file mode 100644 index 000000000..42e47ffeb --- /dev/null +++ b/src/UserGuide/latest/Preparatory-knowledge/Cluster-Concept.md @@ -0,0 +1,59 @@ + + +# Cluster-related Concepts +The figure below illustrates a typical IoTDB 3C3D1A cluster deployment mode, comprising 3 ConfigNodes, 3 DataNodes, and 1 AINode: + + +This deployment involves several key concepts that users commonly encounter when working with IoTDB clusters, including: +- **Nodes** (ConfigNode, DataNode, AINode); +- **Slots** (SchemaSlot, DataSlot); +- **Regions** (SchemaRegion, DataRegion); +- **Replica Groups**. + +The following sections will provide a detailed introduction to these concepts. + +## Nodes + +An IoTDB cluster consists of three types of nodes (processes): **ConfigNode** (the main node), **DataNode**, and **AINode**, as detailed below: +- **ConfigNode:** ConfigNodes store cluster configurations, database metadata, the routing information of time series' schema and data. They also monitor cluster nodes and conduct load balancing. All ConfigNodes maintain full mutual backups, as shown in the figure with ConfigNode-1, ConfigNode-2, and ConfigNode-3. ConfigNodes do not directly handle client read or write requests. Instead, they guide the distribution of time series' schema and data within the cluster using a series of [load balancing algorithms](https://iotdb.apache.org/UserGuide/latest/Technical-Insider/Cluster-data-partitioning.html). +- **DataNode:** DataNodes are responsible for reading and writing time series' schema and data. Each DataNode can accept client read and write requests and provide corresponding services, as illustrated with DataNode-1, DataNode-2, and DataNode-3 in the above figure. When a DataNode receives client requests, it can process them directly or forward them if it has the relevant routing information cached locally. Otherwise, it queries the ConfigNode for routing details and caches the information to improve the efficiency of subsequent requests. +- **AINode:** AINodes interact with ConfigNodes and DataNodes to extend IoTDB's capabilities for data intelligence analysis on time series data. They support registering pre-trained machine learning models from external sources and performing time series analysis tasks using simple SQL statements on specified data. This process integrates model creation, management, and inference within the database engine. Currently, the system provides built-in algorithms or self-training models for common time series analysis scenarios, such as forecasting and anomaly detection. + +## Slots + +IoTDB divides time series' schema and data into smaller, more manageable units called **slots**. Slots are logical entities, and in an IoTDB cluster, the **SchemaSlots** and **DataSlots** are defined as follows: +- **SchemaSlot:** A SchemaSlot represents a subset of the time series' schema collection. The total number of SchemaSlots is fixed, with a default value of 1000. IoTDB uses a hashing algorithm to evenly distribute all devices across these SchemaSlots. +- **DataSlot:** A DataSlot represents a subset of the time series' data collection. Based on the SchemaSlots, the data for corresponding devices is further divided into DataSlots by a fixed time interval. The default time interval for a DataSlot is 7 days. + +## Region + +In IoTDB, time series' schema and data are replicated across DataNodes to ensure high availability in the cluster. However, replicating data at the slot level can increase management complexity and reduce write throughput. To address this, IoTDB introduces the concept of **Region**, which groups SchemaSlots and DataSlots into **SchemaRegions** and **DataRegions** respectively. Replication is then performed at the Region level. The definitions of SchemaRegion and DataRegion are as follows: +- **SchemaRegion**: A SchemaRegion is the basic unit for storing and replicating time series' schema. All SchemaSlots in a database are evenly distributed across the database's SchemaRegions. SchemaRegions with the same RegionID are replicas of each other. For example, in the figure above, SchemaRegion-1 has three replicas located on DataNode-1, DataNode-2, and DataNode-3. +- **DataRegion**: A DataRegion is the basic unit for storing and replicating time series' data. All DataSlots in a database are evenly distributed across the database's DataRegions. DataRegions with the same RegionID are replicas of each other. For instance, in the figure above, DataRegion-2 has two replicas located on DataNode-1 and DataNode-2. + +## Replica Groups +Region replicas are critical for the fault tolerance of the cluster. Each Region's replicas are organized into **replica groups**, where the replicas are assigned roles as either **leader** or **follower**, working together to provide read and write services. Recommended replica group configurations under different architectures are as follows: + +| Category | Parameter | Single-node Recommended Configuration | Distributed Recommended Configuration | +|:------------:|:-----------------------:|:------------------------------------:|:-------------------------------------:| +| Schema | `schema_replication_factor` | 1 | 3 | +| Data | `data_replication_factor` | 1 | 2 | \ No newline at end of file diff --git a/src/zh/UserGuide/Master/Tree/Preparatory-knowledge/Cluster-Concept.md b/src/zh/UserGuide/Master/Tree/Preparatory-knowledge/Cluster-Concept.md new file mode 100644 index 000000000..fa6019036 --- /dev/null +++ b/src/zh/UserGuide/Master/Tree/Preparatory-knowledge/Cluster-Concept.md @@ -0,0 +1,55 @@ + + +# 集群相关概念 +下图展示了一个常见的 IoTDB 3C3D1A（3 个 ConfigNode、3 个 DataNode 和 1 个 AINode）的集群部署模式： + + +其中包括了 IoTDB 集群使用中用户常接触到的几个概念，包括： +- **节点**（ConfigNode、DataNode、AINode）； +- **槽**（SchemaSlot、DataSlot）； +- **Region**（SchemaRegion、DataRegion）； +- ***副本组***。 + +下文将重点对以上概念进行介绍。 + +## 节点 +IoTDB 集群包括三种节点（进程），**ConfigNode**（管理节点），**DataNode**（数据节点）和 **AINode**（分析节点），如下所示： +- **ConfigNode**：存储集群的配置信息、数据库的元数据、时间序列元数据和数据的路由信息，监控集群节点并实施负载均衡，所有 ConfigNode 之间互为全量备份，如上图中的 ConfigNode-1，ConfigNode-2 和 ConfigNode-3 所示。ConfigNode 不直接接收客户端读写请求，它会通过一系列[负载均衡算法](https://iotdb.apache.org/zh/UserGuide/latest/Technical-Insider/Cluster-data-partitioning.html)对集群中元数据和数据的分布提供指导。 +- **DataNode**：负责时间序列元数据和数据的读写，每个 DataNode 都能接收客户端读写请求并提供相应服务，如上图中的 DataNode-1，DataNode-2 和 DataNode-3 所示。接收客户端读写请求时，若 DataNode 缓存有对应的路由信息，它能直接在本地执行或是转发这些请求；否则它会向 ConfigNode 询问并缓存路由信息，以加速后续请求的服务效率。 +- **AINode**：负责与 ConfigNode 和 DataNode 交互来扩展 IoTDB 集群对时间序列进行智能分析的能力，支持从外部引入已有机器学习模型进行注册，并使用注册的模型在指定时序数据上通过简单 SQL 语句完成时序分析任务的过程，将模型的创建、管理及推理融合在数据库引擎中。目前已提供常见时序分析场景（例如预测与异常检测）的机器学习算法或自研模型。 + +## 槽 +IoTDB 内部将元数据和数据划分成多个更小的、更易于管理的单元，每个单元称为一个**槽**。槽是一个逻辑概念，在 IoTDB 集群中，**元数据槽**和**数据槽**定义如下： +- **元数据槽**（SchemaSlot）：一部分元数据集合，元数据槽总数固定，默认数量为 1000，IoTDB 使用哈希算法将所有设备均匀地分配到这些元数据槽中。 +- **数据槽**（DataSlot）：一部分数据集合，在元数据槽的基础上，将对应设备的数据按时间范围划分为数据槽，默认的时间范围为 7 天。 + +## Region +在 IoTDB 中，元数据和数据被复制到各个 DataNode 以获得集群高可用性。然而以槽为粒度进行复制会增加集群管理成本、降低写入吞吐。因此 IoTDB 引入 **Region** 这一概念，将元数据槽和数据槽分别分配给 SchemaRegion 和 DataRegion 后，以 Region 为单位进行复制。**SchemRegion** 和 **DataRegion** 的详细定义如下： +- **SchemaRegion**：元数据存储和复制的基本单元，集群每个数据库的所有元数据槽会被均匀分配给该数据库的所有 SchemaRegion。拥有相同 RegionID 的 SchemaRegion 互为副本，如上图中 SchemaRegion-1 拥有三个副本，分别放置于 DataNode-1，DataNode-2 和 DataNode-3。 +- **DataRegion**：数据存储和复制的基本单元，集群每个数据库的所有数据槽会被均匀分配给该数据库的所有 DataRegion。拥有相同 RegionID 的 DataRegion 互为副本，如上图中 DataRegion-2 拥有两个副本，分别放置于 DataNode-1 和 DataNode-2。 + +## 副本组 +Region 的副本对集群的容灾能力至关重要。对于每个 Region 的所有副本，它们的角色分为 **leader** 和 **follower**，共同提供读写服务。不同架构下的副本组配置推荐如下： +| 类别 | 配置项 | 单机推荐配置 | 分布式推荐配置 | +| :-: | :-: | :-: | :-: | +| 元数据 | schema_replication_factor | 1 | 3 | +| 数据 | data_replication_factor | 1 | 2 | \ No newline at end of file diff --git a/src/zh/UserGuide/V1.3.0-2/Preparatory-knowledge/Cluster-Concept.md b/src/zh/UserGuide/V1.3.0-2/Preparatory-knowledge/Cluster-Concept.md new file mode 100644 index 000000000..fa6019036 --- /dev/null +++ b/src/zh/UserGuide/V1.3.0-2/Preparatory-knowledge/Cluster-Concept.md @@ -0,0 +1,55 @@ + + +# 集群相关概念 +下图展示了一个常见的 IoTDB 3C3D1A（3 个 ConfigNode、3 个 DataNode 和 1 个 AINode）的集群部署模式： + + +其中包括了 IoTDB 集群使用中用户常接触到的几个概念，包括： +- **节点**（ConfigNode、DataNode、AINode）； +- **槽**（SchemaSlot、DataSlot）； +- **Region**（SchemaRegion、DataRegion）； +- ***副本组***。 + +下文将重点对以上概念进行介绍。 + +## 节点 +IoTDB 集群包括三种节点（进程），**ConfigNode**（管理节点），**DataNode**（数据节点）和 **AINode**（分析节点），如下所示： +- **ConfigNode**：存储集群的配置信息、数据库的元数据、时间序列元数据和数据的路由信息，监控集群节点并实施负载均衡，所有 ConfigNode 之间互为全量备份，如上图中的 ConfigNode-1，ConfigNode-2 和 ConfigNode-3 所示。ConfigNode 不直接接收客户端读写请求，它会通过一系列[负载均衡算法](https://iotdb.apache.org/zh/UserGuide/latest/Technical-Insider/Cluster-data-partitioning.html)对集群中元数据和数据的分布提供指导。 +- **DataNode**：负责时间序列元数据和数据的读写，每个 DataNode 都能接收客户端读写请求并提供相应服务，如上图中的 DataNode-1，DataNode-2 和 DataNode-3 所示。接收客户端读写请求时，若 DataNode 缓存有对应的路由信息，它能直接在本地执行或是转发这些请求；否则它会向 ConfigNode 询问并缓存路由信息，以加速后续请求的服务效率。 +- **AINode**：负责与 ConfigNode 和 DataNode 交互来扩展 IoTDB 集群对时间序列进行智能分析的能力，支持从外部引入已有机器学习模型进行注册，并使用注册的模型在指定时序数据上通过简单 SQL 语句完成时序分析任务的过程，将模型的创建、管理及推理融合在数据库引擎中。目前已提供常见时序分析场景（例如预测与异常检测）的机器学习算法或自研模型。 + +## 槽 +IoTDB 内部将元数据和数据划分成多个更小的、更易于管理的单元，每个单元称为一个**槽**。槽是一个逻辑概念，在 IoTDB 集群中，**元数据槽**和**数据槽**定义如下： +- **元数据槽**（SchemaSlot）：一部分元数据集合，元数据槽总数固定，默认数量为 1000，IoTDB 使用哈希算法将所有设备均匀地分配到这些元数据槽中。 +- **数据槽**（DataSlot）：一部分数据集合，在元数据槽的基础上，将对应设备的数据按时间范围划分为数据槽，默认的时间范围为 7 天。 + +## Region +在 IoTDB 中，元数据和数据被复制到各个 DataNode 以获得集群高可用性。然而以槽为粒度进行复制会增加集群管理成本、降低写入吞吐。因此 IoTDB 引入 **Region** 这一概念，将元数据槽和数据槽分别分配给 SchemaRegion 和 DataRegion 后，以 Region 为单位进行复制。**SchemRegion** 和 **DataRegion** 的详细定义如下： +- **SchemaRegion**：元数据存储和复制的基本单元，集群每个数据库的所有元数据槽会被均匀分配给该数据库的所有 SchemaRegion。拥有相同 RegionID 的 SchemaRegion 互为副本，如上图中 SchemaRegion-1 拥有三个副本，分别放置于 DataNode-1，DataNode-2 和 DataNode-3。 +- **DataRegion**：数据存储和复制的基本单元，集群每个数据库的所有数据槽会被均匀分配给该数据库的所有 DataRegion。拥有相同 RegionID 的 DataRegion 互为副本，如上图中 DataRegion-2 拥有两个副本，分别放置于 DataNode-1 和 DataNode-2。 + +## 副本组 +Region 的副本对集群的容灾能力至关重要。对于每个 Region 的所有副本，它们的角色分为 **leader** 和 **follower**，共同提供读写服务。不同架构下的副本组配置推荐如下： +| 类别 | 配置项 | 单机推荐配置 | 分布式推荐配置 | +| :-: | :-: | :-: | :-: | +| 元数据 | schema_replication_factor | 1 | 3 | +| 数据 | data_replication_factor | 1 | 2 | \ No newline at end of file diff --git a/src/zh/UserGuide/latest/Preparatory-knowledge/Cluster-Concept.md b/src/zh/UserGuide/latest/Preparatory-knowledge/Cluster-Concept.md new file mode 100644 index 000000000..fa6019036 --- /dev/null +++ b/src/zh/UserGuide/latest/Preparatory-knowledge/Cluster-Concept.md @@ -0,0 +1,55 @@ + + +# 集群相关概念 +下图展示了一个常见的 IoTDB 3C3D1A（3 个 ConfigNode、3 个 DataNode 和 1 个 AINode）的集群部署模式： + + +其中包括了 IoTDB 集群使用中用户常接触到的几个概念，包括： +- **节点**（ConfigNode、DataNode、AINode）； +- **槽**（SchemaSlot、DataSlot）； +- **Region**（SchemaRegion、DataRegion）； +- ***副本组***。 + +下文将重点对以上概念进行介绍。 + +## 节点 +IoTDB 集群包括三种节点（进程），**ConfigNode**（管理节点），**DataNode**（数据节点）和 **AINode**（分析节点），如下所示： +- **ConfigNode**：存储集群的配置信息、数据库的元数据、时间序列元数据和数据的路由信息，监控集群节点并实施负载均衡，所有 ConfigNode 之间互为全量备份，如上图中的 ConfigNode-1，ConfigNode-2 和 ConfigNode-3 所示。ConfigNode 不直接接收客户端读写请求，它会通过一系列[负载均衡算法](https://iotdb.apache.org/zh/UserGuide/latest/Technical-Insider/Cluster-data-partitioning.html)对集群中元数据和数据的分布提供指导。 +- **DataNode**：负责时间序列元数据和数据的读写，每个 DataNode 都能接收客户端读写请求并提供相应服务，如上图中的 DataNode-1，DataNode-2 和 DataNode-3 所示。接收客户端读写请求时，若 DataNode 缓存有对应的路由信息，它能直接在本地执行或是转发这些请求；否则它会向 ConfigNode 询问并缓存路由信息，以加速后续请求的服务效率。 +- **AINode**：负责与 ConfigNode 和 DataNode 交互来扩展 IoTDB 集群对时间序列进行智能分析的能力，支持从外部引入已有机器学习模型进行注册，并使用注册的模型在指定时序数据上通过简单 SQL 语句完成时序分析任务的过程，将模型的创建、管理及推理融合在数据库引擎中。目前已提供常见时序分析场景（例如预测与异常检测）的机器学习算法或自研模型。 + +## 槽 +IoTDB 内部将元数据和数据划分成多个更小的、更易于管理的单元，每个单元称为一个**槽**。槽是一个逻辑概念，在 IoTDB 集群中，**元数据槽**和**数据槽**定义如下： +- **元数据槽**（SchemaSlot）：一部分元数据集合，元数据槽总数固定，默认数量为 1000，IoTDB 使用哈希算法将所有设备均匀地分配到这些元数据槽中。 +- **数据槽**（DataSlot）：一部分数据集合，在元数据槽的基础上，将对应设备的数据按时间范围划分为数据槽，默认的时间范围为 7 天。 + +## Region +在 IoTDB 中，元数据和数据被复制到各个 DataNode 以获得集群高可用性。然而以槽为粒度进行复制会增加集群管理成本、降低写入吞吐。因此 IoTDB 引入 **Region** 这一概念，将元数据槽和数据槽分别分配给 SchemaRegion 和 DataRegion 后，以 Region 为单位进行复制。**SchemRegion** 和 **DataRegion** 的详细定义如下： +- **SchemaRegion**：元数据存储和复制的基本单元，集群每个数据库的所有元数据槽会被均匀分配给该数据库的所有 SchemaRegion。拥有相同 RegionID 的 SchemaRegion 互为副本，如上图中 SchemaRegion-1 拥有三个副本，分别放置于 DataNode-1，DataNode-2 和 DataNode-3。 +- **DataRegion**：数据存储和复制的基本单元，集群每个数据库的所有数据槽会被均匀分配给该数据库的所有 DataRegion。拥有相同 RegionID 的 DataRegion 互为副本，如上图中 DataRegion-2 拥有两个副本，分别放置于 DataNode-1 和 DataNode-2。 + +## 副本组 +Region 的副本对集群的容灾能力至关重要。对于每个 Region 的所有副本，它们的角色分为 **leader** 和 **follower**，共同提供读写服务。不同架构下的副本组配置推荐如下： +| 类别 | 配置项 | 单机推荐配置 | 分布式推荐配置 | +| :-: | :-: | :-: | :-: | +| 元数据 | schema_replication_factor | 1 | 3 | +| 数据 | data_replication_factor | 1 | 2 | \ No newline at end of file