This is an automated email from the ASF dual-hosted git repository. yongzao pushed a commit to branch cluster_partition_update in repository https://gitbox.apache.org/repos/asf/iotdb-docs.git
commit 88d95b230e45472a39b7401d9e5c0c8c6ae5e2b5 Author: YongzaoDan <[email protected]> AuthorDate: Thu Oct 3 03:21:08 2024 +0800 Finish --- .../Basic-Concept/Cluster-data-partitioning.md | 89 +++++++++++++++++----- .../Basic-Concept/Cluster-data-partitioning.md | 89 +++++++++++++++++----- .../Basic-Concept/Cluster-data-partitioning.md | 87 ++++++++++++++++----- .../Basic-Concept/Cluster-data-partitioning.md | 87 ++++++++++++++++----- 4 files changed, 274 insertions(+), 78 deletions(-) diff --git a/src/UserGuide/Master/Basic-Concept/Cluster-data-partitioning.md b/src/UserGuide/Master/Basic-Concept/Cluster-data-partitioning.md index 030f86e..4804d28 100644 --- a/src/UserGuide/Master/Basic-Concept/Cluster-data-partitioning.md +++ b/src/UserGuide/Master/Basic-Concept/Cluster-data-partitioning.md @@ -19,42 +19,91 @@ --> -# Data Partitioning & Load Balancing +# Partitioning & Load Balance +This document introduces the partitioning strategies and load balance algorithms in IoTDB. According to the characteristics of time series data, IoTDB partitions them by series and time dimensions. Combining a series partition with a time partition creates a partition, the unit of division. To enhance throughput and reduce management costs, these partitions are evenly allocated to RegionGroups, which serve as the unit of replication. The RegionGroup's Regions then determine the storage l [...] -IoTDB manages metadata and data based on data partitions (DataRegion), dividing the data from both the sequence and time dimensions. +## Partitioning Strategy & Partition Allocation +IoTDB implements tailored partitioning operators for time series data. Building on this foundation, the partition information cached on both ConfigNodes and DataNodes is not only manageable in size but also clearly differentiated between hot and cold. Subsequently, balanced partitions are evenly allocated across the cluster's RegionGroups to achieve storage balance. -<img style="width:100%; max-width:800px; max-height:600px; margin-left:auto; margin-right:auto; display:block;" src="https://alioss.timecho.com/upload/data-region.jpg";> +### Partitioning Strategy +IoTDB maps each sensor in the production environment to a time series. The time series are then partitioned using the series partitioning operator to manage their schema, and combined with the time partitioning operator to manage their data. The following figure illustrates how IoTDB partitions time series data. -## Partition Slots +<img style="width:100%; max-width:800px; max-height:600px; margin-left:auto; margin-right:auto; display:block;" src="https://alioss.timecho.com/docs/img/partition_table_en.png?raw=true";> -A sequence partition slot combined with a time partition slot can generate a data partition (when the sequence slot has corresponding data under that time slot). +#### Partitioning Operator +Because numerous devices and sensors are commonly deployed in production environments, IoTDB employs the series partitioning operator to ensure the size of partition information is manageable. Since the generated time series associated with timestamps, IoTDB uses the time partioning operator to clearly distinguish between hot and cold partitions. -<img style="width:100%; max-width:800px; max-height:600px; margin-left:auto; margin-right:auto; display:block;" src="https://alioss.timecho.com/docs/img/SeriesPartitionSlot.png?raw=true";> +##### Series Partitioning Operator +By default, IoTDB limits the number of series partitions to 1000 and configures the series partitioning operator to use a hash partitioning strategy. This leads to the following outcomes: ++ Since the number of series partitions is a fixed constant, the mapping between series and series partitions remains stable. As a result, IoTDB does not require frequent data migrations. ++ The load across series partitions is relatively balanced because the number of series partitions is much smaller than the number of sensors deployed in the production environment. -### Sequence Partition Slots +Furthermore, if a more accurate estimate of the actual load in the production environment is available, the series partitioning operator can be configured to use a customized hash partitioning strategy or a list partitioning strategy to achieve a more uniform load distribution across all series partitions. -Each database holds a fixed number of sequence partition slots, with the default set to 1000. Every time series managed by the database is allocated to a unique sequence partition slot using a partitioning algorithm (usually some hash method). +##### Time Partitioning Operator +The time partitioning operator converts a given timestamp to the corresponding time partition by: +$$\left\lfloor\frac{\text{timestamp}-\text{start\_timestamp}}{\text{time\_partition\_interval}}\right\rfloor.$$ -### Time Partition Slots +In this equation, both $\text{start\_timestamp}$ and $\text{time\_partition\_interval}$ are configurable parameters to accommodate various production environments. The $\text{start\_timestamp}$ represents the starting time of the first time partition, while the $\text{time\_partition\_interval}$ defines the duration of each time partition. By default, the $\text{time\_partition\_interval}$ is set to one day. -Every time series will continuously produce data. If all the data from a time series is stored on one node continuously, the newly added DataNode in the cluster might not be effectively utilized. +#### Schema Partitioning +Since the series partitioning operator evenly partitions the time series, each series partition corresponds to a schema partition. These schema partitions are then evenly allocated across the SchemaRegionGroups to achieve a balanced schema distribution. -Time partition slots slice the time-series data from the time dimension (typically, one time partition per day), making the time-series data storage in the cluster easy to manage. +#### Data Partitioning +Combining a series partition with a time partition creates a data partition. Since the series partitioning operator evenly partitions the time series, the load of data partitions within a specified time partition remains balanced. These data partitions are then evenly allocated across the DataRegionGroups to achieve balanced data distribution. -## Metadata Partitioning +### Partition Allocation +IoTDB uses RegionGroups to enable elastic storage of time series, with the number of RegionGroups in the cluster determined by the total resources available across all DataNodes. Since the number of RegionGroups is dynamic, IoTDB can easily scale out. Both the SchemaRegionGroup and DataRegionGroup follow the same partition allocation strategy, which evenly splits all series partitions. The following figure demonstrates the partition allocation process, where the dynamic RegionGroups matc [...] -The metadata partition management of a single database, following a specific load balancing strategy, assigns all sequence slots to the corresponding SchemaRegionGroup, further horizontally scaling within the cluster. +<img style="width:100%; max-width:800px; max-height:600px; margin-left:auto; margin-right:auto; display:block;" src="https://alioss.timecho.com/docs/img/partition_allocation.png?raw=true";> -<img style="width:100%; max-width:800px; max-height:600px; margin-left:auto; margin-right:auto; display:block;" src="https://alioss.timecho.com/docs/img/SchemaRegion.png?raw=true";> +#### RegionGroup Expansion +The number of RegionGroups is given by -## Data Partitioning +$$\text{RegionGroup\_number}=\left\lfloor\frac{\sum_{i=1}^{DataNode\_number}\text{Region\_number}_i}{\text{replication\_factor}}\right\rfloor.$$ -It follows a certain load balancing strategy, dividing time and sequence partition slots, and allocating them to the relevant DataRegionGroup, further allowing horizontal scaling in the cluster. +In this equation, $\text{Region\_number}_i$ represents the number of Regions expected to be hosted on the $i$-th DataNode, while $\text{replication\_factor}$ denotes the number of Regions within each RegionGroup. Both $\text{Region\_number}_i$ and $\text{replication\_factor}$ are configurable parameters. The $\text{Region\_number}_i$ can be determined by the available hardware resources---such as CPU cores, memory sizes, etc.---on the $i$-th DataNode to accommodate different physical ser [...] -<img style="width:100%; max-width:800px; max-height:600px; margin-left:auto; margin-right:auto; display:block;" src="https://alioss.timecho.com/docs/img/DataRegion.png?raw=true";> +#### Allocation Strategy +Both the SchemaRegionGroup and the DataRegionGroup follow the same allocation strategy—-splitting all series partitions evenly. As a result, each SchemaRegionGroup holds the same number of schema partitions, ensuring balanced schema storage. Similarly, for each time partition, each DataRegionGroup acquires the data partitions corresponding to the series partitions it holds. Consequently, the data partitions within a time partition are evenly distributed across all DataRegionGroups, ensur [...] -## Load Balancing +Notably, IoTDB effectively leverages the characteristics of time series data. When the TTL (Time to Live) is configured, IoTDB enables migration-free elastic storage for time series data. This feature facilitates cluster expansion while minimizing the impact on online operations. The figures above illustrate an instance of this feature: newborn data partitions are evenly allocated to each DataRegion, and expired data are automatically archived. As a result, the cluster's storage will eve [...] -When the cluster's capacity remains unchanged, data will be evenly distributed across all nodes to utilize storage and computational resources effectively. +## Load Balance +To enhance the cluster's availability and performance, IoTDB employs sophisticated Region placement and leader selection algorithms. -Also, during cluster expansion, the system automatically increases the number of regions to fully exploit the computational resources of all nodes without manual intervention. Such dynamic expansion enhances the cluster's performance and scalability, making the system more flexible and efficient. \ No newline at end of file +### Region Placement +The number of Regions held by a DataNode reflects its storage load. If the difference in the number of Regions across DataNodes is relatively large, the DataNode with more Regions is likely to become a storage bottleneck. Although a straightforward Round Robin placement algorithm can achieve storage balance by ensuring that each DataNode hosts an equal number of Regions, it compromises the cluster's fault tolerance, as illustrated below: + +<img style="width:100%; max-width:800px; max-height:600px; margin-left:auto; margin-right:auto; display:block;" src="https://alioss.timecho.com/docs/img/placement.png?raw=true";> + ++ Assume the cluster has 4 DataNodes, 4 RegionGroups and a replication factor of 2. ++ Place RegionGroup $r_1$'s 2 Regions on DataNodes $n_1$ and $n_2$. ++ Place RegionGroup $r_2$'s 2 Regions on DataNodes $n_3$ and $n_4$. ++ Place RegionGroup $r_3$'s 2 Regions on DataNodes $n_1$ and $n_3$. ++ Place RegionGroup $r_4$'s 2 Regions on DataNodes $n_2$ and $n_4$. + +In this scenario, if DataNode $n_2$ fails, the load previously handled by DataNode $n_2$ would be transferred solely to DataNode $n_1$, potentially overloading it. + +To address this issue, IoTDB employs a Region placement algorithm that not only evenly distributes Regions across all DataNodes but also ensures that each DataNode can offload its storage to sufficient other DataNodes in the event of a failure. As a result, the cluster achieves balanced storage distribution and a high level of fault tolerance, ensuring its availability. + +### Leader Selection +The number of leader Regions held by a DataNode reflects its computational load. If the difference in the number of leaders across DataNodes is relatively large, the DataNode with more leaders is likely to become a computational bottleneck. If the leader selection process is conducted using a transparent Greedy algorithm, the result may be an unbalanced leader distribution when the Regions are fault-tolerantly placed, as demonstrated below: + +<img style="width:100%; max-width:800px; max-height:600px; margin-left:auto; margin-right:auto; display:block;" src="https://alioss.timecho.com/docs/img/selection.png?raw=true";> + ++ Assume the cluster has 4 DataNodes, 4 RegionGroups and a replication factor of 2. ++ Select RegionGroup $r_5$'s Region on DataNode $n_5$ as the leader. ++ Select RegionGroup $r_6$'s Region on DataNode $n_7$ as the leader. ++ Select RegionGroup $r_7$'s Region on DataNode $n_7$ as the leader. ++ Select RegionGroup $r_8$'s Region on DataNode $n_8$ as the leader. + +Please note that all the above steps strictly follow the Greedy algorithm. However, by Step 3, selecting the leader of RegionGroup $r_7$ on either DataNode $n_5$ or $n_7$ results in an unbalanced leader distribution. The rationale is that each greedy step lacks a global perspective, leading to a locally optimal solution. + +To address this issue, IoTDB employs a leader selection algorithm that can consistently balance the cluster's leader distribution. Consequently, the cluster achieves balanced computational load distribution, ensuring its performance. + +## Source Code ++ [Data Partitioning](https://github.com/apache/iotdb/tree/master/iotdb-core/node-commons/src/main/java/org/apache/iotdb/commons/partition) ++ [Partition Allocation](https://github.com/apache/iotdb/tree/master/iotdb-core/confignode/src/main/java/org/apache/iotdb/confignode/manager/load/balancer/partition) ++ [Region Placement](https://github.com/apache/iotdb/tree/master/iotdb-core/confignode/src/main/java/org/apache/iotdb/confignode/manager/load/balancer/region) ++ [Leader Selection](https://github.com/apache/iotdb/tree/master/iotdb-core/confignode/src/main/java/org/apache/iotdb/confignode/manager/load/balancer/router/leader) \ No newline at end of file diff --git a/src/UserGuide/latest/Basic-Concept/Cluster-data-partitioning.md b/src/UserGuide/latest/Basic-Concept/Cluster-data-partitioning.md index 030f86e..4804d28 100644 --- a/src/UserGuide/latest/Basic-Concept/Cluster-data-partitioning.md +++ b/src/UserGuide/latest/Basic-Concept/Cluster-data-partitioning.md @@ -19,42 +19,91 @@ --> -# Data Partitioning & Load Balancing +# Partitioning & Load Balance +This document introduces the partitioning strategies and load balance algorithms in IoTDB. According to the characteristics of time series data, IoTDB partitions them by series and time dimensions. Combining a series partition with a time partition creates a partition, the unit of division. To enhance throughput and reduce management costs, these partitions are evenly allocated to RegionGroups, which serve as the unit of replication. The RegionGroup's Regions then determine the storage l [...] -IoTDB manages metadata and data based on data partitions (DataRegion), dividing the data from both the sequence and time dimensions. +## Partitioning Strategy & Partition Allocation +IoTDB implements tailored partitioning operators for time series data. Building on this foundation, the partition information cached on both ConfigNodes and DataNodes is not only manageable in size but also clearly differentiated between hot and cold. Subsequently, balanced partitions are evenly allocated across the cluster's RegionGroups to achieve storage balance. -<img style="width:100%; max-width:800px; max-height:600px; margin-left:auto; margin-right:auto; display:block;" src="https://alioss.timecho.com/upload/data-region.jpg";> +### Partitioning Strategy +IoTDB maps each sensor in the production environment to a time series. The time series are then partitioned using the series partitioning operator to manage their schema, and combined with the time partitioning operator to manage their data. The following figure illustrates how IoTDB partitions time series data. -## Partition Slots +<img style="width:100%; max-width:800px; max-height:600px; margin-left:auto; margin-right:auto; display:block;" src="https://alioss.timecho.com/docs/img/partition_table_en.png?raw=true";> -A sequence partition slot combined with a time partition slot can generate a data partition (when the sequence slot has corresponding data under that time slot). +#### Partitioning Operator +Because numerous devices and sensors are commonly deployed in production environments, IoTDB employs the series partitioning operator to ensure the size of partition information is manageable. Since the generated time series associated with timestamps, IoTDB uses the time partioning operator to clearly distinguish between hot and cold partitions. -<img style="width:100%; max-width:800px; max-height:600px; margin-left:auto; margin-right:auto; display:block;" src="https://alioss.timecho.com/docs/img/SeriesPartitionSlot.png?raw=true";> +##### Series Partitioning Operator +By default, IoTDB limits the number of series partitions to 1000 and configures the series partitioning operator to use a hash partitioning strategy. This leads to the following outcomes: ++ Since the number of series partitions is a fixed constant, the mapping between series and series partitions remains stable. As a result, IoTDB does not require frequent data migrations. ++ The load across series partitions is relatively balanced because the number of series partitions is much smaller than the number of sensors deployed in the production environment. -### Sequence Partition Slots +Furthermore, if a more accurate estimate of the actual load in the production environment is available, the series partitioning operator can be configured to use a customized hash partitioning strategy or a list partitioning strategy to achieve a more uniform load distribution across all series partitions. -Each database holds a fixed number of sequence partition slots, with the default set to 1000. Every time series managed by the database is allocated to a unique sequence partition slot using a partitioning algorithm (usually some hash method). +##### Time Partitioning Operator +The time partitioning operator converts a given timestamp to the corresponding time partition by: +$$\left\lfloor\frac{\text{timestamp}-\text{start\_timestamp}}{\text{time\_partition\_interval}}\right\rfloor.$$ -### Time Partition Slots +In this equation, both $\text{start\_timestamp}$ and $\text{time\_partition\_interval}$ are configurable parameters to accommodate various production environments. The $\text{start\_timestamp}$ represents the starting time of the first time partition, while the $\text{time\_partition\_interval}$ defines the duration of each time partition. By default, the $\text{time\_partition\_interval}$ is set to one day. -Every time series will continuously produce data. If all the data from a time series is stored on one node continuously, the newly added DataNode in the cluster might not be effectively utilized. +#### Schema Partitioning +Since the series partitioning operator evenly partitions the time series, each series partition corresponds to a schema partition. These schema partitions are then evenly allocated across the SchemaRegionGroups to achieve a balanced schema distribution. -Time partition slots slice the time-series data from the time dimension (typically, one time partition per day), making the time-series data storage in the cluster easy to manage. +#### Data Partitioning +Combining a series partition with a time partition creates a data partition. Since the series partitioning operator evenly partitions the time series, the load of data partitions within a specified time partition remains balanced. These data partitions are then evenly allocated across the DataRegionGroups to achieve balanced data distribution. -## Metadata Partitioning +### Partition Allocation +IoTDB uses RegionGroups to enable elastic storage of time series, with the number of RegionGroups in the cluster determined by the total resources available across all DataNodes. Since the number of RegionGroups is dynamic, IoTDB can easily scale out. Both the SchemaRegionGroup and DataRegionGroup follow the same partition allocation strategy, which evenly splits all series partitions. The following figure demonstrates the partition allocation process, where the dynamic RegionGroups matc [...] -The metadata partition management of a single database, following a specific load balancing strategy, assigns all sequence slots to the corresponding SchemaRegionGroup, further horizontally scaling within the cluster. +<img style="width:100%; max-width:800px; max-height:600px; margin-left:auto; margin-right:auto; display:block;" src="https://alioss.timecho.com/docs/img/partition_allocation.png?raw=true";> -<img style="width:100%; max-width:800px; max-height:600px; margin-left:auto; margin-right:auto; display:block;" src="https://alioss.timecho.com/docs/img/SchemaRegion.png?raw=true";> +#### RegionGroup Expansion +The number of RegionGroups is given by -## Data Partitioning +$$\text{RegionGroup\_number}=\left\lfloor\frac{\sum_{i=1}^{DataNode\_number}\text{Region\_number}_i}{\text{replication\_factor}}\right\rfloor.$$ -It follows a certain load balancing strategy, dividing time and sequence partition slots, and allocating them to the relevant DataRegionGroup, further allowing horizontal scaling in the cluster. +In this equation, $\text{Region\_number}_i$ represents the number of Regions expected to be hosted on the $i$-th DataNode, while $\text{replication\_factor}$ denotes the number of Regions within each RegionGroup. Both $\text{Region\_number}_i$ and $\text{replication\_factor}$ are configurable parameters. The $\text{Region\_number}_i$ can be determined by the available hardware resources---such as CPU cores, memory sizes, etc.---on the $i$-th DataNode to accommodate different physical ser [...] -<img style="width:100%; max-width:800px; max-height:600px; margin-left:auto; margin-right:auto; display:block;" src="https://alioss.timecho.com/docs/img/DataRegion.png?raw=true";> +#### Allocation Strategy +Both the SchemaRegionGroup and the DataRegionGroup follow the same allocation strategy—-splitting all series partitions evenly. As a result, each SchemaRegionGroup holds the same number of schema partitions, ensuring balanced schema storage. Similarly, for each time partition, each DataRegionGroup acquires the data partitions corresponding to the series partitions it holds. Consequently, the data partitions within a time partition are evenly distributed across all DataRegionGroups, ensur [...] -## Load Balancing +Notably, IoTDB effectively leverages the characteristics of time series data. When the TTL (Time to Live) is configured, IoTDB enables migration-free elastic storage for time series data. This feature facilitates cluster expansion while minimizing the impact on online operations. The figures above illustrate an instance of this feature: newborn data partitions are evenly allocated to each DataRegion, and expired data are automatically archived. As a result, the cluster's storage will eve [...] -When the cluster's capacity remains unchanged, data will be evenly distributed across all nodes to utilize storage and computational resources effectively. +## Load Balance +To enhance the cluster's availability and performance, IoTDB employs sophisticated Region placement and leader selection algorithms. -Also, during cluster expansion, the system automatically increases the number of regions to fully exploit the computational resources of all nodes without manual intervention. Such dynamic expansion enhances the cluster's performance and scalability, making the system more flexible and efficient. \ No newline at end of file +### Region Placement +The number of Regions held by a DataNode reflects its storage load. If the difference in the number of Regions across DataNodes is relatively large, the DataNode with more Regions is likely to become a storage bottleneck. Although a straightforward Round Robin placement algorithm can achieve storage balance by ensuring that each DataNode hosts an equal number of Regions, it compromises the cluster's fault tolerance, as illustrated below: + +<img style="width:100%; max-width:800px; max-height:600px; margin-left:auto; margin-right:auto; display:block;" src="https://alioss.timecho.com/docs/img/placement.png?raw=true";> + ++ Assume the cluster has 4 DataNodes, 4 RegionGroups and a replication factor of 2. ++ Place RegionGroup $r_1$'s 2 Regions on DataNodes $n_1$ and $n_2$. ++ Place RegionGroup $r_2$'s 2 Regions on DataNodes $n_3$ and $n_4$. ++ Place RegionGroup $r_3$'s 2 Regions on DataNodes $n_1$ and $n_3$. ++ Place RegionGroup $r_4$'s 2 Regions on DataNodes $n_2$ and $n_4$. + +In this scenario, if DataNode $n_2$ fails, the load previously handled by DataNode $n_2$ would be transferred solely to DataNode $n_1$, potentially overloading it. + +To address this issue, IoTDB employs a Region placement algorithm that not only evenly distributes Regions across all DataNodes but also ensures that each DataNode can offload its storage to sufficient other DataNodes in the event of a failure. As a result, the cluster achieves balanced storage distribution and a high level of fault tolerance, ensuring its availability. + +### Leader Selection +The number of leader Regions held by a DataNode reflects its computational load. If the difference in the number of leaders across DataNodes is relatively large, the DataNode with more leaders is likely to become a computational bottleneck. If the leader selection process is conducted using a transparent Greedy algorithm, the result may be an unbalanced leader distribution when the Regions are fault-tolerantly placed, as demonstrated below: + +<img style="width:100%; max-width:800px; max-height:600px; margin-left:auto; margin-right:auto; display:block;" src="https://alioss.timecho.com/docs/img/selection.png?raw=true";> + ++ Assume the cluster has 4 DataNodes, 4 RegionGroups and a replication factor of 2. ++ Select RegionGroup $r_5$'s Region on DataNode $n_5$ as the leader. ++ Select RegionGroup $r_6$'s Region on DataNode $n_7$ as the leader. ++ Select RegionGroup $r_7$'s Region on DataNode $n_7$ as the leader. ++ Select RegionGroup $r_8$'s Region on DataNode $n_8$ as the leader. + +Please note that all the above steps strictly follow the Greedy algorithm. However, by Step 3, selecting the leader of RegionGroup $r_7$ on either DataNode $n_5$ or $n_7$ results in an unbalanced leader distribution. The rationale is that each greedy step lacks a global perspective, leading to a locally optimal solution. + +To address this issue, IoTDB employs a leader selection algorithm that can consistently balance the cluster's leader distribution. Consequently, the cluster achieves balanced computational load distribution, ensuring its performance. + +## Source Code ++ [Data Partitioning](https://github.com/apache/iotdb/tree/master/iotdb-core/node-commons/src/main/java/org/apache/iotdb/commons/partition) ++ [Partition Allocation](https://github.com/apache/iotdb/tree/master/iotdb-core/confignode/src/main/java/org/apache/iotdb/confignode/manager/load/balancer/partition) ++ [Region Placement](https://github.com/apache/iotdb/tree/master/iotdb-core/confignode/src/main/java/org/apache/iotdb/confignode/manager/load/balancer/region) ++ [Leader Selection](https://github.com/apache/iotdb/tree/master/iotdb-core/confignode/src/main/java/org/apache/iotdb/confignode/manager/load/balancer/router/leader) \ No newline at end of file diff --git a/src/zh/UserGuide/Master/Basic-Concept/Cluster-data-partitioning.md b/src/zh/UserGuide/Master/Basic-Concept/Cluster-data-partitioning.md index 943659c..b8d8848 100644 --- a/src/zh/UserGuide/Master/Basic-Concept/Cluster-data-partitioning.md +++ b/src/zh/UserGuide/Master/Basic-Concept/Cluster-data-partitioning.md @@ -19,42 +19,91 @@ --> -# 数据分区与负载均衡 +# 分区与负载均衡 +本文档介绍了 IoTDB 中的分区策略和负载均衡算法。根据时序数据的特性，IoTDB 按序列和时间维度对其进行分区。结合序列分区与时间分区创建一个分区，作为划分的基本单元。为了提高吞吐量并降低管理成本，这些分区被均匀分配到 RegionGroup 中，RegionGroup 是复制的基本单元。RegionGroup 的 Region 决定了数据的存储位置，leader 负责主要负载的管理。在此过程中，Region 放置算法决定哪些节点将持有 Region，而 leader 选择算法则指定哪个 Region 将成为 leader。 -IoTDB 以数据分区（DataRegion）为单位对元数据和数据进行管理，从序列和时间两个维度进行数据划分。 +## 分区策略和分区分配 +IoTDB 为时间序列数据实现了量身定制的分区算子。在此基础上，缓存于 ConfigNode 和 DataNode 上的分区信息不仅易于管理，而且能够清晰区分冷热数据。随后，平衡的分区被均匀分配到集群的 RegionGroup 中，以实现存储均衡。 -<img style="width:100%; max-width:800px; max-height:600px; margin-left:auto; margin-right:auto; display:block;" src="https://alioss.timecho.com/docs/img/%E5%88%86%E5%8C%BA%E6%A7%BD%E4%B8%8E%E6%95%B0%E6%8D%AE%E5%88%86%E5%8C%BA.png?raw=true";> +### 分区策略 +IoTDB 将生产环境中的每个传感器映射为一个时间序列。然后，使用序列分区算子对时间序列进行分区以管理其元数据，再结合时间分区算子来管理其数据。下图展示了 IoTDB 如何对时序数据进行分区。 -## 分区槽 +<img style="width:100%; max-width:800px; max-height:600px; margin-left:auto; margin-right:auto; display:block;" src="https://alioss.timecho.com/docs/img/partition_table_cn.png?raw=true";> -一个序列分区槽和一个时间分区槽可以组合产生一个数据分区(当该序列分区槽在该时间分区槽下有对应数据时)。 +#### 分区算子 +由于生产环境中通常部署大量设备和传感器，IoTDB 使用序列分区算子以确保分区信息的大小可控。由于生成的时间序列与时间戳相关联，IoTDB 使用时间分区算子来清晰区分冷热分区。 -### 序列分区槽 +##### 序列分区算子 +默认情况下，IoTDB 将序列分区的数量限制为 1000，并将序列分区算子配置为哈希分区策略。这带来以下收益： ++ 由于序列分区的数量是固定常量，序列与序列分区之间的映射保持稳定。因此，IoTDB 不需要频繁进行数据迁移。 ++ 序列分区的负载相对均衡，因为序列分区的数量远小于生产环境中部署的传感器数量。 -每个数据库持有固定数量的序列分区槽，默认为1000个。该数据库管理的每个时间序列都将通过序列分区算法（通常为某种哈希算法）被分配给唯一的序列分区槽管理。 +更进一步，如果能够更准确地估计生产环境中的实际负载情况，序列分区算子可以配置为自定义的哈希分区策略或列表分区策略，以在所有序列分区中实现更均匀的负载分布。 -<img style="width:100%; max-width:800px; max-height:600px; margin-left:auto; margin-right:auto; display:block;" src="https://alioss.timecho.com/docs/img/SeriesPartitionSlot.png?raw=true";> +##### 时间分区算子 +时间分区算子通过下式将给定的时间戳转换为相应的时间分区： +$$\left\lfloor\frac{\text{timestamp}-\text{start\_timestamp}}{\text{time\_partition\_interval}}\right\rfloor。$$ -### 时间分区槽 +在此式中，$\text{start\_timestamp}$ 和 $\text{time\_partition\_interval}$ 都是可配置参数，以适应不同的生产环境。$\text{start\_timestamp}$ 表示第一个时间分区的起始时间，而 $\text{time\_partition\_interval}$ 定义了每个时间分区的持续时间。默认情况下，$\text{time\_partition\_interval}$ 设置为一天。 -每个时间序列都将持续产生数据，如果一个时间序列产生的全部数据持续存储于一个节点，那么集群新增的 DataNode 可能无法得到有效利用。 +#### 元数据分区 +由于序列分区算子对时间序列进行了均匀分区，每个序列分区对应一个元数据分区。这些元数据分区随后被均匀分配到 SchemaRegionGroup 中，以实现元数据的均衡分布。 -时间分区槽从时间维度对时序数据进行分片（默认为每 7 天一个时间分区），使得集群时序数据的存储易于规划。 +#### 数据分区 +结合序列分区与时间分区创建数据分区。由于序列分区算子对时间序列进行了均匀分区，特定时间分区内的数据分区负载保持均衡。这些数据分区随后被均匀分配到 DataRegionGroup 中，以实现数据的均衡分布。 -## 元数据分区 +### 分区分配 +IoTDB 使用 RegionGroup 来实现时间序列的弹性存储，集群中RegionGroup 的数量由所有 DataNode 的总资源决定。由于RegionGroup 的数量是动态的，IoTDB 可以轻松扩展。SchemaRegionGroup 和 DataRegionGroup 都遵循相同的分区分配策略，即均匀划分所有序列分区。下图展示了分区分配过程，其中动态的 RegionGroup 匹配不断扩展的时间序列和集群。 -单个数据库的元数据分区管理，会按照一定的负载均衡策略，将所有序列槽分配到相应的 SchemaRegionGroup 中，进而在集群中横向扩展。 +<img style="width:100%; max-width:800px; max-height:600px; margin-left:auto; margin-right:auto; display:block;" src="https://alioss.timecho.com/docs/img/partition_allocation.png?raw=true";> -<img style="width:100%; max-width:800px; max-height:600px; margin-left:auto; margin-right:auto; display:block;" src="https://alioss.timecho.com/docs/img/SchemaRegion.png?raw=true";> +#### RegionGroup 扩容 +RegionGroup 的数量由下式给出： -## 数据分区 +$$\text{RegionGroup\_number}=\left\lfloor\frac{\sum_{i=1}^{DataNode\_number}\text{Region\_number}_i}{\text{replication\_factor}}\right\rfloor。$$ -会按照一定的负载均衡策略，进行时间分区槽和序列分区槽的划分，并分配到相应的 DataRegionGroup 中，进而在集群中横向扩展。 +在此式中，$\text{Region\_number}_i$ 表示期望在第 $i$ 个 DataNode 上放置的 Region 数量，而 $\text{replication\_factor}$ 表示每个 RegionGroup 中的 Region 数量。$\text{Region\_number}_i$ 和 $\text{replication\_factor}$ 都是可配置的参数。$\text{Region\_number}_i$ 可以根据第 $i$ 个 DataNode 上的可用硬件资源（如 CPU 核心数量、内存大小等）确定，以适应不同的物理服务器。$\text{replication\_factor}$ 可以调整以确保不同级别的容错能力。 -<img style="width:100%; max-width:800px; max-height:600px; margin-left:auto; margin-right:auto; display:block;" src="https://alioss.timecho.com/docs/img/DataRegion.png?raw=true";> +#### 分配策略 +SchemaRegionGroup 和 DataRegionGroup 都遵循相同的分配策略，即均匀划分所有序列分区。因此，每个 SchemaRegionGroup 持有相同数量的元数据分区，以确保元数据存储均衡。同样，对于每个时间分区，每个 DataRegionGroup 获取与其持有的序列分区对应的数据分区。因此，时间分区内的数据分区均匀分布在所有 DataRegionGroup 中，确保每个时间分区内的数据存储均衡。 + +值得注意的是，IoTDB 有效利用了时序数据的特性。当配置了 TTL（生存时间）时，IoTDB 可实现无需迁移的时序数据弹性存储，该功能在集群扩展时最小化了对在线操作的影响。上图展示了该功能的一个实例：新生成的数据分区被均匀分配到每个 DataRegion，过期数据会自动归档。因此，集群的存储最终将保持平衡。 ## 负载均衡 +为了提高集群的可用性和性能，IoTDB 采用了精心设计的 Region 放置和 leader 选择算法。 + +### Region 放置 +DataNode 持有的 Region 数量反映了它的存储负载。如果DataNode 之间的 Region 数量差异较大，拥有更多 Region 的DataNode 可能成为存储瓶颈。尽管简单的轮询（Round Robin）放置算法可以通过确保每个 DataNode 持有等量 Region 来实现存储均衡，但它会降低集群的容错能力，如下所示： + +<img style="width:100%; max-width:800px; max-height:600px; margin-left:auto; margin-right:auto; display:block;" src="https://alioss.timecho.com/docs/img/placement.png?raw=true";> + ++ 假设集群有 4 个 DataNode，4 个 RegionGroup，并且副本因子为 2。 ++ 将 RegionGroup $r_1$ 的 2 个 Region 放置在 DataNode $n_1$ 和 $n_2$ 上。 ++ 将 RegionGroup $r_2$ 的 2 个 Region 放置在 DataNode $n_3$ 和 $n_4$ 上。 ++ 将 RegionGroup $r_3$ 的 2 个 Region 放置在 DataNode $n_1$ 和 $n_3$ 上。 ++ 将 RegionGroup $r_4$ 的 2 个 Region 放置在 DataNode $n_2$ 和 $n_4$ 上。 + +在这种情况下，如果 DataNode $n_2$ 发生故障，由它先前负责的负载将只能全部转移到 DataNode $n_1$，可能导致其过载。 + +为了解决这个问题，IoTDB 采用了一种副本放置算法，该算法不仅将Region 均匀放置到所有 DataNode 上，还确保每个 DataNode 在发生故障时，能够将其负载转移到足够多的其他 DataNode。因此，集群实现了存储分布的均衡，并具备较高的容错能力，从而确保其可用性。 + +### Leader 选择 +一个 DataNode 持有的 leader Region 数量反映了它的计算负载。如果 DataNode 之间持有 leader 数量差异较大，拥有更多 leader 的 DataNode 可能成为计算瓶颈。如果 leader 选择过程使用直观的贪心算法，当 Region 以容错算法放置时，可能会导致 leader 分布不均，如下所示： + +<img style="width:100%; max-width:800px; max-height:600px; margin-left:auto; margin-right:auto; display:block;" src="https://alioss.timecho.com/docs/img/selection.png?raw=true";> + ++ 假设集群有 4 个 DataNode，4 个 RegionGroup，并且副本因子为 2。 ++ 选择 RegionGroup $r_5$ 在 DataNode $n_5$ 上的 Region 作为 leader。 ++ 选择 RegionGroup $r_6$ 在 DataNode $n_7$ 上的 Region 作为 leader。 ++ 选择 RegionGroup $r_7$ 在 DataNode $n_7$ 上的 Region 作为 leader。 ++ 选择 RegionGroup $r_8$ 在 DataNode $n_8$ 上的 Region 作为 leader。 + +请注意，以上步骤严格遵循贪心算法。然而，到第 3 步时，无论在DataNode $n_5$ 或 $n_7$ 上选择 RegionGroup $r_7$ 的 leader，都会导致 leader 分布不均衡。根本原因在于每一步贪心选择都缺乏全局视角，最终导致局部最优解。 -当集群容量保持不变时，数据会被均匀分配到各个节点，以实现存储和计算资源的均衡利用。 +为了解决这个问题，IoTDB 采用了一种 leader 选择算法，能够持续平衡集群中的 leader 分布。因此，集群实现了计算负载的均衡分布，确保了其性能。 -同时，在进行集群扩容时，系统会自动增加区域（region）的数量，以充分利用所有节点的计算资源，无需人工干预。这种动态扩展能够提高集群的性能和可扩展性，使整个系统更加灵活和高效。 +## Source Code ++ [数据分区](https://github.com/apache/iotdb/tree/master/iotdb-core/node-commons/src/main/java/org/apache/iotdb/commons/partition) ++ [分区分配](https://github.com/apache/iotdb/tree/master/iotdb-core/confignode/src/main/java/org/apache/iotdb/confignode/manager/load/balancer/partition) ++ [Region 放置](https://github.com/apache/iotdb/tree/master/iotdb-core/confignode/src/main/java/org/apache/iotdb/confignode/manager/load/balancer/region) ++ [主 Region 选择](https://github.com/apache/iotdb/tree/master/iotdb-core/confignode/src/main/java/org/apache/iotdb/confignode/manager/load/balancer/router/leader) \ No newline at end of file diff --git a/src/zh/UserGuide/latest/Basic-Concept/Cluster-data-partitioning.md b/src/zh/UserGuide/latest/Basic-Concept/Cluster-data-partitioning.md index 943659c..b8d8848 100644 --- a/src/zh/UserGuide/latest/Basic-Concept/Cluster-data-partitioning.md +++ b/src/zh/UserGuide/latest/Basic-Concept/Cluster-data-partitioning.md @@ -19,42 +19,91 @@ --> -# 数据分区与负载均衡 +# 分区与负载均衡 +本文档介绍了 IoTDB 中的分区策略和负载均衡算法。根据时序数据的特性，IoTDB 按序列和时间维度对其进行分区。结合序列分区与时间分区创建一个分区，作为划分的基本单元。为了提高吞吐量并降低管理成本，这些分区被均匀分配到 RegionGroup 中，RegionGroup 是复制的基本单元。RegionGroup 的 Region 决定了数据的存储位置，leader 负责主要负载的管理。在此过程中，Region 放置算法决定哪些节点将持有 Region，而 leader 选择算法则指定哪个 Region 将成为 leader。 -IoTDB 以数据分区（DataRegion）为单位对元数据和数据进行管理，从序列和时间两个维度进行数据划分。 +## 分区策略和分区分配 +IoTDB 为时间序列数据实现了量身定制的分区算子。在此基础上，缓存于 ConfigNode 和 DataNode 上的分区信息不仅易于管理，而且能够清晰区分冷热数据。随后，平衡的分区被均匀分配到集群的 RegionGroup 中，以实现存储均衡。 -<img style="width:100%; max-width:800px; max-height:600px; margin-left:auto; margin-right:auto; display:block;" src="https://alioss.timecho.com/docs/img/%E5%88%86%E5%8C%BA%E6%A7%BD%E4%B8%8E%E6%95%B0%E6%8D%AE%E5%88%86%E5%8C%BA.png?raw=true";> +### 分区策略 +IoTDB 将生产环境中的每个传感器映射为一个时间序列。然后，使用序列分区算子对时间序列进行分区以管理其元数据，再结合时间分区算子来管理其数据。下图展示了 IoTDB 如何对时序数据进行分区。 -## 分区槽 +<img style="width:100%; max-width:800px; max-height:600px; margin-left:auto; margin-right:auto; display:block;" src="https://alioss.timecho.com/docs/img/partition_table_cn.png?raw=true";> -一个序列分区槽和一个时间分区槽可以组合产生一个数据分区(当该序列分区槽在该时间分区槽下有对应数据时)。 +#### 分区算子 +由于生产环境中通常部署大量设备和传感器，IoTDB 使用序列分区算子以确保分区信息的大小可控。由于生成的时间序列与时间戳相关联，IoTDB 使用时间分区算子来清晰区分冷热分区。 -### 序列分区槽 +##### 序列分区算子 +默认情况下，IoTDB 将序列分区的数量限制为 1000，并将序列分区算子配置为哈希分区策略。这带来以下收益： ++ 由于序列分区的数量是固定常量，序列与序列分区之间的映射保持稳定。因此，IoTDB 不需要频繁进行数据迁移。 ++ 序列分区的负载相对均衡，因为序列分区的数量远小于生产环境中部署的传感器数量。 -每个数据库持有固定数量的序列分区槽，默认为1000个。该数据库管理的每个时间序列都将通过序列分区算法（通常为某种哈希算法）被分配给唯一的序列分区槽管理。 +更进一步，如果能够更准确地估计生产环境中的实际负载情况，序列分区算子可以配置为自定义的哈希分区策略或列表分区策略，以在所有序列分区中实现更均匀的负载分布。 -<img style="width:100%; max-width:800px; max-height:600px; margin-left:auto; margin-right:auto; display:block;" src="https://alioss.timecho.com/docs/img/SeriesPartitionSlot.png?raw=true";> +##### 时间分区算子 +时间分区算子通过下式将给定的时间戳转换为相应的时间分区： +$$\left\lfloor\frac{\text{timestamp}-\text{start\_timestamp}}{\text{time\_partition\_interval}}\right\rfloor。$$ -### 时间分区槽 +在此式中，$\text{start\_timestamp}$ 和 $\text{time\_partition\_interval}$ 都是可配置参数，以适应不同的生产环境。$\text{start\_timestamp}$ 表示第一个时间分区的起始时间，而 $\text{time\_partition\_interval}$ 定义了每个时间分区的持续时间。默认情况下，$\text{time\_partition\_interval}$ 设置为一天。 -每个时间序列都将持续产生数据，如果一个时间序列产生的全部数据持续存储于一个节点，那么集群新增的 DataNode 可能无法得到有效利用。 +#### 元数据分区 +由于序列分区算子对时间序列进行了均匀分区，每个序列分区对应一个元数据分区。这些元数据分区随后被均匀分配到 SchemaRegionGroup 中，以实现元数据的均衡分布。 -时间分区槽从时间维度对时序数据进行分片（默认为每 7 天一个时间分区），使得集群时序数据的存储易于规划。 +#### 数据分区 +结合序列分区与时间分区创建数据分区。由于序列分区算子对时间序列进行了均匀分区，特定时间分区内的数据分区负载保持均衡。这些数据分区随后被均匀分配到 DataRegionGroup 中，以实现数据的均衡分布。 -## 元数据分区 +### 分区分配 +IoTDB 使用 RegionGroup 来实现时间序列的弹性存储，集群中RegionGroup 的数量由所有 DataNode 的总资源决定。由于RegionGroup 的数量是动态的，IoTDB 可以轻松扩展。SchemaRegionGroup 和 DataRegionGroup 都遵循相同的分区分配策略，即均匀划分所有序列分区。下图展示了分区分配过程，其中动态的 RegionGroup 匹配不断扩展的时间序列和集群。 -单个数据库的元数据分区管理，会按照一定的负载均衡策略，将所有序列槽分配到相应的 SchemaRegionGroup 中，进而在集群中横向扩展。 +<img style="width:100%; max-width:800px; max-height:600px; margin-left:auto; margin-right:auto; display:block;" src="https://alioss.timecho.com/docs/img/partition_allocation.png?raw=true";> -<img style="width:100%; max-width:800px; max-height:600px; margin-left:auto; margin-right:auto; display:block;" src="https://alioss.timecho.com/docs/img/SchemaRegion.png?raw=true";> +#### RegionGroup 扩容 +RegionGroup 的数量由下式给出： -## 数据分区 +$$\text{RegionGroup\_number}=\left\lfloor\frac{\sum_{i=1}^{DataNode\_number}\text{Region\_number}_i}{\text{replication\_factor}}\right\rfloor。$$ -会按照一定的负载均衡策略，进行时间分区槽和序列分区槽的划分，并分配到相应的 DataRegionGroup 中，进而在集群中横向扩展。 +在此式中，$\text{Region\_number}_i$ 表示期望在第 $i$ 个 DataNode 上放置的 Region 数量，而 $\text{replication\_factor}$ 表示每个 RegionGroup 中的 Region 数量。$\text{Region\_number}_i$ 和 $\text{replication\_factor}$ 都是可配置的参数。$\text{Region\_number}_i$ 可以根据第 $i$ 个 DataNode 上的可用硬件资源（如 CPU 核心数量、内存大小等）确定，以适应不同的物理服务器。$\text{replication\_factor}$ 可以调整以确保不同级别的容错能力。 -<img style="width:100%; max-width:800px; max-height:600px; margin-left:auto; margin-right:auto; display:block;" src="https://alioss.timecho.com/docs/img/DataRegion.png?raw=true";> +#### 分配策略 +SchemaRegionGroup 和 DataRegionGroup 都遵循相同的分配策略，即均匀划分所有序列分区。因此，每个 SchemaRegionGroup 持有相同数量的元数据分区，以确保元数据存储均衡。同样，对于每个时间分区，每个 DataRegionGroup 获取与其持有的序列分区对应的数据分区。因此，时间分区内的数据分区均匀分布在所有 DataRegionGroup 中，确保每个时间分区内的数据存储均衡。 + +值得注意的是，IoTDB 有效利用了时序数据的特性。当配置了 TTL（生存时间）时，IoTDB 可实现无需迁移的时序数据弹性存储，该功能在集群扩展时最小化了对在线操作的影响。上图展示了该功能的一个实例：新生成的数据分区被均匀分配到每个 DataRegion，过期数据会自动归档。因此，集群的存储最终将保持平衡。 ## 负载均衡 +为了提高集群的可用性和性能，IoTDB 采用了精心设计的 Region 放置和 leader 选择算法。 + +### Region 放置 +DataNode 持有的 Region 数量反映了它的存储负载。如果DataNode 之间的 Region 数量差异较大，拥有更多 Region 的DataNode 可能成为存储瓶颈。尽管简单的轮询（Round Robin）放置算法可以通过确保每个 DataNode 持有等量 Region 来实现存储均衡，但它会降低集群的容错能力，如下所示： + +<img style="width:100%; max-width:800px; max-height:600px; margin-left:auto; margin-right:auto; display:block;" src="https://alioss.timecho.com/docs/img/placement.png?raw=true";> + ++ 假设集群有 4 个 DataNode，4 个 RegionGroup，并且副本因子为 2。 ++ 将 RegionGroup $r_1$ 的 2 个 Region 放置在 DataNode $n_1$ 和 $n_2$ 上。 ++ 将 RegionGroup $r_2$ 的 2 个 Region 放置在 DataNode $n_3$ 和 $n_4$ 上。 ++ 将 RegionGroup $r_3$ 的 2 个 Region 放置在 DataNode $n_1$ 和 $n_3$ 上。 ++ 将 RegionGroup $r_4$ 的 2 个 Region 放置在 DataNode $n_2$ 和 $n_4$ 上。 + +在这种情况下，如果 DataNode $n_2$ 发生故障，由它先前负责的负载将只能全部转移到 DataNode $n_1$，可能导致其过载。 + +为了解决这个问题，IoTDB 采用了一种副本放置算法，该算法不仅将Region 均匀放置到所有 DataNode 上，还确保每个 DataNode 在发生故障时，能够将其负载转移到足够多的其他 DataNode。因此，集群实现了存储分布的均衡，并具备较高的容错能力，从而确保其可用性。 + +### Leader 选择 +一个 DataNode 持有的 leader Region 数量反映了它的计算负载。如果 DataNode 之间持有 leader 数量差异较大，拥有更多 leader 的 DataNode 可能成为计算瓶颈。如果 leader 选择过程使用直观的贪心算法，当 Region 以容错算法放置时，可能会导致 leader 分布不均，如下所示： + +<img style="width:100%; max-width:800px; max-height:600px; margin-left:auto; margin-right:auto; display:block;" src="https://alioss.timecho.com/docs/img/selection.png?raw=true";> + ++ 假设集群有 4 个 DataNode，4 个 RegionGroup，并且副本因子为 2。 ++ 选择 RegionGroup $r_5$ 在 DataNode $n_5$ 上的 Region 作为 leader。 ++ 选择 RegionGroup $r_6$ 在 DataNode $n_7$ 上的 Region 作为 leader。 ++ 选择 RegionGroup $r_7$ 在 DataNode $n_7$ 上的 Region 作为 leader。 ++ 选择 RegionGroup $r_8$ 在 DataNode $n_8$ 上的 Region 作为 leader。 + +请注意，以上步骤严格遵循贪心算法。然而，到第 3 步时，无论在DataNode $n_5$ 或 $n_7$ 上选择 RegionGroup $r_7$ 的 leader，都会导致 leader 分布不均衡。根本原因在于每一步贪心选择都缺乏全局视角，最终导致局部最优解。 -当集群容量保持不变时，数据会被均匀分配到各个节点，以实现存储和计算资源的均衡利用。 +为了解决这个问题，IoTDB 采用了一种 leader 选择算法，能够持续平衡集群中的 leader 分布。因此，集群实现了计算负载的均衡分布，确保了其性能。 -同时，在进行集群扩容时，系统会自动增加区域（region）的数量，以充分利用所有节点的计算资源，无需人工干预。这种动态扩展能够提高集群的性能和可扩展性，使整个系统更加灵活和高效。 +## Source Code ++ [数据分区](https://github.com/apache/iotdb/tree/master/iotdb-core/node-commons/src/main/java/org/apache/iotdb/commons/partition) ++ [分区分配](https://github.com/apache/iotdb/tree/master/iotdb-core/confignode/src/main/java/org/apache/iotdb/confignode/manager/load/balancer/partition) ++ [Region 放置](https://github.com/apache/iotdb/tree/master/iotdb-core/confignode/src/main/java/org/apache/iotdb/confignode/manager/load/balancer/region) ++ [主 Region 选择](https://github.com/apache/iotdb/tree/master/iotdb-core/confignode/src/main/java/org/apache/iotdb/confignode/manager/load/balancer/router/leader) \ No newline at end of file
![https://alioss.timecho.com/upload/data-region.jpg"](https://alioss.timecho.com/upload/data-region.jpg"){kind=link}
![https://alioss.timecho.com/docs/img/partition_table_en.png?raw=true"](https://alioss.timecho.com/docs/img/partition_table_en.png?raw=true"){kind=link}
![https://alioss.timecho.com/docs/img/SeriesPartitionSlot.png?raw=true"](https://alioss.timecho.com/docs/img/SeriesPartitionSlot.png?raw=true"){kind=link}
![https://alioss.timecho.com/docs/img/partition_allocation.png?raw=true"](https://alioss.timecho.com/docs/img/partition_allocation.png?raw=true"){kind=link}
![https://alioss.timecho.com/docs/img/SchemaRegion.png?raw=true"](https://alioss.timecho.com/docs/img/SchemaRegion.png?raw=true"){kind=link}
![https://alioss.timecho.com/docs/img/DataRegion.png?raw=true"](https://alioss.timecho.com/docs/img/DataRegion.png?raw=true"){kind=link}
![https://alioss.timecho.com/docs/img/placement.png?raw=true"](https://alioss.timecho.com/docs/img/placement.png?raw=true"){kind=link}
![https://alioss.timecho.com/docs/img/selection.png?raw=true"](https://alioss.timecho.com/docs/img/selection.png?raw=true"){kind=link}
![https://alioss.timecho.com/docs/img/%E5%88%86%E5%8C%BA%E6%A7%BD%E4%B8%8E%E6%95%B0%E6%8D%AE%E5%88%86%E5%8C%BA.png?raw=true"](https://alioss.timecho.com/docs/img/%E5%88%86%E5%8C%BA%E6%A7%BD%E4%B8%8E%E6%95%B0%E6%8D%AE%E5%88%86%E5%8C%BA.png?raw=true"){kind=link}
![https://alioss.timecho.com/docs/img/partition_table_cn.png?raw=true"](https://alioss.timecho.com/docs/img/partition_table_cn.png?raw=true"){kind=link}