You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@iotdb.apache.org by hx...@apache.org on 2021/01/22 05:03:53 UTC

[iotdb] branch master updated: [FIX] fix the display of Chinese doc on Compaction.

This is an automated email from the ASF dual-hosted git repository.

hxd pushed a commit to branch master
in repository https://gitbox.apache.org/repos/asf/iotdb.git


The following commit(s) were added to refs/heads/master by this push:
     new 65a65e5  [FIX] fix the display of Chinese doc on Compaction.
65a65e5 is described below

commit 65a65e53a2f02a4103a164aeb4aa6c08e3452eae
Author: weizihan0110 <wz...@163.com>
AuthorDate: Fri Jan 22 12:15:52 2021 +0800

    [FIX] fix the display of Chinese doc on Compaction.
---
 docs/zh/SystemDesign/StorageEngine/Compaction.md | 38 ++++++++++++++++++++----
 1 file changed, 33 insertions(+), 5 deletions(-)

diff --git a/docs/zh/SystemDesign/StorageEngine/Compaction.md b/docs/zh/SystemDesign/StorageEngine/Compaction.md
index 24e6696..a1bf234 100644
--- a/docs/zh/SystemDesign/StorageEngine/Compaction.md
+++ b/docs/zh/SystemDesign/StorageEngine/Compaction.md
@@ -101,16 +101,21 @@
 
 ### 完全根据 level 合并的情况
 假设此时整个系统中有5个文件,最后一个文件没有关闭,则其结构及顺序分布如下
+```
 level-0: t2-0 t3-0 t4-0
 level-1: t0-1 t1-1
+```
 当最后一个文件关闭,按如下方式合并(第0层的t2-0、t3-0、t4-0文件合并到了第1层的t2-1文件)
+```
 level-0: t2-0 t3-0 t4-0
            \    \    |
              \   \   |
                \  \  |
                  \ \ |
 level-1: t0-1 t1-1 t2-1
+```
 合并后发现第1层合并后也满了,则继续合并到第2层,最后整个系统只剩下了第2层的t0-2文件
+```
 level-0: t2-0 t3-0 t4-0
            \    \    |
              \   \   |
@@ -122,12 +127,15 @@ level-1: t0-1 t1-1 t2-1
           |  /   /
           | /  /
 level-2: t0-2
-
+```
 ### 中途满足 merge_chunk_point_number 的情况
 假设此时整个系统中有4个文件,最后一个文件没有关闭,则其结构及顺序分布如下
+```
 level-0: t2-0 t3-0
 level-1: t0-1 t1-1
+```
 当最后一个文件关闭,但是t0-1、t1-1、t2-0、t3-0文件的 chunk point 数量加起来已经满足 merge_chunk_point_number,则做如下合并,即直接将所有文件合并到第2层(稳定层)
+```
 level-0: t2-0 t3-0
            |    |
 level-1: t0-1 t1-1
@@ -135,7 +143,7 @@ level-1: t0-1 t1-1
            |   / 
            |  / 
 level-2: t0-2
-
+```
 ### 动态参数调整的例子
 
 - 系统会严格按照上文中提到的 merge 流程对多层文件进行选择和合并,这里只介绍到参数调整时,系统初始化过程中文件会被放在哪一层
@@ -150,16 +158,21 @@ level-2: t0-2 t1-2 t2-2 t3-2 t4-2
 	* 此时因为不会改变任何文件的原 level,所以 recover 时文件还会被放到原来的层上,或超出 {max_level_num - 1} 的文件被放在最后一层(考虑到多次调整的情况)
 	* 即原文件将基于原来的 level 继续合并,超出 {max_level_num - 1} 部分也不会有乱序问题,因为在最后一层的必然是老文件
 假设整个系统中有5个文件,原 max_file_num_in_each_level = 2,提高后的 max_file_num_in_each_level = 3,此时恢复后的文件结构为:
