This is an automated email from the ASF dual-hosted git repository.
caogaofei pushed a commit to branch main
in repository https://gitbox.apache.org/repos/asf/iotdb-docs.git
The following commit(s) were added to refs/heads/main by this push:
new 5a96926 Modify the table format of the "Database Resources" document,
delete the "Resource Recommendation" document, and remove the "Monitoring Board
Install and Deploy" entry in the open source version document
5a96926 is described below
commit 5a9692648ec1a069e185eedba62f45d111f2de51
Author: majialin <[email protected]>
AuthorDate: Thu Jun 13 20:02:55 2024 +0800
Modify the table format of the "Database Resources" document, delete the
"Resource Recommendation" document, and remove the "Monitoring Board Install
and Deploy" entry in the open source version document
---
src/.vuepress/sidebar/V1.3.x/en.ts | 4 +-
src/.vuepress/sidebar/V1.3.x/zh.ts | 1 -
src/.vuepress/sidebar_timecho/V1.3.x/en.ts | 3 +-
src/.vuepress/sidebar_timecho/V1.3.x/zh.ts | 1 -
.../Database-Resources.md | 181 +++++++++++++++++---
.../Master/stage/Deployment-Recommendation.md | 182 +++++++++++++++++++++
.../Database-Resources.md | 181 +++++++++++++++++---
.../latest/stage/Deployment-Recommendation.md | 182 +++++++++++++++++++++
.../Database-Resources.md | 181 ++++++++++++++++----
.../Master/stage/Deployment-Recommendation.md | 178 ++++++++++++++++++++
.../Database-Resources.md | 88 ++++++----
.../latest/stage/Deployment-Recommendation.md | 178 ++++++++++++++++++++
12 files changed, 1242 insertions(+), 118 deletions(-)
diff --git a/src/.vuepress/sidebar/V1.3.x/en.ts
b/src/.vuepress/sidebar/V1.3.x/en.ts
index 1bde631..cadee7a 100644
--- a/src/.vuepress/sidebar/V1.3.x/en.ts
+++ b/src/.vuepress/sidebar/V1.3.x/en.ts
@@ -66,13 +66,11 @@ export const enSidebar = {
prefix: 'Deployment-and-Maintenance/',
// children: 'structure',
children: [
- { text: 'Package acquisition', link: 'IoTDB-Package' },
+ { text: 'Package Acquisition', link: 'IoTDB-Package' },
{ text: 'Database Resources', link: 'Database-Resources' },
{ text: 'Environmental Requirement', link: 'Environmental-Requirement'
},
- { text: 'Resource Recommendation', link: 'Deployment-Recommendation' },
{ text: 'Deployment Guide', link: 'Deployment-Guide' },
{ text: 'Docker Install', link: 'Docker-Install' },
- { text: 'Monitoring-Board-Install-and-Deploy', link:
'Monitoring-Board-Install-and-Deploy' },
],
},
diff --git a/src/.vuepress/sidebar/V1.3.x/zh.ts
b/src/.vuepress/sidebar/V1.3.x/zh.ts
index 2e444d3..bfb6e08 100644
--- a/src/.vuepress/sidebar/V1.3.x/zh.ts
+++ b/src/.vuepress/sidebar/V1.3.x/zh.ts
@@ -69,7 +69,6 @@ export const zhSidebar = {
{ text: '安装包获取', link: 'IoTDB-Package' },
{ text: '资源规划', link: 'Database-Resources' },
{ text: '部署准备', link: 'Deployment-Preparation' },
- { text: '资源推荐', link: 'Deployment-Recommendation' },
{ text: '部署指导', link: 'Deployment-Guide' },
{ text: 'docker部署', link: 'Docker-Install' },
],
diff --git a/src/.vuepress/sidebar_timecho/V1.3.x/en.ts
b/src/.vuepress/sidebar_timecho/V1.3.x/en.ts
index 2115c80..5bbc620 100644
--- a/src/.vuepress/sidebar_timecho/V1.3.x/en.ts
+++ b/src/.vuepress/sidebar_timecho/V1.3.x/en.ts
@@ -66,10 +66,9 @@ export const enSidebar = {
prefix: 'Deployment-and-Maintenance/',
// children: 'structure',
children: [
- { text: 'Package acquisition', link: 'IoTDB-Package_timecho' },
+ { text: 'Package Acquisition', link: 'IoTDB-Package_timecho' },
{ text: 'Database Resources', link: 'Database-Resources' },
{ text: 'Environmental Requirement', link: 'Environmental-Requirement'
},
- { text: 'Resource Recommendation', link: 'Deployment-Recommendation' },
{ text: 'Deployment Guide', link: 'Deployment-Guide_timecho' },
{ text: 'Docker Install', link: 'Docker-Install' },
{ text: 'Monitoring-Board-Install-and-Deploy', link:
'Monitoring-Board-Install-and-Deploy' },
diff --git a/src/.vuepress/sidebar_timecho/V1.3.x/zh.ts
b/src/.vuepress/sidebar_timecho/V1.3.x/zh.ts
index b9a7762..805ec33 100644
--- a/src/.vuepress/sidebar_timecho/V1.3.x/zh.ts
+++ b/src/.vuepress/sidebar_timecho/V1.3.x/zh.ts
@@ -69,7 +69,6 @@ export const zhSidebar = {
{ text: '安装包获取', link: 'IoTDB-Package_timecho' },
{ text: '资源规划', link: 'Database-Resources' },
{ text: '部署准备', link: 'Deployment-Preparation' },
- { text: '资源推荐', link: 'Deployment-Recommendation' },
{ text: '部署指导', link: 'Deployment-Guide_timecho' },
{ text: 'docker部署', link: 'Docker-Install' },
{ text: '监控面板安装部署', link: 'Monitoring-Board-Install-and-Deploy' },
diff --git
a/src/UserGuide/Master/Deployment-and-Maintenance/Database-Resources.md
b/src/UserGuide/Master/Deployment-and-Maintenance/Database-Resources.md
index 6cdd4aa..d6eaa90 100644
--- a/src/UserGuide/Master/Deployment-and-Maintenance/Database-Resources.md
+++ b/src/UserGuide/Master/Deployment-and-Maintenance/Database-Resources.md
@@ -20,37 +20,164 @@
-->
# Database Resources
## CPU
-| Number of second level sequences | CPU
| Number of nodes | |
|
-| -------------------------------- |
------------------------------------------------ | --------------- | ---- |
------------------------------------------------ |
-| standalone mode | Double active
| Distributed | |
|
-| Within 100000 | 2-4 core
| 1 | 2 | 3
|
-| Within 300000 | 4-8core
| 1 | 2 | 3
|
-| Within 500000 | 8-26core
| 1 | 2 | 3
|
-| Within 1000000 | 16-32core
| 1 | 2 | 3
|
-| Within 2000000 | 32-48core
| 1 | 2 | 3
|
-| Within 10000000 | 48-core
| 1 | 2 | Please contact Timecho Business for
consultation |
-| Over 10000000 | Please contact Timecho Business for
consultation | | |
|
+<table>
+ <tr>
+ <th rowspan="2">Number of second level sequences</th>
+ <th rowspan="2">CPU</th>
+ <th colspan="3">Number of nodes</th>
+ </tr>
+ <tr>
+ <th>standalone mode</th>
+ <th>Double active</th>
+ <th>Distributed</th>
+ </tr>
+ <tr>
+ <td>Within 100000</td>
+ <td>2core-4core</td>
+ <td>1</td>
+ <td>2</td>
+ <td>3</td>
+ </tr>
+ <tr>
+ <td>Within 300000</td>
+ <td>4core-8core</td>
+ <td>1</td>
+ <td>2</td>
+ <td>3</td>
+ </tr>
+ <tr>
+ <td>Within 500000</td>
+ <td>8core-26core</td>
+ <td>1</td>
+ <td>2</td>
+ <td>3</td>
+ </tr>
+ <tr>
+ <td>Within 1000000</td>
+ <td>16core-32core</td>
+ <td>1</td>
+ <td>2</td>
+ <td>3</td>
+ </tr>
+ <tr>
+ <td>Within 2000000</td>
+ <td>32core-48core</td>
+ <td>1</td>
+ <td>2</td>
+ <td>3</td>
+ </tr>
+ <tr>
+ <td>Within 10000000</td>
+ <td>48core</td>
+ <td>1</td>
+ <td>2</td>
+ <td>Please contact Timecho Business for consultation</td>
+ </tr>
+ <tr>
+ <td>Over 10000000</td>
+ <td colspan="4">Please contact Timecho Business for
consultation</td>
+ </tr>
+</table>
+
## Memory
-| Number of second level sequences | Memory
| Number of nodes | |
|
-| -------------------------------- |
------------------------------------------------ | --------------- | ---- |
------------------------------------------------ |
-| standalone mode | Double active
| Distributed | |
|
-| Within 100000 | 4G-8G
| 1 | 2 | 3
|
-| Within 300000 | 12G-32G
| 1 | 2 | 3
|
-| Within 500000 | 24G-48G
| 1 | 2 | 3
|
-| Within 1000000 | 32G-96G
| 1 | 2 | 3
|
-| Within 2000000 | 64G-128G
| 1 | 2 | 3
|
-| Within 10000000 | 128G
| 1 | 2 | Please contact Timecho Business for
consultation |
-| 1000w以上Over 10000000 | Please contact Timecho Business for
consultation | | |
|
+<table>
+ <tr>
+ <th rowspan="2">Number of second level sequences</th>
+ <th rowspan="2">Memory</th>
+ <th colspan="3">Number of nodes</th>
+ </tr>
+ <tr>
+ <th>standalone mode</th>
+ <th>Double active</th>
+ <th>Distributed</th>
+ </tr>
+ <tr>
+ <td>Within 100000</td>
+ <td>4G-8G</td>
+ <td>1</td>
+ <td>2</td>
+ <td>3</td>
+ </tr>
+ <tr>
+ <td>Within 300000</td>
+ <td>12G-32G</td>
+ <td>1</td>
+ <td>2</td>
+ <td>3</td>
+ </tr>
+ <tr>
+ <td>Within 500000</td>
+ <td>24G-48G</td>
+ <td>1</td>
+ <td>2</td>
+ <td>3</td>
+ </tr>
+ <tr>
+ <td>Within 1000000</td>
+ <td>32G-96G</td>
+ <td>1</td>
+ <td>2</td>
+ <td>3</td>
+ </tr>
+ <tr>
+ <td>Within 2000000</td>
+ <td>64G-128G</td>
+ <td>1</td>
+ <td>2</td>
+ <td>3</td>
+ </tr>
+ <tr>
+ <td>Within 10000000</td>
+ <td>128G</td>
+ <td>1</td>
+ <td>2</td>
+ <td>Please contact Timecho Business for consultation</td>
+ </tr>
+ <tr>
+ <td>Over 10000000</td>
+ <td colspan="4">Please contact Timecho Business for
consultation</td>
+ </tr>
+</table>
+
## Storage (Disk)
### Storage space
Calculation formula: Number of measurement points * Sampling frequency (Hz) *
Size of each data point (Byte, different data types may vary, see table below)
* Storage time (seconds) * Number of copies (usually 1 copy for a single node
and 2 copies for a cluster) ÷ Compression ratio (can be estimated at 5-10
times, but may be higher in actual situations)
-| Data point size calculation table | | |
|
-| --------------------------------- | ----------------- | ---------------- |
------------------------------------ |
-| data type | Timestamp (Bytes) | Value (Bytes) |
Total size of data points (in bytes) |
-| Boolean | 8 | 1 | 9
|
-| INT32）/FLOAT | 8 | 4 | 12
|
-| INT64/DOUBLE | 8 | 8 |
16 |
-| TEXT | 8 | The average is a |
8+a |
+<table>
+ <tr>
+ <th colspan="4">Data point size calculation</th>
+ </tr>
+ <tr>
+ <th>data type</th>
+ <th>Timestamp (Bytes)</th>
+ <th> Value (Bytes)</th>
+ <th> Total size of data points (in bytes)
+ </th>
+ </tr>
+ <tr>
+ <td>Boolean</td>
+ <td>8</td>
+ <td>1</td>
+ <td>9</td>
+ </tr>
+ <tr>
+ <td> INT32/FLOAT</td>
+ <td>8</td>
+ <td>4</td>
+ <td>12</td>
+ </tr>
+ <tr>
+ <td>INT64/DOUBLE</td>
+ <td>8</td>
+ <td>8</td>
+ <td>16</td>
+ </tr>
+ <tr>
+ <td>TEXT</td>
+ <td>8</td>
+ <td>The average is a</td>
+ <td>8+a</td>
+ </tr>
+</table>
Example: 1000 devices, each with 100 measurement points, a total of 100000
sequences, INT32 type. Sampling frequency 1Hz (once per second), storage for 1
year, 3 copies.
- Complete calculation formula: 1000 devices * 100 measurement points * 12
bytes per data point * 86400 seconds per day * 365 days per year * 3 copies/10
compression ratio=11T
diff --git a/src/UserGuide/Master/stage/Deployment-Recommendation.md
b/src/UserGuide/Master/stage/Deployment-Recommendation.md
new file mode 100644
index 0000000..5fd59f9
--- /dev/null
+++ b/src/UserGuide/Master/stage/Deployment-Recommendation.md
@@ -0,0 +1,182 @@
+<!--
+
+ Licensed to the Apache Software Foundation (ASF) under one
+ or more contributor license agreements. See the NOTICE file
+ distributed with this work for additional information
+ regarding copyright ownership. The ASF licenses this file
+ to you under the Apache License, Version 2.0 (the
+ "License"); you may not use this file except in compliance
+ with the License. You may obtain a copy of the License at
+
+ http://www.apache.org/licenses/LICENSE-2.0
+
+ Unless required by applicable law or agreed to in writing,
+ software distributed under the License is distributed on an
+ "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
+ KIND, either express or implied. See the License for the
+ specific language governing permissions and limitations
+ under the License.
+
+-->
+
+# IoTDB Deployment Recommendation
+## Backgrounds
+
+System Abilities
+- Performance: writing and reading performance, compression ratio
+- Extensibility: system has the ability to manage data with multiple nodes,
and is essentially that data can be managed by partitions
+- High availability(HA): system has the ability to tolerate the nodes
disconnected, and is essentially that the data has replicas
+- Consistency：when data is with multiple copies, whether the replicas are
consistent, and is essentially that the system treats the whole database as a
single node
+
+Abbreviations
+- C: ConfigNode
+- D: DataNode
+- nCmD：cluster with n ConfigNodes and m DataNodes
+
+## Deployment mode
+
+| mode | Performance | Extensibility |
HA | Consistency |
+|:---------------------------------------:|:---------------|:--------------|:-------|:------------|
+| Lightweight standalone mode | Extremely High | None |
None | High |
+| Scalable standalone mode (default) | High | High |
Medium | High |
+| High performance cluster mode | High | High |
High | Medium |
+| Strong consistency cluster mode | Medium | High |
High | High |
+
+
+| Config | Lightweight standalone mode |
Scalable single node mode | High performance mode | strong consistency cluster
mode |
+|:--------------------------------------:|:----------------------------|:--------------------------|:----------------------|:--------------------------------|
+| ConfigNode number | 1 | ≥1
(odd number) | ≥1 (odd number) | ≥1 (odd number)
|
+| DataNode number | 1 | ≥1
| ≥3 | ≥3 |
+| schema_replication_factor | 1 | 1
| 3 | 3 |
+| data_replication_factor | 1 | 1
| 2 | 3 |
+| config_node_consensus_protocol_class | Simple | Ratis
| Ratis | Ratis |
+| schema_region_consensus_protocol_class | Simple | Ratis
| Ratis | Ratis |
+| data_region_consensus_protocol_class | Simple | IoT
| IoT | Ratis |
+
+
+## Deployment Recommendation
+
+### Upgrade from v0.13 to v1.0
+
+Scenario:
+Already has some data under v0.13, hope to upgrade to v1.0.
+
+Options:
+1. Upgrade to 1C1D standalone mode, allocate 2GB memory to ConfigNode,
allocate same memory size with v0.13 to DataNode.
+2. Upgrade to 3C3D cluster mode, allocate 2GB memory to ConfigNode, allocate
same memory size with v0.13 to DataNode.
+
+Configuration modification:
+
+- Do not point v1.0 data directory to v0.13 data directory
+- region_group_extension_strategy=COSTOM
+- data_region_group_per_database
+ - for 3C3D cluster mode: Cluster CPU total core num /
data_replication_factor
+ - for 1C1D standalone mode: use virtual_storage_group_num in v0.13
+
+Data migration:
+After modifying the configuration, use load-tsfile tool to load the TsFiles of
v0.13 to v1.0.
+
+### Use v1.0 directly
+
+**Recommend to use 1 Database only**
+
+#### Memory estimation
+
+##### Use active series number to estimate memory size
+
+Cluster DataNode total heap size(GB) = active series number / 100000 *
data_replication_factor
+
+Heap size of each DataNode (GB) = Cluster DataNode total heap size / DataNode
number
+
+> Example: use 3C3D to manage 1 million timeseries, use 3 data replicas
+> - Cluster DataNode total heap size: 1,000,000 / 100,000 * 3 = 30G
+> - 每Heap size of each DataNode: 30 / 3 = 10G
+
+##### Use total series number to estimate memory size
+
+Cluster DataNode total heap size（B） = 20 * (180 + 2 * average character num of
the series full path) * total series number * schema_replication_factor
+
+Heap size of each DataNode = Cluster DataNode total heap size / DataNode number
+
+> Example: use 3C3D to manage 1 million timeseries, use 3 schema replicas,
series name such as root.sg_1.d_10.s_100(20 chars)
+> - Cluster DataNode total heap size: 20 * (180 + 2 * 20) * 1,000,000 * 3 =
13.2 GB
+> - Heap size of each DataNode: 13.2 GB / 3 = 4.4 GB
+
+#### Disk estimation
+
+IoTDB storage size = data storage size + schema storage size + temp storage
size
+
+##### Data storage size
+
+Series number * Sampling frequency * Data point size * Storage duration *
data_replication_factor / 10 (compression ratio)
+
+| Data Type \ Data point size | Timestamp (Byte) | Value (Byte) | Total (Byte)
|
+|:---------------------------:|:-----------------|:-------------|:-------------|
+| Boolean | 8 | 1 | 9
|
+| INT32 / FLOAT | 8 | 4 | 12
|
+| INT64）/ DOUBLE | 8 | 8 | 16
|
+| TEXT | 8 | Assuming a | 8+a
|
+
+
+> Example: 1000 devices, 100 sensors for one device, 100,000 series total,
INT32 data type, 1Hz sampling frequency, 1 year storage duration, 3 replicas,
compression ratio is 10
+> Data storage size = 1000 * 100 * 12 * 86400 * 365 * 3 / 10 = 11T
+
+##### Schema storage size
+
+One series uses the path character byte size + 20 bytes.
+If the series has tag, add the tag character byte size.
+
+##### Temp storage size
+
+Temp storage size = WAL storage size + Consensus storage size + Compaction
temp storage size
+
+1. WAL
+
+max wal storage size = memtable memory size ÷ wal_min_effective_info_ratio
+- memtable memory size is decided by datanode_memory_proportion,
storage_engine_memory_proportion and write_memory_proportion
+- wal_min_effective_info_ratio is decided by wal_min_effective_info_ratio
configuration
+
+> Example: allocate 16G memory for DataNode, config is as below:
+> datanode_memory_proportion=3:3:1:1:1:1
+> storage_engine_memory_proportion=8:2
+> write_memory_proportion=19:1
+> wal_min_effective_info_ratio=0.1
+> max wal storage size = 16 * (3 / 10) * (8 / 10) * (19 / 20) ÷ 0.1 = 36.48G
+
+2. Consensus
+
+Ratis consensus
+
+When using ratis consensus protocol, we need extra storage for Raft Log, which
will be deleted after the state machine takes snapshot.
+We can adjust `trigger_snapshot_threshold` to control the maximum Raft Log
disk usage.
+
+
+Raft Log disk size in each Region = average * trigger_snapshot_threshold
+
+The total Raft Log storage space is proportional to the data replica number
+
+> Example: DataRegion, 20kB data for one request,
data_region_trigger_snapshot_threshold = 400,000, then max Raft Log disk size =
20K * 400,000 = 8G.
+Raft Log increases from 0 to 8GB, and then turns to 0 after snapshot. Average
size will be 4GB.
+When replica number is 3, max Raft log size will be 3 * 8G = 24G.
+
+What's more, we can configure data_region_ratis_log_max_size to limit max log
size of a single DataRegion.
+By default, data_region_ratis_log_max_size=20G, which guarantees that Raft Log
size would not exceed 20G.
+
+3. Compaction
+
+- Inner space compaction
+ Disk space for temporary files = Total Disk space of origin files
+
+ > Example: 10 origin files, 100MB for each file
+ > Disk space for temporary files = 10 * 100 = 1000M
+
+
+- Outer space compaction
+ The overlap of out-of-order data = overlapped data amount / total
out-of-order data amount
+
+ Disk space for temporary file = Total ordered Disk space of origin files +
Total out-of-order disk space of origin files *（1 - overlap）
+ > Example: 10 ordered files, 10 out-of-order files, 100M for each ordered
file, 50M for each out-of-order file, half of data is overlapped with sequence
file
+ > The overlap of out-of-order data = 25M/50M * 100% = 50%
+ > Disk space for temporary files = 10 * 100 + 10 * 50 * 50% = 1250M
+
+
diff --git
a/src/UserGuide/latest/Deployment-and-Maintenance/Database-Resources.md
b/src/UserGuide/latest/Deployment-and-Maintenance/Database-Resources.md
index 6cdd4aa..d6eaa90 100644
--- a/src/UserGuide/latest/Deployment-and-Maintenance/Database-Resources.md
+++ b/src/UserGuide/latest/Deployment-and-Maintenance/Database-Resources.md
@@ -20,37 +20,164 @@
-->
# Database Resources
## CPU
-| Number of second level sequences | CPU
| Number of nodes | |
|
-| -------------------------------- |
------------------------------------------------ | --------------- | ---- |
------------------------------------------------ |
-| standalone mode | Double active
| Distributed | |
|
-| Within 100000 | 2-4 core
| 1 | 2 | 3
|
-| Within 300000 | 4-8core
| 1 | 2 | 3
|
-| Within 500000 | 8-26core
| 1 | 2 | 3
|
-| Within 1000000 | 16-32core
| 1 | 2 | 3
|
-| Within 2000000 | 32-48core
| 1 | 2 | 3
|
-| Within 10000000 | 48-core
| 1 | 2 | Please contact Timecho Business for
consultation |
-| Over 10000000 | Please contact Timecho Business for
consultation | | |
|
+<table>
+ <tr>
+ <th rowspan="2">Number of second level sequences</th>
+ <th rowspan="2">CPU</th>
+ <th colspan="3">Number of nodes</th>
+ </tr>
+ <tr>
+ <th>standalone mode</th>
+ <th>Double active</th>
+ <th>Distributed</th>
+ </tr>
+ <tr>
+ <td>Within 100000</td>
+ <td>2core-4core</td>
+ <td>1</td>
+ <td>2</td>
+ <td>3</td>
+ </tr>
+ <tr>
+ <td>Within 300000</td>
+ <td>4core-8core</td>
+ <td>1</td>
+ <td>2</td>
+ <td>3</td>
+ </tr>
+ <tr>
+ <td>Within 500000</td>
+ <td>8core-26core</td>
+ <td>1</td>
+ <td>2</td>
+ <td>3</td>
+ </tr>
+ <tr>
+ <td>Within 1000000</td>
+ <td>16core-32core</td>
+ <td>1</td>
+ <td>2</td>
+ <td>3</td>
+ </tr>
+ <tr>
+ <td>Within 2000000</td>
+ <td>32core-48core</td>
+ <td>1</td>
+ <td>2</td>
+ <td>3</td>
+ </tr>
+ <tr>
+ <td>Within 10000000</td>
+ <td>48core</td>
+ <td>1</td>
+ <td>2</td>
+ <td>Please contact Timecho Business for consultation</td>
+ </tr>
+ <tr>
+ <td>Over 10000000</td>
+ <td colspan="4">Please contact Timecho Business for
consultation</td>
+ </tr>
+</table>
+
## Memory
-| Number of second level sequences | Memory
| Number of nodes | |
|
-| -------------------------------- |
------------------------------------------------ | --------------- | ---- |
------------------------------------------------ |
-| standalone mode | Double active
| Distributed | |
|
-| Within 100000 | 4G-8G
| 1 | 2 | 3
|
-| Within 300000 | 12G-32G
| 1 | 2 | 3
|
-| Within 500000 | 24G-48G
| 1 | 2 | 3
|
-| Within 1000000 | 32G-96G
| 1 | 2 | 3
|
-| Within 2000000 | 64G-128G
| 1 | 2 | 3
|
-| Within 10000000 | 128G
| 1 | 2 | Please contact Timecho Business for
consultation |
-| 1000w以上Over 10000000 | Please contact Timecho Business for
consultation | | |
|
+<table>
+ <tr>
+ <th rowspan="2">Number of second level sequences</th>
+ <th rowspan="2">Memory</th>
+ <th colspan="3">Number of nodes</th>
+ </tr>
+ <tr>
+ <th>standalone mode</th>
+ <th>Double active</th>
+ <th>Distributed</th>
+ </tr>
+ <tr>
+ <td>Within 100000</td>
+ <td>4G-8G</td>
+ <td>1</td>
+ <td>2</td>
+ <td>3</td>
+ </tr>
+ <tr>
+ <td>Within 300000</td>
+ <td>12G-32G</td>
+ <td>1</td>
+ <td>2</td>
+ <td>3</td>
+ </tr>
+ <tr>
+ <td>Within 500000</td>
+ <td>24G-48G</td>
+ <td>1</td>
+ <td>2</td>
+ <td>3</td>
+ </tr>
+ <tr>
+ <td>Within 1000000</td>
+ <td>32G-96G</td>
+ <td>1</td>
+ <td>2</td>
+ <td>3</td>
+ </tr>
+ <tr>
+ <td>Within 2000000</td>
+ <td>64G-128G</td>
+ <td>1</td>
+ <td>2</td>
+ <td>3</td>
+ </tr>
+ <tr>
+ <td>Within 10000000</td>
+ <td>128G</td>
+ <td>1</td>
+ <td>2</td>
+ <td>Please contact Timecho Business for consultation</td>
+ </tr>
+ <tr>
+ <td>Over 10000000</td>
+ <td colspan="4">Please contact Timecho Business for
consultation</td>
+ </tr>
+</table>
+
## Storage (Disk)
### Storage space
Calculation formula: Number of measurement points * Sampling frequency (Hz) *
Size of each data point (Byte, different data types may vary, see table below)
* Storage time (seconds) * Number of copies (usually 1 copy for a single node
and 2 copies for a cluster) ÷ Compression ratio (can be estimated at 5-10
times, but may be higher in actual situations)
-| Data point size calculation table | | |
|
-| --------------------------------- | ----------------- | ---------------- |
------------------------------------ |
-| data type | Timestamp (Bytes) | Value (Bytes) |
Total size of data points (in bytes) |
-| Boolean | 8 | 1 | 9
|
-| INT32）/FLOAT | 8 | 4 | 12
|
-| INT64/DOUBLE | 8 | 8 |
16 |
-| TEXT | 8 | The average is a |
8+a |
+<table>
+ <tr>
+ <th colspan="4">Data point size calculation</th>
+ </tr>
+ <tr>
+ <th>data type</th>
+ <th>Timestamp (Bytes)</th>
+ <th> Value (Bytes)</th>
+ <th> Total size of data points (in bytes)
+ </th>
+ </tr>
+ <tr>
+ <td>Boolean</td>
+ <td>8</td>
+ <td>1</td>
+ <td>9</td>
+ </tr>
+ <tr>
+ <td> INT32/FLOAT</td>
+ <td>8</td>
+ <td>4</td>
+ <td>12</td>
+ </tr>
+ <tr>
+ <td>INT64/DOUBLE</td>
+ <td>8</td>
+ <td>8</td>
+ <td>16</td>
+ </tr>
+ <tr>
+ <td>TEXT</td>
+ <td>8</td>
+ <td>The average is a</td>
+ <td>8+a</td>
+ </tr>
+</table>
Example: 1000 devices, each with 100 measurement points, a total of 100000
sequences, INT32 type. Sampling frequency 1Hz (once per second), storage for 1
year, 3 copies.
- Complete calculation formula: 1000 devices * 100 measurement points * 12
bytes per data point * 86400 seconds per day * 365 days per year * 3 copies/10
compression ratio=11T
diff --git a/src/UserGuide/latest/stage/Deployment-Recommendation.md
b/src/UserGuide/latest/stage/Deployment-Recommendation.md
new file mode 100644
index 0000000..5fd59f9
--- /dev/null
+++ b/src/UserGuide/latest/stage/Deployment-Recommendation.md
@@ -0,0 +1,182 @@
+<!--
+
+ Licensed to the Apache Software Foundation (ASF) under one
+ or more contributor license agreements. See the NOTICE file
+ distributed with this work for additional information
+ regarding copyright ownership. The ASF licenses this file
+ to you under the Apache License, Version 2.0 (the
+ "License"); you may not use this file except in compliance
+ with the License. You may obtain a copy of the License at
+
+ http://www.apache.org/licenses/LICENSE-2.0
+
+ Unless required by applicable law or agreed to in writing,
+ software distributed under the License is distributed on an
+ "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
+ KIND, either express or implied. See the License for the
+ specific language governing permissions and limitations
+ under the License.
+
+-->
+
+# IoTDB Deployment Recommendation
+## Backgrounds
+
+System Abilities
+- Performance: writing and reading performance, compression ratio
+- Extensibility: system has the ability to manage data with multiple nodes,
and is essentially that data can be managed by partitions
+- High availability(HA): system has the ability to tolerate the nodes
disconnected, and is essentially that the data has replicas
+- Consistency：when data is with multiple copies, whether the replicas are
consistent, and is essentially that the system treats the whole database as a
single node
+
+Abbreviations
+- C: ConfigNode
+- D: DataNode
+- nCmD：cluster with n ConfigNodes and m DataNodes
+
+## Deployment mode
+
+| mode | Performance | Extensibility |
HA | Consistency |
+|:---------------------------------------:|:---------------|:--------------|:-------|:------------|
+| Lightweight standalone mode | Extremely High | None |
None | High |
+| Scalable standalone mode (default) | High | High |
Medium | High |
+| High performance cluster mode | High | High |
High | Medium |
+| Strong consistency cluster mode | Medium | High |
High | High |
+
+
+| Config | Lightweight standalone mode |
Scalable single node mode | High performance mode | strong consistency cluster
mode |
+|:--------------------------------------:|:----------------------------|:--------------------------|:----------------------|:--------------------------------|
+| ConfigNode number | 1 | ≥1
(odd number) | ≥1 (odd number) | ≥1 (odd number)
|
+| DataNode number | 1 | ≥1
| ≥3 | ≥3 |
+| schema_replication_factor | 1 | 1
| 3 | 3 |
+| data_replication_factor | 1 | 1
| 2 | 3 |
+| config_node_consensus_protocol_class | Simple | Ratis
| Ratis | Ratis |
+| schema_region_consensus_protocol_class | Simple | Ratis
| Ratis | Ratis |
+| data_region_consensus_protocol_class | Simple | IoT
| IoT | Ratis |
+
+
+## Deployment Recommendation
+
+### Upgrade from v0.13 to v1.0
+
+Scenario:
+Already has some data under v0.13, hope to upgrade to v1.0.
+
+Options:
+1. Upgrade to 1C1D standalone mode, allocate 2GB memory to ConfigNode,
allocate same memory size with v0.13 to DataNode.
+2. Upgrade to 3C3D cluster mode, allocate 2GB memory to ConfigNode, allocate
same memory size with v0.13 to DataNode.
+
+Configuration modification:
+
+- Do not point v1.0 data directory to v0.13 data directory
+- region_group_extension_strategy=COSTOM
+- data_region_group_per_database
+ - for 3C3D cluster mode: Cluster CPU total core num /
data_replication_factor
+ - for 1C1D standalone mode: use virtual_storage_group_num in v0.13
+
+Data migration:
+After modifying the configuration, use load-tsfile tool to load the TsFiles of
v0.13 to v1.0.
+
+### Use v1.0 directly
+
+**Recommend to use 1 Database only**
+
+#### Memory estimation
+
+##### Use active series number to estimate memory size
+
+Cluster DataNode total heap size(GB) = active series number / 100000 *
data_replication_factor
+
+Heap size of each DataNode (GB) = Cluster DataNode total heap size / DataNode
number
+
+> Example: use 3C3D to manage 1 million timeseries, use 3 data replicas
+> - Cluster DataNode total heap size: 1,000,000 / 100,000 * 3 = 30G
+> - 每Heap size of each DataNode: 30 / 3 = 10G
+
+##### Use total series number to estimate memory size
+
+Cluster DataNode total heap size（B） = 20 * (180 + 2 * average character num of
the series full path) * total series number * schema_replication_factor
+
+Heap size of each DataNode = Cluster DataNode total heap size / DataNode number
+
+> Example: use 3C3D to manage 1 million timeseries, use 3 schema replicas,
series name such as root.sg_1.d_10.s_100(20 chars)
+> - Cluster DataNode total heap size: 20 * (180 + 2 * 20) * 1,000,000 * 3 =
13.2 GB
+> - Heap size of each DataNode: 13.2 GB / 3 = 4.4 GB
+
+#### Disk estimation
+
+IoTDB storage size = data storage size + schema storage size + temp storage
size
+
+##### Data storage size
+
+Series number * Sampling frequency * Data point size * Storage duration *
data_replication_factor / 10 (compression ratio)
+
+| Data Type \ Data point size | Timestamp (Byte) | Value (Byte) | Total (Byte)
|
+|:---------------------------:|:-----------------|:-------------|:-------------|
+| Boolean | 8 | 1 | 9
|
+| INT32 / FLOAT | 8 | 4 | 12
|
+| INT64）/ DOUBLE | 8 | 8 | 16
|
+| TEXT | 8 | Assuming a | 8+a
|
+
+
+> Example: 1000 devices, 100 sensors for one device, 100,000 series total,
INT32 data type, 1Hz sampling frequency, 1 year storage duration, 3 replicas,
compression ratio is 10
+> Data storage size = 1000 * 100 * 12 * 86400 * 365 * 3 / 10 = 11T
+
+##### Schema storage size
+
+One series uses the path character byte size + 20 bytes.
+If the series has tag, add the tag character byte size.
+
+##### Temp storage size
+
+Temp storage size = WAL storage size + Consensus storage size + Compaction
temp storage size
+
+1. WAL
+
+max wal storage size = memtable memory size ÷ wal_min_effective_info_ratio
+- memtable memory size is decided by datanode_memory_proportion,
storage_engine_memory_proportion and write_memory_proportion
+- wal_min_effective_info_ratio is decided by wal_min_effective_info_ratio
configuration
+
+> Example: allocate 16G memory for DataNode, config is as below:
+> datanode_memory_proportion=3:3:1:1:1:1
+> storage_engine_memory_proportion=8:2
+> write_memory_proportion=19:1
+> wal_min_effective_info_ratio=0.1
+> max wal storage size = 16 * (3 / 10) * (8 / 10) * (19 / 20) ÷ 0.1 = 36.48G
+
+2. Consensus
+
+Ratis consensus
+
+When using ratis consensus protocol, we need extra storage for Raft Log, which
will be deleted after the state machine takes snapshot.
+We can adjust `trigger_snapshot_threshold` to control the maximum Raft Log
disk usage.
+
+
+Raft Log disk size in each Region = average * trigger_snapshot_threshold
+
+The total Raft Log storage space is proportional to the data replica number
+
+> Example: DataRegion, 20kB data for one request,
data_region_trigger_snapshot_threshold = 400,000, then max Raft Log disk size =
20K * 400,000 = 8G.
+Raft Log increases from 0 to 8GB, and then turns to 0 after snapshot. Average
size will be 4GB.
+When replica number is 3, max Raft log size will be 3 * 8G = 24G.
+
+What's more, we can configure data_region_ratis_log_max_size to limit max log
size of a single DataRegion.
+By default, data_region_ratis_log_max_size=20G, which guarantees that Raft Log
size would not exceed 20G.
+
+3. Compaction
+
+- Inner space compaction
+ Disk space for temporary files = Total Disk space of origin files
+
+ > Example: 10 origin files, 100MB for each file
+ > Disk space for temporary files = 10 * 100 = 1000M
+
+
+- Outer space compaction
+ The overlap of out-of-order data = overlapped data amount / total
out-of-order data amount
+
+ Disk space for temporary file = Total ordered Disk space of origin files +
Total out-of-order disk space of origin files *（1 - overlap）
+ > Example: 10 ordered files, 10 out-of-order files, 100M for each ordered
file, 50M for each out-of-order file, half of data is overlapped with sequence
file
+ > The overlap of out-of-order data = 25M/50M * 100% = 50%
+ > Disk space for temporary files = 10 * 100 + 10 * 50 * 50% = 1250M
+
+
diff --git
a/src/zh/UserGuide/Master/Deployment-and-Maintenance/Database-Resources.md
b/src/zh/UserGuide/Master/Deployment-and-Maintenance/Database-Resources.md
index 7fe7d8e..4e36197 100644
--- a/src/zh/UserGuide/Master/Deployment-and-Maintenance/Database-Resources.md
+++ b/src/zh/UserGuide/Master/Deployment-and-Maintenance/Database-Resources.md
@@ -20,37 +20,162 @@
-->
# 资源规划
## CPU
-| 秒级序列数 | CPU | 节点数 | | |
-| ---------- | ------------------ | ------ | ---- | ------------------ |
-| 单机 | 双活 | 分布式 | | |
-| 10w以内 | 2核-4核 | 1 | 2 | 3 |
-| 30w以内 | 4核-8核 | 1 | 2 | 3 |
-| 50w以内 | 8核-16核 | 1 | 2 | 3 |
-| 100w以内 | 16核-32核 | 1 | 2 | 3 |
-| 200w以内 | 32核-48核 | 1 | 2 | 3 |
-| 1000w以内 | 48核 | 1 | 2 | 请联系天谋商务咨询 |
-| 1000w以上 | 请联系天谋商务咨询 | | | |
+<table>
+ <tr>
+ <th rowspan="2">秒级序列数</th>
+ <th rowspan="2">CPU</th>
+ <th colspan="3">节点数</th>
+ </tr>
+ <tr>
+ <th>单机</th>
+ <th>双活</th>
+ <th>分布式</th>
+ </tr>
+ <tr>
+ <td>10W以内</td>
+ <td>2核-4核</td>
+ <td>1</td>
+ <td>2</td>
+ <td>3</td>
+ </tr>
+ <tr>
+ <td>30W以内</td>
+ <td>4核-8核</td>
+ <td>1</td>
+ <td>2</td>
+ <td>3</td>
+ </tr>
+ <tr>
+ <td>50W以内</td>
+ <td>8核-16核</td>
+ <td>1</td>
+ <td>2</td>
+ <td>3</td>
+ </tr>
+ <tr>
+ <td>100W以内</td>
+ <td>16核-32核</td>
+ <td>1</td>
+ <td>2</td>
+ <td>3</td>
+ </tr>
+ <tr>
+ <td>200w以内</td>
+ <td>32核-48核</td>
+ <td>1</td>
+ <td>2</td>
+ <td>3</td>
+ </tr>
+ <tr>
+ <td>1000w以内</td>
+ <td>48核</td>
+ <td>1</td>
+ <td>2</td>
+ <td>请联系天谋商务咨询</td>
+ </tr>
+ <tr>
+ <td>1000w以上</td>
+ <th colspan="4">请联系天谋商务咨询</th>
+ </tr>
+</table>
+
## 内存
-| 秒级序列数 | 内存 | 节点数 | | |
-| ---------- | ------------------ | ------ | ---- | ------------------ |
-| 单机 | 双活 | 分布式 | | |
-| 10w以内 | 4G-8G | 1 | 2 | 3 |
-| 30w以内 | 12G-32G | 1 | 2 | 3 |
-| 50w以内 | 24G-48G | 1 | 2 | 3 |
-| 100w以内 | 32G-96G | 1 | 2 | 3 |
-| 200w以内 | 64G-128G | 1 | 2 | 3 |
-| 1000w以内 | 128G | 1 | 2 | 请联系天谋商务咨询 |
-| 1000w以上 | 请联系天谋商务咨询 | | | |
+<table>
+ <tr>
+ <th rowspan="2">秒级序列数</th>
+ <th rowspan="2">内存</th>
+ <th colspan="3">节点数</th>
+ </tr>
+ <tr>
+ <th>单机</th>
+ <th>双活</th>
+ <th>分布式</th>
+ </tr>
+ <tr>
+ <td>10W以内</td>
+ <td>4G-8G</td>
+ <td>1</td>
+ <td>2</td>
+ <td>3</td>
+ </tr>
+ <tr>
+ <td>30W以内</td>
+ <td>12G-32G</td>
+ <td>1</td>
+ <td>2</td>
+ <td>3</td>
+ </tr>
+ <tr>
+ <td>50W以内</td>
+ <td>24G-48G</td>
+ <td>1</td>
+ <td>2</td>
+ <td>3</td>
+ </tr>
+ <tr>
+ <td>100W以内</td>
+ <td>32G-96G</td>
+ <td>1</td>
+ <td>2</td>
+ <td>3</td>
+ </tr>
+ <tr>
+ <td>200w以内</td>
+ <td>64G-128G</td>
+ <td>1</td>
+ <td>2</td>
+ <td>3</td>
+ </tr>
+ <tr>
+ <td>1000w以内</td>
+ <td>128G</td>
+ <td>1</td>
+ <td>2</td>
+ <td>请联系天谋商务咨询</td>
+ </tr>
+ <tr>
+ <td>1000w以上</td>
+ <th colspan="4">请联系天谋商务咨询</th>
+ </tr>
+</table>
+
## 存储(磁盘)
### 存储空间
-计算公式：测点数量 * 采样频率（Hz）* 每个数据点大小（Byte，不同数据类型不一样，见下表） * 存储时长（秒） *
副本数（一般单节点为1副本，集群为2副本）÷ 压缩比（可按5-10倍估算，实际情况可能更高）
-| 数据点大小计算表 | | |
|
-| -------------------------------------- | -------------- | ---------- |
-------------------- |
-| 数据类型 | 时间戳（字节） | 值（字节） | 数据点总大小（字节） |
-| 开关量（Boolean） | 8 | 1 | 9
|
-| 整型（INT32）/单精度浮点数（FLOAT） | 8 | 4 | 12
|
-| 长整型（INT64）/双精度浮点数（DOUBLE） | 8 | 8 | 16
|
-| 字符串（TEXT） | 8 | 平均为 a | 8+a
|
+<table>
+ <tr>
+ <th colspan="4"> 数据点大小计算表 </th>
+ </tr>
+ <tr>
+ <td> 数据类型 </td>
+ <td>时间戳（字节）</td>
+ <td>值（字节）</td>
+ <td>数据点总大小（字节）</td>
+ </tr>
+ <tr>
+ <td>开关量（Boolean）</td>
+ <td>8</td>
+ <td>1</td>
+ <td>9</td>
+ </tr>
+ <tr>
+ <td>整型（INT32）/单精度浮点数（FLOAT）</td>
+ <td>8</td>
+ <td>4</td>
+ <td>12</td>
+ </tr>
+ <tr>
+ <td>长整型（INT64）/双精度浮点数（DOUBLE）</td>
+ <td>8</td>
+ <td>8</td>
+ <td>16</td>
+ </tr>
+ <tr>
+ <td>字符串（TEXT）</td>
+ <td>8</td>
+ <td>平均为a</td>
+ <td>8+a</td>
+ </tr>
+</table>
示例：1000设备，每个设备100 测点，共 100000 序列，INT32 类型。采样频率1Hz（每秒一次），存储1年，3副本。
- 完整计算公式：1000设备*100测点*12字节每数据点*86400秒每天*365天每年*3副本/10压缩比=11T
diff --git a/src/zh/UserGuide/Master/stage/Deployment-Recommendation.md
b/src/zh/UserGuide/Master/stage/Deployment-Recommendation.md
new file mode 100644
index 0000000..74f39c9
--- /dev/null
+++ b/src/zh/UserGuide/Master/stage/Deployment-Recommendation.md
@@ -0,0 +1,178 @@
+<!--
+
+ Licensed to the Apache Software Foundation (ASF) under one
+ or more contributor license agreements. See the NOTICE file
+ distributed with this work for additional information
+ regarding copyright ownership. The ASF licenses this file
+ to you under the Apache License, Version 2.0 (the
+ "License"); you may not use this file except in compliance
+ with the License. You may obtain a copy of the License at
+
+ http://www.apache.org/licenses/LICENSE-2.0
+
+ Unless required by applicable law or agreed to in writing,
+ software distributed under the License is distributed on an
+ "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
+ KIND, either express or implied. See the License for the
+ specific language governing permissions and limitations
+ under the License.
+
+-->
+
+# IoTDB 部署推荐
+## 背景
+
+系统能力
+- 性能需求：系统读写速度，压缩比
+- 扩展性：系统能够用多节点管理数据，本质上是数据是否可分区管理
+- 高可用：系统能够容忍节点失效，本质上是数据是否有副本
+- 一致性：当数据有多副本时，不同副本是否一致，本质上用户是否能将数据库当做单机看待
+
+缩写
+- C：ConfigNode
+- D：DataNode
+- aCbD：a 个 ConfigNode 和 b 个 DataNode
+
+## 部署模式选型
+
+| 模式 | 性能 | 扩展性 | 高可用 | 一致性 |
+|:------------:|:----|:----|:----|:----|
+| 轻量单机模式 | 最高 | 无 | 无 | 高 |
+| 可扩展单节点模式 （默认） | 高 | 高 | 中 | 高 |
+| 高性能分布式模式 | 高 | 高 | 高 | 中 |
+| 强一致分布式模式 | 中 | 高 | 高 | 高 |
+
+
+| 配置 | 轻量单机模式 | 可扩展单节点模式 |
高性能分布式模式 | 强一致分布式模式 |
+|:------------------------------------------------------:|:-------|:---------|:---------|:---------|
+| ConfigNode 个数 | 1 | ≥1 （奇数） |
≥1 （奇数） | ≥1（奇数） |
+| DataNode 个数 | 1 | ≥1 |
≥3 | ≥3 |
+| 元数据副本 schema_replication_factor | 1 | 1 |
3 | 3 |
+| 数据副本 data_replication_factor | 1 | 1 |
2 | 3 |
+| ConfigNode 协议 config_node_consensus_protocol_class | Simple | Ratis |
Ratis | Ratis |
+| SchemaRegion 协议 schema_region_consensus_protocol_class | Simple | Ratis |
Ratis | Ratis |
+| DataRegion 协议 data_region_consensus_protocol_class | Simple | IoT |
IoT | Ratis |
+
+
+## 部署配置推荐
+
+### 从 0.13 版本升级到 1.0
+
+场景：
+已在 0.13 版本存储了部分数据，希望迁移到 1.0 版本，并且与 0.13 表现保持一致。
+
+可选方案：
+1. 升级到 1C1D 单机版，ConfigNode 分配 2G 内存，DataNode 与 0.13 一致。
+2. 升级到 3C3D 高性能分布式，ConfigNode 分配 2G 内存，DataNode 与 0.13 一致。
+
+配置修改：
+1.0 配置参数修改：
+- 数据目录不要指向0.13原有数据目录
+- region_group_extension_strategy=COSTOM
+- data_region_group_per_database
+ - 如果是 3C3D 高性能分布式：则改为：集群 CPU 总核数/ 数据副本数
+ - 如果是 1C1D，则改为：等于 0.13 的 virtual_storage_group_num 即可 （"database"一词 与 0.13
中的 "sg" 同义）
+
+数据迁移：
+配置修改完成后，通过 load-tsfile 工具将 0.13 的 TsFile 都加载进 1.0 的 IoTDB 中，即可使用。
+
+### 直接使用 1.0
+
+**推荐用户仅设置 1 个 Database**
+
+#### 内存设置方法
+##### 根据活跃序列数估计内存
+
+集群 DataNode 总堆内内存（GB） = 活跃序列数/100000 * 数据副本数
+
+每个 DataNode 堆内内存（GB）= 集群DataNode总堆内内存 / DataNode 个数
+
+> 假设需要用3C3D管理100万条序列，数据采用3副本，则：
+> - 集群 DataNode 总堆内内存（GB）：1,000,000 / 100,000 * 3 = 30G
+> - 每台 DataNode 的堆内内存配置为：30 / 3 = 10G
+
+##### 根据总序列数估计内存
+
+集群 DataNode 总堆内内存 （B） = 20 * （180 + 2 * 序列的全路径的平均字符数）* 序列总量 * 元数据副本数
+
+每个 DataNode 内存配置推荐：集群 DataNode 总堆内内存 / DataNode 数目
+
+> 假设需要用3C3D管理100万条序列，元数据采用3副本，序列名形如 root.sg_1.d_10.s_100（约20字符），则：
+> - 集群 DataNode 总堆内内存：20 * （180 + 2 * 20）* 1,000,000 * 3 = 13.2 GB
+> - 每台 DataNode 的堆内内存配置为：13.2 GB / 3 = 4.4 GB
+
+#### 磁盘估计
+
+IoTDB 存储空间=数据存储空间 + 元数据存储空间 + 临时存储空间
+
+##### 数据磁盘空间
+
+序列数量 * 采样频率 * 每个数据点大小 * 存储时长 * 副本数 / 10 倍压缩比
+
+| 数据类型 \ 数据点大小 | 时间戳（字节） | 值（字节） | 总共（字节） |
+|:-------------------------:|:--------|:------|:-------|
+| 开关量（Boolean） | 8 | 1 | 9 |
+| 整型（INT32）/单精度浮点数（FLOAT） | 8 | 4 | 12 |
+| 长整型（INT64）/双精度浮点数（DOUBLE） | 8 | 8 | 16 |
+| 字符串（TEXT） | 8 | 假设为 a | 8+a |
+
+
+> 示例：1000设备，每个设备100 测点，共 100000 序列。整型。采样频率1Hz（每秒一次），存储1年，3副本，压缩比按 10
算，则数据存储空间占用：
+> * 简版：1000 * 100 * 12 * 86400 * 365 * 3 / 10 = 11T
+> * 完整版：1000设备 * 100测点 * 12字节每数据点 * 86400秒每天 * 365天每年 * 3副本 / 10压缩比 = 11T
+
+##### 元数据磁盘空间
+
+每条序列在磁盘日志文件中大约占用 序列字符数 + 20 字节。
+若序列有tag描述信息，则仍需加上约 tag 总字符数字节的空间。
+
+##### 临时磁盘空间
+
+临时磁盘空间 = 写前日志 + 共识协议 + 合并临时空间
+
+1. 写前日志
+
+最大写前日志空间占用 = memtable 总内存占用 ÷ 最小有效信息占比
+- memtable 总内存占用和
datanode_memory_proportion、storage_engine_memory_proportion、write_memory_proportion
三个参数有关
+- 最小有效信息占比由 wal_min_effective_info_ratio 决定
+
+> 示例：为 IoTDB 分配 16G 内存，配置文件如下
+> datanode_memory_proportion=3:3:1:1:1:1
+> storage_engine_memory_proportion=8:2
+> write_memory_proportion=19:1
+> wal_min_effective_info_ratio=0.1
+> 最大写前日志空间占用 = 16 * (3 / 10) * (8 / 10) * (19 / 20) ÷ 0.1 = 36.48G
+
+2. 共识协议
+
+Ratis共识协议
+采用Ratis共识协议的情况下，需要额外磁盘空间存储Raft Log。Raft Log会在每一次状态机 Snapshot 之后删除，因此可以通过调整
trigger_snapshot_threshold 参数控制Raft Log最大空间占用。
+
+每一个 Region Raft Log占用最大空间 = 平均请求大小 * trigger_snapshot_threshold。
+集群中一个Region总的Raft Log占用空间和Raft数据副本数成正比。
+
+> 示例：DataRegion, 平均每一次插入20k数据，data_region_trigger_snapshot_threshold =
400,000，那么Raft Log最大占用 = 20K * 400,000 = 8G。
+Raft Log会从0增长到8G，接着在snapshot之后重新变成0。平均占用为4G。
+当副本数为3时，集群中这个DataRegion总Raft Log最大占用 3 * 8G = 24G。
+
+此外，可以通过data_region_ratis_log_max_size规定每一个DataRegion的Raft Log磁盘占用最大值，
+默认为20G，能够保障运行全程中单DataRegion Raft Log总大小不超过20G。
+
+3. 合并临时空间
+
+ - 空间内合并
+ 临时文件的磁盘空间 = 源文件大小总和
+
+ > 示例：10个源文件，每个文件大小为100M
+ > 临时文件的磁盘空间 = 10 * 100 = 1000M
+
+
+ - 跨空间合并
+ 跨空间合并的临时文件大小与源文件大小和顺乱序数据的重叠度有关，当乱序数据与顺序数据有相同的时间戳时，就认为有重叠。
+ 乱序数据的重叠度 = 重叠的乱序数据量 / 总的乱序数据量
+
+ 临时文件的磁盘空间 = 源顺序文件总大小 + 源乱序文件总大小 *（1 - 重叠度）
+ > 示例：10个顺序文件，10个乱序文件，每个顺序文件100M，每个乱序文件50M，每个乱序文件里有一半的数据与顺序文件有相同的时间戳
+ > 乱序数据的重叠度 = 25M/50M * 100% = 50%
+ > 临时文件的磁盘空间 = 10 * 100 + 10 * 50 * 50% = 1250M
+
diff --git
a/src/zh/UserGuide/latest/Deployment-and-Maintenance/Database-Resources.md
b/src/zh/UserGuide/latest/Deployment-and-Maintenance/Database-Resources.md
index 7fe7d8e..f008dc7 100644
--- a/src/zh/UserGuide/latest/Deployment-and-Maintenance/Database-Resources.md
+++ b/src/zh/UserGuide/latest/Deployment-and-Maintenance/Database-Resources.md
@@ -19,38 +19,68 @@
-->
# 资源规划
-## CPU
-| 秒级序列数 | CPU | 节点数 | | |
-| ---------- | ------------------ | ------ | ---- | ------------------ |
-| 单机 | 双活 | 分布式 | | |
-| 10w以内 | 2核-4核 | 1 | 2 | 3 |
-| 30w以内 | 4核-8核 | 1 | 2 | 3 |
-| 50w以内 | 8核-16核 | 1 | 2 | 3 |
-| 100w以内 | 16核-32核 | 1 | 2 | 3 |
-| 200w以内 | 32核-48核 | 1 | 2 | 3 |
-| 1000w以内 | 48核 | 1 | 2 | 请联系天谋商务咨询 |
-| 1000w以上 | 请联系天谋商务咨询 | | | |
+<table>
+ <tr>
+ <th rowspan="2">秒级序列数</th>
+ <th rowspan="2">CPU</th>
+ <th colspan="3">节点数</th>
+ </tr>
+ <tr>
+ <th>单机</th>
+ <th>双活</th>
+ <th>分布式</th>
+ </tr>
+ <tr>
+ <td>10W以内</td>
+ <td>2核-4核</td>
+ <td>1</td>
+ <td>2</td>
+ <td>3</td>
+ </tr>
+ <tr>
+ <td>30W以内</td>
+ <td>4核-8核</td>
+ <td>1</td>
+ <td>2</td>
+ <td>3</td>
+ </tr>
+ <tr>
+ <td>50W以内</td>
+ <td>8核-16核</td>
+ <td>1</td>
+ <td>2</td>
+ <td>3</td>
+ </tr>
+ <tr>
+ <td>100W以内</td>
+ <td>16核-32核</td>
+ <td>1</td>
+ <td>2</td>
+ <td>3</td>
+ </tr>
+ <tr>
+ <td>200w以内</td>
+ <td>32核-48核</td>
+ <td>1</td>
+ <td>2</td>
+ <td>3</td>
+ </tr>
+ <tr>
+ <td>1000w以内</td>
+ <td>48核</td>
+ <td>1</td>
+ <td>2</td>
+ <td>请联系天谋商务咨询</td>
+ </tr>
+ <tr>
+ <td>1000w以上</td>
+ <th colspan="4">请联系天谋商务咨询</th>
+ </tr>
+</table>
+
## 内存
-| 秒级序列数 | 内存 | 节点数 | | |
-| ---------- | ------------------ | ------ | ---- | ------------------ |
-| 单机 | 双活 | 分布式 | | |
-| 10w以内 | 4G-8G | 1 | 2 | 3 |
-| 30w以内 | 12G-32G | 1 | 2 | 3 |
-| 50w以内 | 24G-48G | 1 | 2 | 3 |
-| 100w以内 | 32G-96G | 1 | 2 | 3 |
-| 200w以内 | 64G-128G | 1 | 2 | 3 |
-| 1000w以内 | 128G | 1 | 2 | 请联系天谋商务咨询 |
-| 1000w以上 | 请联系天谋商务咨询 | | | |
## 存储(磁盘)
### 存储空间
-计算公式：测点数量 * 采样频率（Hz）* 每个数据点大小（Byte，不同数据类型不一样，见下表） * 存储时长（秒） *
副本数（一般单节点为1副本，集群为2副本）÷ 压缩比（可按5-10倍估算，实际情况可能更高）
-| 数据点大小计算表 | | |
|
-| -------------------------------------- | -------------- | ---------- |
-------------------- |
-| 数据类型 | 时间戳（字节） | 值（字节） | 数据点总大小（字节） |
-| 开关量（Boolean） | 8 | 1 | 9
|
-| 整型（INT32）/单精度浮点数（FLOAT） | 8 | 4 | 12
|
-| 长整型（INT64）/双精度浮点数（DOUBLE） | 8 | 8 | 16
|
-| 字符串（TEXT） | 8 | 平均为 a | 8+a
|
示例：1000设备，每个设备100 测点，共 100000 序列，INT32 类型。采样频率1Hz（每秒一次），存储1年，3副本。
- 完整计算公式：1000设备*100测点*12字节每数据点*86400秒每天*365天每年*3副本/10压缩比=11T
diff --git a/src/zh/UserGuide/latest/stage/Deployment-Recommendation.md
b/src/zh/UserGuide/latest/stage/Deployment-Recommendation.md
new file mode 100644
index 0000000..74f39c9
--- /dev/null
+++ b/src/zh/UserGuide/latest/stage/Deployment-Recommendation.md
@@ -0,0 +1,178 @@
+<!--
+
+ Licensed to the Apache Software Foundation (ASF) under one
+ or more contributor license agreements. See the NOTICE file
+ distributed with this work for additional information
+ regarding copyright ownership. The ASF licenses this file
+ to you under the Apache License, Version 2.0 (the
+ "License"); you may not use this file except in compliance
+ with the License. You may obtain a copy of the License at
+
+ http://www.apache.org/licenses/LICENSE-2.0
+
+ Unless required by applicable law or agreed to in writing,
+ software distributed under the License is distributed on an
+ "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
+ KIND, either express or implied. See the License for the
+ specific language governing permissions and limitations
+ under the License.
+
+-->
+
+# IoTDB 部署推荐
+## 背景
+
+系统能力
+- 性能需求：系统读写速度，压缩比
+- 扩展性：系统能够用多节点管理数据，本质上是数据是否可分区管理
+- 高可用：系统能够容忍节点失效，本质上是数据是否有副本
+- 一致性：当数据有多副本时，不同副本是否一致，本质上用户是否能将数据库当做单机看待
+
+缩写
+- C：ConfigNode
+- D：DataNode
+- aCbD：a 个 ConfigNode 和 b 个 DataNode
+
+## 部署模式选型
+
+| 模式 | 性能 | 扩展性 | 高可用 | 一致性 |
+|:------------:|:----|:----|:----|:----|
+| 轻量单机模式 | 最高 | 无 | 无 | 高 |
+| 可扩展单节点模式 （默认） | 高 | 高 | 中 | 高 |
+| 高性能分布式模式 | 高 | 高 | 高 | 中 |
+| 强一致分布式模式 | 中 | 高 | 高 | 高 |
+
+
+| 配置 | 轻量单机模式 | 可扩展单节点模式 |
高性能分布式模式 | 强一致分布式模式 |
+|:------------------------------------------------------:|:-------|:---------|:---------|:---------|
+| ConfigNode 个数 | 1 | ≥1 （奇数） |
≥1 （奇数） | ≥1（奇数） |
+| DataNode 个数 | 1 | ≥1 |
≥3 | ≥3 |
+| 元数据副本 schema_replication_factor | 1 | 1 |
3 | 3 |
+| 数据副本 data_replication_factor | 1 | 1 |
2 | 3 |
+| ConfigNode 协议 config_node_consensus_protocol_class | Simple | Ratis |
Ratis | Ratis |
+| SchemaRegion 协议 schema_region_consensus_protocol_class | Simple | Ratis |
Ratis | Ratis |
+| DataRegion 协议 data_region_consensus_protocol_class | Simple | IoT |
IoT | Ratis |
+
+
+## 部署配置推荐
+
+### 从 0.13 版本升级到 1.0
+
+场景：
+已在 0.13 版本存储了部分数据，希望迁移到 1.0 版本，并且与 0.13 表现保持一致。
+
+可选方案：
+1. 升级到 1C1D 单机版，ConfigNode 分配 2G 内存，DataNode 与 0.13 一致。
+2. 升级到 3C3D 高性能分布式，ConfigNode 分配 2G 内存，DataNode 与 0.13 一致。
+
+配置修改：
+1.0 配置参数修改：
+- 数据目录不要指向0.13原有数据目录
+- region_group_extension_strategy=COSTOM
+- data_region_group_per_database
+ - 如果是 3C3D 高性能分布式：则改为：集群 CPU 总核数/ 数据副本数
+ - 如果是 1C1D，则改为：等于 0.13 的 virtual_storage_group_num 即可 （"database"一词 与 0.13
中的 "sg" 同义）
+
+数据迁移：
+配置修改完成后，通过 load-tsfile 工具将 0.13 的 TsFile 都加载进 1.0 的 IoTDB 中，即可使用。
+
+### 直接使用 1.0
+
+**推荐用户仅设置 1 个 Database**
+
+#### 内存设置方法
+##### 根据活跃序列数估计内存
+
+集群 DataNode 总堆内内存（GB） = 活跃序列数/100000 * 数据副本数
+
+每个 DataNode 堆内内存（GB）= 集群DataNode总堆内内存 / DataNode 个数
+
+> 假设需要用3C3D管理100万条序列，数据采用3副本，则：
+> - 集群 DataNode 总堆内内存（GB）：1,000,000 / 100,000 * 3 = 30G
+> - 每台 DataNode 的堆内内存配置为：30 / 3 = 10G
+
+##### 根据总序列数估计内存
+
+集群 DataNode 总堆内内存 （B） = 20 * （180 + 2 * 序列的全路径的平均字符数）* 序列总量 * 元数据副本数
+
+每个 DataNode 内存配置推荐：集群 DataNode 总堆内内存 / DataNode 数目
+
+> 假设需要用3C3D管理100万条序列，元数据采用3副本，序列名形如 root.sg_1.d_10.s_100（约20字符），则：
+> - 集群 DataNode 总堆内内存：20 * （180 + 2 * 20）* 1,000,000 * 3 = 13.2 GB
+> - 每台 DataNode 的堆内内存配置为：13.2 GB / 3 = 4.4 GB
+
+#### 磁盘估计
+
+IoTDB 存储空间=数据存储空间 + 元数据存储空间 + 临时存储空间
+
+##### 数据磁盘空间
+
+序列数量 * 采样频率 * 每个数据点大小 * 存储时长 * 副本数 / 10 倍压缩比
+
+| 数据类型 \ 数据点大小 | 时间戳（字节） | 值（字节） | 总共（字节） |
+|:-------------------------:|:--------|:------|:-------|
+| 开关量（Boolean） | 8 | 1 | 9 |
+| 整型（INT32）/单精度浮点数（FLOAT） | 8 | 4 | 12 |
+| 长整型（INT64）/双精度浮点数（DOUBLE） | 8 | 8 | 16 |
+| 字符串（TEXT） | 8 | 假设为 a | 8+a |
+
+
+> 示例：1000设备，每个设备100 测点，共 100000 序列。整型。采样频率1Hz（每秒一次），存储1年，3副本，压缩比按 10
算，则数据存储空间占用：
+> * 简版：1000 * 100 * 12 * 86400 * 365 * 3 / 10 = 11T
+> * 完整版：1000设备 * 100测点 * 12字节每数据点 * 86400秒每天 * 365天每年 * 3副本 / 10压缩比 = 11T
+
+##### 元数据磁盘空间
+
+每条序列在磁盘日志文件中大约占用 序列字符数 + 20 字节。
+若序列有tag描述信息，则仍需加上约 tag 总字符数字节的空间。
+
+##### 临时磁盘空间
+
+临时磁盘空间 = 写前日志 + 共识协议 + 合并临时空间
+
+1. 写前日志
+
+最大写前日志空间占用 = memtable 总内存占用 ÷ 最小有效信息占比
+- memtable 总内存占用和
datanode_memory_proportion、storage_engine_memory_proportion、write_memory_proportion
三个参数有关
+- 最小有效信息占比由 wal_min_effective_info_ratio 决定
+
+> 示例：为 IoTDB 分配 16G 内存，配置文件如下
+> datanode_memory_proportion=3:3:1:1:1:1
+> storage_engine_memory_proportion=8:2
+> write_memory_proportion=19:1
+> wal_min_effective_info_ratio=0.1
+> 最大写前日志空间占用 = 16 * (3 / 10) * (8 / 10) * (19 / 20) ÷ 0.1 = 36.48G
+
+2. 共识协议
+
+Ratis共识协议
+采用Ratis共识协议的情况下，需要额外磁盘空间存储Raft Log。Raft Log会在每一次状态机 Snapshot 之后删除，因此可以通过调整
trigger_snapshot_threshold 参数控制Raft Log最大空间占用。
+
+每一个 Region Raft Log占用最大空间 = 平均请求大小 * trigger_snapshot_threshold。
+集群中一个Region总的Raft Log占用空间和Raft数据副本数成正比。
+
+> 示例：DataRegion, 平均每一次插入20k数据，data_region_trigger_snapshot_threshold =
400,000，那么Raft Log最大占用 = 20K * 400,000 = 8G。
+Raft Log会从0增长到8G，接着在snapshot之后重新变成0。平均占用为4G。
+当副本数为3时，集群中这个DataRegion总Raft Log最大占用 3 * 8G = 24G。
+
+此外，可以通过data_region_ratis_log_max_size规定每一个DataRegion的Raft Log磁盘占用最大值，
+默认为20G，能够保障运行全程中单DataRegion Raft Log总大小不超过20G。
+
+3. 合并临时空间
+
+ - 空间内合并
+ 临时文件的磁盘空间 = 源文件大小总和
+
+ > 示例：10个源文件，每个文件大小为100M
+ > 临时文件的磁盘空间 = 10 * 100 = 1000M
+
+
+ - 跨空间合并
+ 跨空间合并的临时文件大小与源文件大小和顺乱序数据的重叠度有关，当乱序数据与顺序数据有相同的时间戳时，就认为有重叠。
+ 乱序数据的重叠度 = 重叠的乱序数据量 / 总的乱序数据量
+
+ 临时文件的磁盘空间 = 源顺序文件总大小 + 源乱序文件总大小 *（1 - 重叠度）
+ > 示例：10个顺序文件，10个乱序文件，每个顺序文件100M，每个乱序文件50M，每个乱序文件里有一半的数据与顺序文件有相同的时间戳
+ > 乱序数据的重叠度 = 25M/50M * 100% = 50%
+ > 临时文件的磁盘空间 = 10 * 100 + 10 * 50 * 50% = 1250M
+
