[iotdb] branch master updated: Update some English system design documents (#3379)

[haonan]

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

haonan 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 f6c4162  Update some English system design documents (#3379)
f6c4162 is described below

commit f6c4162ea15777c1bb53673afc7c8c88c4760b8d
Author: zhengjp31 <zhengj...@outlook.com>
AuthorDate: Thu Jun 10 11:16:39 2021 +0800

    Update some English system design documents (#3379)
---
 docs/SystemDesign/DataQuery/QueryFundamentals.md     | 16 ++++++++--------
 .../QueryEngine/ResultSetConstruction.md             | 12 ++++++------
 docs/SystemDesign/SchemaManager/SchemaManager.md     |  8 ++++----
 docs/SystemDesign/StorageEngine/DataPartition.md     |  2 +-
 docs/SystemDesign/StorageEngine/FlushManager.md      |  2 +-
 docs/SystemDesign/StorageEngine/MergeManager.md      | 11 ++++-------
 docs/SystemDesign/StorageEngine/StorageEngine.md     |  6 +++---
 docs/SystemDesign/StorageEngine/WAL.md               |  4 ++--
 docs/SystemDesign/TsFile/Format.md                   | 20 ++++++++++----------
 docs/SystemDesign/TsFile/Read.md                     | 16 ++++++++--------
 docs/SystemDesign/TsFile/Write.md                    | 16 ++++++++--------
 11 files changed, 55 insertions(+), 58 deletions(-)

diff --git a/docs/SystemDesign/DataQuery/QueryFundamentals.md 
b/docs/SystemDesign/DataQuery/QueryFundamentals.md
index 827a961..b7eda82 100644
--- a/docs/SystemDesign/DataQuery/QueryFundamentals.md
+++ b/docs/SystemDesign/DataQuery/QueryFundamentals.md
@@ -34,12 +34,12 @@ IoTDB stores sequential and un-sequential TsFiles 
separately under `data/sequenc
 
 It should be noted that, in the following query documents, we tend to use `seq 
file` to represent Sequential files for short. For un-sequential ones we use 
`unseq file`. Sometimes `unordered file` or `out-of-order file` are also used 
as aliases of un-sequential files.
 
-## General query process
+## General process of reading TsFile and other memory data
 
 The multi-level structure of TsFile is introduced in 
[TsFile](../TsFile/TsFile.md). 
 For each timeseries, we always follow the query routine across 5 levels: 
TsFileResource -> TimeseriesMetadata -> ChunkMetadata -> IPageReader -> 
BatchData
 
-The file access utility methods are in 
`org.apache.iotdb.db.utils.FileLoaderUtils`
+The function methods for file reading are in 
`org.apache.iotdb.db.utils.FileLoaderUtils`
 
 * `loadTimeSeriesMetadata()` reads the TimeseriesMetadata of a timeseries in a 
TsFileResource. If a time filter is set for this method, only those 
TimeseriesMetadata that satisfies this filter will be returned. 
`loadTimeSeriesMetadata()` returns null otherwise.
 * `loadChunkMetadataList()` can load a ChunkMetadata list for a 
TimeseriesMetadata。
@@ -58,8 +58,8 @@ We call it unsealed because users may be still writing data 
into this Timeseries
 It is almost the same in `loadPageReaderList()` to read Page data. 
 `MemChunkLoader` and `DiskChunkLoader` support for memory page loading and 
disk page loading. 
 
-## Data orderings in TsFiles
-
+## Data characteristics of sequential and unsequential files.
+For data in sequential and unsequential files, the partial characteristics of 
the data in the file are different.
 Timeseries data in seq files is in "overall" ascending order. Specifically, 
all the ChunkMetadata in a timeseries stored in seq files are in the right 
order.
 Therefore, if we have `ChunkMetadata1` and `ChunkMetadata2` kept in a seq 
file, it is guaranteed that 
 ```
@@ -75,10 +75,10 @@ That means, two orderings within pages are guaranteed:
 
 This certain ordering will be fully utilized to accelerate query process 
within our design.
 
-## Modification Handling
+## Data modification processing in the query
 
 Data deletion in IoTDB records a series of mods file for disk data. The data 
is not really deleted, so we need to consider the existence of modifications in 
query.
-
+ If any data is deleted from a file, record the deletion to the mods file. 
Record three columns: the time series of the deletion, the maximum time point 
of the deletion range, and the version corresponding to the deletion operation.
 ### Related class
 
 Modification file: org.apache.iotdb.db.engine.modification.ModificationFile
@@ -98,7 +98,7 @@ Correspondingly, TimeRange is the medium that deletions exist 
within memory.
 
 All deletion TimeRanges are both left-close and right-close intervals. We use 
Long.MIN_VALUE and Long.MAX_VALUE to refer to infinity and negative infinity 
timestamp.
 
-### Query chunks with delete intervals
+### Query processing with deletion ranges
 When querying a TVList, the TimeRanges are sorted and merged before a TVList 
tries to access them. 
 For example, we have [1,10], [5,12], [15,20], [16,21] in the original list, 
then they will be preprocessed to [1,12] and [15,21].
 For cases when there are a large number of deletion operations, it would be 
helpful to exclude deleted data.
@@ -158,4 +158,4 @@ FileLoaderUtils.loadPageReaderList()
 ```
 // For disk page, skip the data points that be deleted and filtered out. For 
memory data, skip data points be filtered out.
 IPageReader.getAllSatisfiedPageData()
-```
\ No newline at end of file
+```
diff --git a/docs/SystemDesign/QueryEngine/ResultSetConstruction.md 
b/docs/SystemDesign/QueryEngine/ResultSetConstruction.md
index e4e1757..bd8ae89 100644
--- a/docs/SystemDesign/QueryEngine/ResultSetConstruction.md
+++ b/docs/SystemDesign/QueryEngine/ResultSetConstruction.md
@@ -31,7 +31,7 @@ Next Introduce the first part: including the result set 
header construction way
 
 ### Raw data query
 
-The header construction logic of raw data query is in the 
`getWideQueryHeaders()` method.
+The result set table header construction logic for the raw data query is 
mainly in the `getWideQueryHeaders()` method.
 
 - org.apache.iotdb.db.service.TSServiceImpl.getWideQueryHeaders
 
@@ -59,7 +59,7 @@ SQL2：`SELECT count(s1), max_time(s1) FROM root.sg.d1;` ->
 
 ### Align by device query
 
-The header construction logic of align by device query is in the 
`getAlignByDeviceQueryHeaders()` method.
+The result set table header construction logic for the Align by device query 
is mainly in the `getAlignByDeviceQueryHeaders()` method.
 
 - org.apache.iotdb.db.service.TSServiceImpl.getAlignByDeviceQueryHeaders
 
@@ -85,9 +85,9 @@ SQL：`SELECT '111', s1, s2, *, s5 FROM root.sg.d1 ALIGN BY 
DEVICE;`
 | ---- | ------ | --- | --- | --- | --- | --- | --- |
 |      |        |     |     |     |     |     |     |
 
-### LastQuery
+### Latest data query
 
-The header construction logic of last query is in the static method 
`LAST_RESP`.
+The result set table header construction logic for the Latest data query is 
mainly in the static method `LAST_RESP`.
 
 - org.apache.iotdb.db.service.StaticResps.LAST_RESP
 
@@ -154,7 +154,7 @@ To restore the final result set, we need to construct a 
mapping set `columnOrdin
 
 - org.apache.iotdb.jdbc.AbstractIoTDBResultSet.AbstractIoTDBResultSet()
 
-In order to construct metadata information in final result set, a complete 
column name list is needed. The `columnnamelist` given above does not contain a 
timestamp. Therefore, it's necessary to determine whether a timestamp needs to 
be printed. If so, add the `Time` column to the header to form a complete 
header.
+In order to construct metadata information in final result set, a complete 
list of column names needs to be constructed. The `columnnamelist` given above 
does not contain a timestamp. Therefore, it's necessary to determine whether a 
timestamp needs to be printed. If so, add the `Time` column to the header to 
form a complete header.
 
 The complete header in example is：
 
@@ -162,7 +162,7 @@ The complete header in example is：
 | ---- | ------------- | ------------- | ------------- |
 |      |               |               |               |
 
-Then calculating `columnordinalmap`, judge whether to print a timestamp first. 
If so, record the timestamp as the first column.
+Then let's calculate `columnordinalmap`, judge whether to print a timestamp 
first. If so, record the timestamp as the first column.
 
 Then traverse the column name list in the header and then check whether 
`columnnameindex` is initialized. This field comes from `pathtoindex` 
calculated during deduplication, which records the location of each timeseries 
path in the query. If it is initialized, record the position + 2 as its 
position in the result set. If not, record the positions in traversal order, 
which is consistent with the query order in server side.
 
diff --git a/docs/SystemDesign/SchemaManager/SchemaManager.md 
b/docs/SystemDesign/SchemaManager/SchemaManager.md
index 53d97d1..b601cd4 100644
--- a/docs/SystemDesign/SchemaManager/SchemaManager.md
+++ b/docs/SystemDesign/SchemaManager/SchemaManager.md
@@ -40,7 +40,7 @@ In the process of initializing, MManager will replay the mlog 
to load the metada
 * Create Timeseries
     * check if the storage group exists, if not and the auto create is enable, 
create it.
     * create a leafMNode in the MTree with alias
-       * if the dynamic parameter is enable, check if the memory is satisfied
+       * If dynamic parameters are turned on, check the memory is satisfied or 
not
        * if not restart
            * persist tags/attributes into tlog, and return the offset
                * set the offset of the leafMNode
@@ -66,7 +66,7 @@ In the process of initializing, MManager will replay the mlog 
to load the metada
 
 * Set Storage Group
     * add StorageGroupMNode in MTree
-       * if dynamic parameter is enable, check if the memory is satisfied
+       * If dynamic parameters are turned on, check the memory is satisfied or 
not
        * if not restart, persist log into mlog
 
 * Delete Storage Group
@@ -92,7 +92,7 @@ In the process of initializing, MManager will replay the mlog 
to load the metada
 
 In addition to these seven operation that are needed to be logged, there are 
another six alter operation to tag/attribute info of timeseries.
  
-> Same as above, at the beginning of each operation, it will try to obatin the 
write lock of MManager, and release it after operation.
+Same as above, at the beginning of each operation, it will try to obatin the 
write lock of MManager, and release it after operation.
 
 * Rename Tag/Attribute
        * obtain the LeafMNode of that timeseries
@@ -173,7 +173,7 @@ The root node exists by default. Creating storage groups, 
deleting storage group
        * create LeafMNode, and store the alias in LeafMNode if it has
        * If it has alias, create another links with alias to LeafMNode
 
-* Deleting a storage group is similar to deleting a time series. That is, the 
storage group or time series node is deleted in its parent node. The time 
series node also needs to delete its alias in the parent node; if in the 
deletion process, a node is found not to have any child node, needs to be 
deleted recursively.
+* Deleting a storage group is similar to deleting a time series. That is, the 
storage group or time series node is deleted in its parent node. The time 
series node also needs to delete its alias in the parent node; If in the 
deletion process,it is found that a node does not have any child nodes, it also 
needs to delete this node recursively.
        
 ## MTree checkpoint
 
diff --git a/docs/SystemDesign/StorageEngine/DataPartition.md 
b/docs/SystemDesign/StorageEngine/DataPartition.md
index 62a6711..9babe38 100644
--- a/docs/SystemDesign/StorageEngine/DataPartition.md
+++ b/docs/SystemDesign/StorageEngine/DataPartition.md
@@ -21,7 +21,7 @@
 
 # Data partition
 
-Time series data is partitioned on two levels of storage groups and time 
ranges.
+Time series data is partitioned at the storage group and time range levels.
 
 ## Storage group
 
diff --git a/docs/SystemDesign/StorageEngine/FlushManager.md 
b/docs/SystemDesign/StorageEngine/FlushManager.md
index 21050e6..1315704 100644
--- a/docs/SystemDesign/StorageEngine/FlushManager.md
+++ b/docs/SystemDesign/StorageEngine/FlushManager.md
@@ -25,7 +25,7 @@
 
 After the memory buffer memtable reaches a certain threshold, it will be 
handed over to the FlushManager for asynchronous persistence without blocking 
normal writes. The persistence process is pipelined.
 
-## Related idea
+## Related code
 
 * org.apache.iotdb.db.engine.flush.FlushManager
 
diff --git a/docs/SystemDesign/StorageEngine/MergeManager.md 
b/docs/SystemDesign/StorageEngine/MergeManager.md
index fdc4332..8e246f5 100644
--- a/docs/SystemDesign/StorageEngine/MergeManager.md
+++ b/docs/SystemDesign/StorageEngine/MergeManager.md
@@ -71,8 +71,7 @@ In addition, each custom MergeTask needs to inherit the 
Callable \<void\> interf
 
 ### selector
 
-Under limited memory and time, first select the unseq file in turn, and each 
time directly select the seq file that overlaps with the unseq file according 
to the time range
-
+Under limited memory and time, first select the unseq file in turn, Select the 
SEQ files that overlap each time directly based on the unseq file's time range.
 ### merge
 
 First select all series that need to be merged according to storageGroupName, 
then create a chunkMetaHeap for each seq file selected in the selector, and 
merge them into multiple sub-threads according to the mergeChunkSubThreadNum in 
the configuration.
@@ -87,7 +86,7 @@ Under the limited memory and time, first select the unseq 
file in turn, each tim
 
 Basically similar to the inplace strategy, first select all series that need 
to be merged according to storageGroupName, then create a chunkMetaHeap for 
each seq file selected in the selector, and merge into multiple child threads 
according to the mergeChunkSubThreadNum in the configuration to merge
 
-## Recovery after merge interruption
+## Recoverying after merge interruption
 
 The merge may be forcibly interrupted when the system shuts down or fails 
suddenly. At this time, the system records the interrupted merge and scans the 
merge.log file when the next StorageGroupProcessor is created, and re-merges 
according to the configuration.  There are the following states, among which 
the recovery process is to give up the merge strategy first
 
@@ -95,13 +94,11 @@ The merge may be forcibly interrupted when the system shuts 
down or fails sudden
 Basically did nothing, delete the corresponding merge log directly during 
recovery, and wait for the next manual or automatic merge
 
 ### MERGE_START
-Files to be merged and timeseries have been selected
-Delete the corresponding merge file during recovery, empty the selected file, 
and clear all other merge related public resources
-
+When the files to be merged and the TimeSeries have been selected, delete the 
corresponding merge file, empty the selected file, and empty the other merge 
related public resources.
 ### ALL_TS_MERGED
 All timeseries have been merged
 Perform cleanUp directly on recovery and execute the callback operation 
completed by merge
 
 ### MERGE_END
 All the files on the surface have been merged, this time the merge has been 
completed
-This state does not appear in the merge log in principle
\ No newline at end of file
+This state does not appear in the merge log in principle
diff --git a/docs/SystemDesign/StorageEngine/StorageEngine.md 
b/docs/SystemDesign/StorageEngine/StorageEngine.md
index 33a8bf5..b53f2df 100644
--- a/docs/SystemDesign/StorageEngine/StorageEngine.md
+++ b/docs/SystemDesign/StorageEngine/StorageEngine.md
@@ -31,7 +31,7 @@ Each data file TsFile corresponds to a file index information 
TsFileResource in
 
 In addition, the storage engine includes asynchronous persistence and file 
merge mechanisms.
 
-## Write process
+## Writing process
 
 ### Related code
 
@@ -49,9 +49,9 @@ In addition, the storage engine includes asynchronous 
persistence and file merge
 
   Responsible for data writing and accessing a TsFile file.
 
-## Data write
+## Data writing
 See details:
-* [Data write](../StorageEngine/DataManipulation.md)
+* [Data writing](../StorageEngine/DataManipulation.md)
 
 ## Data access
 
diff --git a/docs/SystemDesign/StorageEngine/WAL.md 
b/docs/SystemDesign/StorageEngine/WAL.md
index 3474f90..1d57bb4 100644
--- a/docs/SystemDesign/StorageEngine/WAL.md
+++ b/docs/SystemDesign/StorageEngine/WAL.md
@@ -21,7 +21,7 @@
 
 # WAL
 
-## Work Process
+## Working Process
 * WAL overall recording principle
   * For each Memtable, a corresponding WAL file will be recorded. When the 
Memtable is flushed, the WAL will be deleted.
 * WAL record details
@@ -35,7 +35,7 @@
 
 ## Test Result
 
-* When running forceTask, The entire process is mainly blocked by 
org.apache.iotdb.db.writelog.io.LogWriter.force()
+* The main time spent on forceTask is focused on. 
org.apache.iotdb.db.writelog.io.LogWriter.force()
 * Test forceTask on SSD and HDD respectively
   * In SSD, the speed is 75MB/s
   * In HDD, the speed is 5MB/s
diff --git a/docs/SystemDesign/TsFile/Format.md 
b/docs/SystemDesign/TsFile/Format.md
index 9c7c32b..e3b04df 100644
--- a/docs/SystemDesign/TsFile/Format.md
+++ b/docs/SystemDesign/TsFile/Format.md
@@ -29,7 +29,7 @@
 
 - **Big Endian**
        
-  - For Example, the `int` `0x8` will be stored as `00 00 00 08`, not `08 00 
00 00`
+  - For Example, the `int` `0x8` will be stored as `00 00 00 08`, replace by 
`08 00 00 00`
 - **String with Variable Length**
   - The format is `int size` plus `String literal`. Size can be zero.
   - Size equals the number of bytes this string will take, and it may not 
equal to the length of the string. 
@@ -66,13 +66,13 @@
 
 ### 1.2 TsFile Overview
 
-Here is a graph about the TsFile structure.
+Here is the structure diagram of TsFile.
 
 <img style="width:100%; max-width:800px; max-height:600px; margin-left:auto; 
margin-right:auto; display:block;" 
src="https://user-images.githubusercontent.com/33376433/120660695-2a71e300-c4ba-11eb-9e61-5e023636480b.png";>
 
 This TsFile contains two devices: d1, d2. Each device contains two 
measurements: s1, s2. 4 timeseries in total. Each timeseries contains 2 Chunks.
 
-Here is another graph:
+Here is another representation of the TsFile structure:
 
 <img style="width:100%; max-width:800px; max-height:600px; margin-left:auto; 
margin-right:auto; display:block;" 
src="https://user-images.githubusercontent.com/19167280/98808354-ed2f0080-2456-11eb-8e7f-b11a4759d560.png";>
 
@@ -80,8 +80,8 @@ This TsFile contains two devices: d1, d2. Each device 
contains three measurement
 
 There are three parts of metadata
 
-* ChunkMetadata list that grouped by timeseries
-* TimeseriesMetadata that ordered by timeseries
+* A list of ChunkMetadata organized by timeseries.
+* A list of TimeseriesMetadata organized by timeseries.
 * TsFileMetadata
 
 Query Process：e.g., read d1.s1
@@ -104,7 +104,7 @@ The data section is an array of `ChunkGroup`, each 
ChunkGroup represents a *devi
 
 ##### ChunkGroup
 
-The `ChunkGroup` has an array of `Chunk`, a following byte `0x00` as the 
marker, and a `ChunkFooter`.
+The `ChunkGroup` consists of several `Chunk`, a byte delimiter`0x00` and a 
`ChunkFooter`.
 
 ##### Chunk
 
@@ -215,19 +215,19 @@ The max degree of the metadata index tree (that is, the 
max number of each node'
 
 <img style="width:100%; max-width:800px; max-height:600px; margin-left:auto; 
margin-right:auto; display:block;" 
src="https://user-images.githubusercontent.com/19167280/81935219-de3fd080-9622-11ea-9aa1-a59bef1c0001.png";>
 
-5 devices with 5 measurements each: Since the numbers of devices and 
measurements are both no more than `max_degree_of_index_node`, the tree has 
only measurement index level by default. In this level, each MetadataIndexNode 
is composed of no more than 10 MetadataIndex entries. The root nonde is 
`INTERNAL_MEASUREMENT` type, and the 5 MetadataIndex entries point to 
MetadataIndex nodes of related devices. These nodes point to  
`TimeseriesMetadata` directly, as they are `LEAF_MEASUREMENT` type.
+In the case of 5 devices with 5 measurements each: Since the numbers of 
devices and measurements are both no more than `max_degree_of_index_node`, the 
tree has only measurement index level by default. In this level, each 
MetadataIndexNode is composed of no more than 10 MetadataIndex entries. The 
root nonde is `INTERNAL_MEASUREMENT` type, and the 5 MetadataIndex entries 
point to MetadataIndex nodes of related devices. These nodes point to  
`TimeseriesMetadata` directly, as they are `LEAF_ [...]
 
 <img style="width:100%; max-width:800px; max-height:600px; margin-left:auto; 
margin-right:auto; display:block;" 
src="https://user-images.githubusercontent.com/19167280/81935210-d97b1c80-9622-11ea-8a69-2c2c5f05a876.png";>
 
-1 device with 150 measurements: The number of measurements exceeds 
`max_degree_of_index_node`, so the tree has only measurement index level by 
default. In this level, each MetadataIndexNode is composed of no more than 10 
MetadataIndex entries. The nodes that point to `TimeseriesMetadata` directly 
are `LEAF_MEASUREMENT` type. Other nodes and root node of index tree are not 
leaf nodes of measurement index level, so they are `INTERNAL_MEASUREMENT` type.
+In the case of 1 device with 150 measurements: The number of measurements 
exceeds `max_degree_of_index_node`, so the tree has only measurement index 
level by default. In this level, each MetadataIndexNode is composed of no more 
than 10 MetadataIndex entries. The nodes that point to `TimeseriesMetadata` 
directly are `LEAF_MEASUREMENT` type. Other nodes and root node of index tree 
are not leaf nodes of measurement index level, so they are 
`INTERNAL_MEASUREMENT` type.
 
 <img style="width:100%; max-width:800px; max-height:600px; margin-left:auto; 
margin-right:auto; display:block;" 
src="https://user-images.githubusercontent.com/19167280/95592841-c0fd1a00-0a7b-11eb-9b46-dfe8b2f73bfb.png";>
 
-150 device with 1 measurement each: The number of devices exceeds 
`max_degree_of_index_node`, so the device index level and measurement index 
level of the tree are both formed. In these two levels, each MetadataIndexNode 
is composed of no more than 10 MetadataIndex entries. The nodes that point to 
`TimeseriesMetadata` directly are `LEAF_MEASUREMENT` type. The root nodes of 
measurement index level are also the leaf nodes of device index level, which 
are `LEAF_DEVICE` type. Other nodes and [...]
+In the case of 150 device with 1 measurement each: The number of devices 
exceeds `max_degree_of_index_node`, so the device index level and measurement 
index level of the tree are both formed. In these two levels, each 
MetadataIndexNode is composed of no more than 10 MetadataIndex entries. The 
nodes that point to `TimeseriesMetadata` directly are `LEAF_MEASUREMENT` type. 
The root nodes of measurement index level are also the leaf nodes of device 
index level, which are `LEAF_DEVICE` type.  [...]
 
 <img style="width:100%; max-width:800px; max-height:600px; margin-left:auto; 
margin-right:auto; display:block;" 
src="https://user-images.githubusercontent.com/19167280/81935138-b6e90380-9622-11ea-94f9-c97bd2b5d050.png";>
 
-150 device with 150 measurements each: The numbers of devices and measurements 
both exceed `max_degree_of_index_node`, so the device index level and 
measurement index level are both formed. In these two levels, each 
MetadataIndexNode is composed of no more than 10 MetadataIndex entries. As is 
described before, from the root node to the leaf nodes of device index level, 
their types are `INTERNAL_DEVICE` and `LEAF_DEVICE`; each leaf node of device 
index level can be seen as the root node o [...]
+In the case of 150 device with 150 measurements each: The numbers of devices 
and measurements both exceed `max_degree_of_index_node`, so the device index 
level and measurement index level are both formed. In these two levels, each 
MetadataIndexNode is composed of no more than 10 MetadataIndex entries. As is 
described before, from the root node to the leaf nodes of device index level, 
their types are `INTERNAL_DEVICE` and `LEAF_DEVICE`; each leaf node of device 
index level can be seen as  [...]
 
 The MetadataIndex is designed as tree structure so that not all the 
`TimeseriesMetadata` need to be read when the number of devices or measurements 
is too large. Only reading specific MetadataIndex nodes according to 
requirement and reducing I/O could speed up the query. More reading process of 
TsFile in details will be described in the last section of this chapter.
 
diff --git a/docs/SystemDesign/TsFile/Read.md b/docs/SystemDesign/TsFile/Read.md
index 59569f8..53bbd87 100644
--- a/docs/SystemDesign/TsFile/Read.md
+++ b/docs/SystemDesign/TsFile/Read.md
@@ -19,7 +19,7 @@
 
 -->
 
-# TsFile Read Process
+# TsFile Reading Process
 
 This chapter introduces how to read TsFile. The content is mainly divided into 
two parts, the introduction of Filters and Expressions , and the detailed 
illustration of query process in TsFile.
 
@@ -42,11 +42,11 @@ This chapter introduces how to read TsFile. The content is 
mainly divided into t
     - [2.4 Join Query](#24-Join-Query)
     - [2.5 Query of TsFile](#25-Query-of-TsFile)
     - [2.6 Related Concepts](#26-Related-Concepts)
-## 1 Filters and Expressions
-
+## 1 Filters conditions and query experssions
 ### 1.1 Filter
+This chapter introduces the filtering conditions and the relevant defination 
of query expression when TSFILE file is read first. Secondly, how to transform 
the filtering conditions entered by users into query conditions that the system 
can execute.
 
-In this document, the term Filter means filter conditions. Users can customize 
filter conditions on timestamp, or the value of time series. We distinguish the 
filters which are on timestamp from those on column values. Assume t to be a 
timestamp constant, there are 12 basic types of Filters. In implementation, 
they all inherit from the super class Filter.
+Filter represents the basic filtering condition. The user can specify specific 
filtering criteria on a timestamp or on a column of values. After 
distinguishing the filtering conditions of timestamp and column value, let t 
represent a certain timestamp constant. Filter has the following 12 basic 
types, which are inheritance relations in implementation.
 
 Filter|Filter Type|Explanation|Examples
 ----|----|---|------
@@ -63,7 +63,7 @@ ValueLt|value filter|value on this column < some 
value|ValueLt("string") means v
 ValueLtEq|value filter|value on this column <= some value|ValueLtEq(-100) 
means value on this column shold be less than or equal to -100
 ValueNotEq|value filter|value on this column != some value|ValueNotEq(true) 
means value on this column should not be true
 
-Filter can be composed of one or two Filter children。If a Filter is composed 
of a single Filter, it is also termed as UnaryFilter.If it contains two 
filters, it is termed as BinaryFilter. In this case, the two filters are 
connected with a logical relation, AND or OR, where the formar is termed as 
AndFilter, and the latter is OrFilter. Obviously, both AndFilter and OrFilter 
are BinaryFilter.
+A filter can consist of one or two sub-filters.。If a Filter is composed of a 
single Filter, it is also termed as UnaryFilter.If it contains two filters, it 
is termed as BinaryFilter. In this case, the two filters are connected with a 
logical relation, AND or OR, where the formar is termed as AndFilter, and the 
latter is OrFilter. Obviously, both AndFilter and OrFilter are BinaryFilter.
 
 We give some examples of AndFilter and OrFilter, where "&&" indicates relation 
AND and "||" indicates relation OR.
 
@@ -478,7 +478,7 @@ This component provides two basic functions:
 
 2. get the next satisfying timestamp
 
-### 2.3 Merge Query
+### 2.3 Query Merging
 org.apache.iotdb.tsfile.read.query.dataset.DataSetWithoutTimeGenerator
 
 Suppose there are n time series. For each one of them, a FileSeriesReader will 
be generated. If there's a GlobalTimeExpression, the filter in it will be input 
to the FileSeriesReaders.
@@ -497,7 +497,7 @@ The steps include:
 
 (5) Terminate the process.
 
-### 2.4 Join Query
+### 2.4 Join Queries
 
 org.apache.iotdb.tsfile.read.query.executor.ExecutorWithTimeGenerator
 
@@ -513,7 +513,7 @@ Join query execution generates timestamp according to the 
filter conditions, and
 
 (5) Combine the data points in step (4) to form a RowRecord, then go to step 
(3) to generate another row of records.
 
-### 2.5 Query of TsFile
+### 2.5 Query entrence of TsFile
 
  org.apache.iotdb.tsfile.read.query.executor.TsFileExecutor
 
diff --git a/docs/SystemDesign/TsFile/Write.md 
b/docs/SystemDesign/TsFile/Write.md
index 4d807c3..cea4620 100644
--- a/docs/SystemDesign/TsFile/Write.md
+++ b/docs/SystemDesign/TsFile/Write.md
@@ -19,7 +19,7 @@
 
 -->
 
-# TsFile Write Process
+# TsFile Writing Process
 
 - org.apache.iotdb.tsfile.write.*
 
@@ -31,11 +31,11 @@ Among them, each device corresponds to a ChunkGroupWriter, 
and each sensor corre
 
 File writing is mainly divided into three operations, marked with 1, 2, 3 on 
the figure
 
-- 1、Write memory swap area
+- 1、Writing memory buffer
 - 2、Persistent ChunkGroup
 - 3、Close file
 
-## 1、Write memory buffer
+## 1、Writing memory buffer
 
 TsFile file layer has two write interfaces
 
@@ -69,7 +69,7 @@ One of the most important steps in constructing 
TsFileMetadata is to construct M
 
 ### MetadataIndexConstructor.constructMetadataIndex()
 
-The input params of this method:
+The method of input include:
 * Map\<String, List\<TimeseriesMetadata\>\> deviceTimeseriesMetadataMap, which 
indicates the map from device to its `TimeseriesMetadata`
 * TsFileOutput out
 
@@ -84,7 +84,7 @@ The whole method contains three parts:
     * After storing `MAX_DEGREE_OF_INDEX_NODE` entries, add `currentIndexNode` 
into `queue`, and point `currentIndexNode` to a new MetadataIndexNode
   * Generate upper-level nodes of measurement index level according to the 
leaf nodes in `queue`, until the final root node (this method will be described 
later), and put the "device-root node" map into `deviceMetadataIndexMap`
 
-2. Then judge whether the number of devices exceed `MAX_DEGREE_OF_INDEX_NODE`. 
If not, the root node of MetadataIndex tree could be generated and return
+2. Next, determine whether the number of devices exceeds 
`MAX_DEGREE_OF_INDEX_NODE`. If not, the root node of MetadataIndex tree could 
be generated and return
   * Initialize the root node of MetadataIndex tree, which is 
`INTERNAL_MEASUREMENT` type
   * For each entry in `deviceMetadataIndexMap`:
     * Serialize
@@ -103,7 +103,7 @@ The whole method contains three parts:
 
 ### MetadataIndexConstructor.generateRootNode
 
-The input params of this method:
+The method of input include:
 * Queue\<MetadataIndexNode\> metadataIndexNodeQueue
 * TsFileOutput out
 * MetadataIndexNodeType type, which indicates the internal nodes type of 
generated tree. There are two types: when the method is called by measurement 
index level, it is INTERNAL_MEASUREMENT; when the method is called by device 
index level, it is INTERNAL_DEVICE 
@@ -118,9 +118,9 @@ The method needs to generate a tree structure of nodes in 
metadataIndexNodeQueue
 
 ### MetadataIndexConstructor.addCurrentIndexNodeToQueue
 
-The input params of this method:
+The method of input include:
 * MetadataIndexNode currentIndexNode
 * Queue\<MetadataIndexNode\> metadataIndexNodeQueue
 * TsFileOutput out
 
-This method set the endOffset of current MetadataIndexNode, and put it into 
queue.
\ No newline at end of file
+This method set the endOffset of current MetadataIndexNode, and put it into 
queue.