未验证 提交 294f1e70 编写于 作者: zhanglingzhe0820's avatar zhanglingzhe0820 提交者: GitHub

Update TSDB-comparison doc and `Merge` command doc (#3233)

Co-authored-by: Nzhanglingzhe <surevil@foxmail.com>
Co-authored-by: NHaonan <hhaonan@outlook.com>
上级 9171c2fa
......@@ -308,6 +308,10 @@ We test the performance of writing from two aspects: *batch size* and *client nu
10 clients read data concurrently. The number of storage group is 10. There are 10 devices and each device has 10 measurements (i.e.,, 100 time series total).
The data type is *double*, encoding type is *GORILLA*
* Compression:
We test and compare file sizes of TsFile(the file format of IoTDB) and some others famous dataset formats, which are Parquet, ORC and Csv, after the same datasets are written.
The IoTDB version is v0.11.1.
**Write performance**:
......@@ -315,17 +319,17 @@ The IoTDB version is v0.11.1.
* batch size:
10 clients write data concurrently.
IoTDB uses batch insertion API and the batch size is distributed from 1ms to 1min (write N data points per write API call).
IoTDB uses batch insertion API and the batch size is distributed from 0 to 6000 (write N data points per write API call).
The write throughput (points/second) is:
![Batch Size with Write Throughput (points/second)](https://user-images.githubusercontent.com/24886743/106254214-6cacbe80-6253-11eb-8532-d6a1829f8f66.png)
![Batch Size with Write Throughput (points/second)](https://user-images.githubusercontent.com/24886743/106251391-df1b9f80-624f-11eb-9f1f-66823839acba.png)
<span id = "exp1"> <center>Figure 1. Batch Size with Write throughput (points/second) IoTDB v0.11.1</center></span>
The write delay (ms) is:
![Batch Size with Write Delay (ms)](https://user-images.githubusercontent.com/24886743/106251391-df1b9f80-624f-11eb-9f1f-66823839acba.png)
![Batch Size with Write Delay (ms)](https://user-images.githubusercontent.com/24886743/118790013-f1395080-b8c7-11eb-9e22-3310fa4ec804.png)
<center>Figure 2. Batch Size with Write Delay (ms) IoTDB v0.11.1</center>
* client num:
......@@ -352,8 +356,10 @@ The write throughput (points/second) is:
![Latest query](https://user-images.githubusercontent.com/24886743/106251369-d7f49180-624f-11eb-9d19-fc7341582b90.png)
<center>Figure 7. Latest query time cost(ms) IoTDB v0.11.1</center>
We can see that IoTDB outperforms others.
![Data compression](https://user-images.githubusercontent.com/24886743/118790229-23e34900-b8c8-11eb-87da-ac01dd117f28.png)
<center>Figure 8. Data compression IoTDB v0.11.1</center>
We can see that IoTDB outperforms others.
#### More details
......
......@@ -32,10 +32,10 @@ IoTDB> FLUSH root.sg1,root.sg2
## MERGE
Merge sequence and unsequence data. Currently IoTDB supports the following two types of SQL to manually trigger the merge process of data files:
Execute Level Compaction and unsequence Compaction task. Currently IoTDB supports the following two types of SQL to manually trigger the compaction process of data files:
* `MERGE` Only rewrite overlapped Chunks, the merge speed is quick, while there will be redundant data on the disk eventually.
* `FULL MERGE` Rewrite all data in overlapped files, the merge speed is slow, but there will be no redundant data on the disk eventually.
* `MERGE` Execute the level compaction first and then execute the unsequence compaction. In unsequence compaction process, this command is executed very fast by rewriting the overlapped Chunks only, while there is some redundant data on the disk eventually.
* `FULL MERGE` Execute the level compaction first and then execute the unsequence compaction. In unsequence compaction process, this command is executed slow due to it takes more time to rewrite all data in overlapped files. However, there won't be any redundant data on the disk eventually.
```
IoTDB> MERGE
......
......@@ -32,10 +32,10 @@ IoTDB> FLUSH root.sg1,root.sg2
## MERGE
合并顺序和乱序数据。当前IoTDB支持使用如下两种SQL手动触发数据文件的合并:
触发层级合并和乱序合并。当前IoTDB支持使用如下两种SQL手动触发数据文件的合并:
* `MERGE` 仅重写重复的Chunk,整理速度快,但是最终磁盘会存在多余数据。
* `FULL MERGE` 将需要合并的顺序和乱序文件的所有数据都重新写一份,整理速度慢,最终磁盘将不存在无用的数据。
* `MERGE` 先触发层级合并,等层级合并执行完后,再触发乱序合并。在乱序合并中,仅重写重复的Chunk,整理速度快,但是最终磁盘会存在多余数据。
* `FULL MERGE` 先触发层级合并,等层级合并执行完后,再触发乱序合并。在乱序合并中,将需要合并的顺序和乱序文件的所有数据都重新写一份,整理速度慢,最终磁盘将不存在无用的数据。
```
IoTDB> MERGE
......
Markdown is supported
0% .
You are about to add 0 people to the discussion. Proceed with caution.
先完成此消息的编辑!
想要评论请 注册