+```
 level-0: t2-0 t3-0 t4-0
 level-1: t0-1 t1-1
+```
 假设 {size(t2-0)+size(t3-0)+size(t4-0)< merge_chunk_point_number},则进行合并的过程如下
+```
 level-0: t2-0 t3-0 t4-0
            \    \    |
              \   \   |
                \  \  |
                  \ \ |
 level-1: t0-1 t1-1 t2-1
+```
 合并后发现第1层合并后也满了,则继续合并到第2层,最后整个系统只剩下了第2层的t0-2文件
+```
 level-0: t2-0 t3-0 t4-0
            \    \    |
              \   \   |
@@ -171,21 +184,26 @@ level-1: t0-1 t1-1 t2-1
          |  /   /
          | /  /
 level-2: t0-2
-
+```
 * 降低 max_level_num
 	* 此时因为不会改变任何文件的原 level,所以 recover 时小于此时 {max_level_num - 1} 的文件还会被放到原来的层上,而超出的文件将被放在最后一层
 	* 即部分文件将被继续合并,而超出 {max_level_num - 2} 的文件将不会再被合并
 假设整个系统中有7个文件,原max_file_num_in_each_level = 3,降低后的max_file_num_in_each_level = 2,此时恢复后的文件结构为:
+```
 level-0: t4-0 t5-0 t6-0
 level-1: t0-2 t1-1 t2-1 t3-1
+```
 假设 {size(t2-0)+size(t3-0)+size(t4-0)< merge_chunk_point_number},则进行合并的过程如下
+```
 level-0:          t2-0 t3-0 t4-0
                     \    \    |
                       \   \   |
                         \  \  |
                           \ \ |
 level-1: t0-2 t1-1 t2-1 t3-1 t4-1
+```
 合并后发现第1层合并后也满了,则继续合并到第2层
+```
 level-0:          t2-0 t3-0 t4-0
                     \    \    |
                       \   \   |
@@ -197,29 +215,38 @@ level-1: t0-2 t1-1 t2-1 t3-1 t4-1
           |  /   /
           | /  /
 level-2: t0-2
+```
 最后剩下的文件结构为
+```
 level-0: 
 level-1: t3-1 t4-1
 level-2: t0-2
-
+```
 * NO_COMPACTION -> LEVEL_COMPACTION
 	* 此时因为删去了原始合并的 {mergeVersion + 1} 策略,所以所有文件将全部被放到0层
 	* 每一次合并会最多取出满足 {merge_chunk_point_number} 的文件进行合并,直到将所有多余的文件合并完,进入正常的合并流程
 假设整个系统中有5个文件,此时恢复后的文件结构为:
+```
 level-2: t0-0 t1-0 t2-0 t3-0 t4-0
+```
 假设 {size(t0-0)+size(t1-0)>=merge_chunk_point_number},则进行第一次合并的过程如下
+```
 level-0: t0-0 t1-0 t2-0 t3-0 t4-0 t5-0(新增了文件才会触发合并检查)
            |   /
            |  /
            | /
 level-2: t0-2
+```
 假设 {size(t2-0)+size(t3-0)>=merge_chunk_point_number},则进行第二次合并的过程如下
+```
 level-0: t2-0 t3-0 t4-0 t5-0 t6-0(新增了文件才会触发合并检查)
            \    |
             \   |
              \  |
 level-2: t0-2 t2-2
+```
 假设 {size(t4-0)+size(t5-0)+size(t6-0)+size(t7-0)< merge_chunk_point_number},则进行第三次合并的过程如下
+```
 level-0: t4-0 t5-0 t6-0 t7-0(新增了文件才会触发合并检查)
            |    /   /
            |   /  /
@@ -227,4 +254,5 @@ level-0: t4-0 t5-0 t6-0 t7-0(新增了文件才会触发合并检查)
            | //  
 level-1: t4-1
    
-level-2: t0-2 t2-2
\ No newline at end of file
+level-2: t0-2 t2-2
+```
\ No newline at end of file