You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@iotdb.apache.org by ha...@apache.org on 2021/06/10 03:17:15 UTC
[iotdb] branch master updated: Update some English system design
documents (#3379)
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 <zh...@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.