Hi, The email also confusing me...
1. Where is the queryResult.csv? 2. What the projectID refers to? 3. Can you describe the hardware environment? 4. As this is for query performance test, how much data in IoTDB already? (For a database, the query performance is quite influenced by the data files) 5. though this email can show the performance to let potential users and developers know how good IoTDB is, it is better if they can reproduce the result. So, how to help them to do that? 6. One more suggestion, how about putting all the emails about the future automatically test into a thread? e.g. - [Auto] IoTDB Query Performance Test - Re:[Auto] IoTDB Query Performance Test - Re:Re:..... It is friendly for users who use a modern email application... Best, ----------------------------------- Xiangdong Huang School of Software, Tsinghua University 黄向东 清华大学 软件学院 冯 庆新 <[email protected]> 于2019年8月30日周五 上午12:54写道： > Hi Chris > > > > The answer would be “no”.This is just a test for automatic notice test > result of IoTDB. > > > > BR > > > > Feng > > > > > > > > 发送自 Windows 10 版邮件<https://go.microsoft.com/fwlink/?LinkId=550986>应用 > > > > ________________________________ > 发件人: Christofer Dutz <[email protected]> > 发送时间: Friday, August 30, 2019 3:10:46 PM > 收件人: [email protected] <[email protected]> > 主题: Re: IoTDB Query Performance Test # 35 > > Just a quick question ... > > Are we going to be getting more of these emails? I had to moderate 2 of > them this morning. > > Chris > > Am 30.08.19, 01:27 schrieb "[email protected]" <[email protected]>: > > This e-mail is generated by Jenkins auto-test project. History query > results are shown in attachment. > > The first three group tests are based on the last release version > which can be use as baseline for comparing the following test results. The > last 6*3=18 rows correspond to the 6 types of query test based on latest > master branch. After ingestion test, three groups of query tests will be > conducted. The first group gets the none-cache query performance results > while the second and third groups get cached. Since query test is after > ingestion query, the query result can be easily mapped to IoTDB version by > looking at projectID. > > > queryResult.csv introduction (except obvious fields): > Field: Description > > projectID: Unique test instance mark. > > avg: Average time cost of all query operations. [ms] > > midAvg: Average time cost of query operations without 5% head and > tail. [ms] > > min: Min time cost of all query operations. [ms] > > max: Max time cost of all query operations. [ms] > > p1: 1 percentile of all query operations time cost. [ms] > > totalTimes: Max accumulative query operation time cost of the clients. > [s] > > totalPoints: Number of total query result points. > > queryNumber: Number of query operation. > > Eight Query Types: > 1. aggTi: Aggregation Query with Time Filter > query workload: > number of involved sensor in each query: 1 > number of involved device in each query: 1 > aggregation function: max_value > time filter range: 250000 ms > 500 query operations > example: > SELECT max_value(s_72) FROM root.perform.group_0.d_68 WHERE time >= > 2018-08-30 02:55:50 AND time <= 2018-08-30 03:00:00 > > 2. aggVa: Aggregation Query with Value Filter > query workload: > number of involved sensor in each query: 1 > number of involved device in each query: 1 > aggregation function: max_value > time filter range: 250000 ms > 500 query operations > example: > SELECT max_value(s_25) FROM root.perform.group_1.d_102 WHERE > root.perform.group_1.d_102.s_25 > 1.0 > > > 3. criteri: Criteria Query (Simple Query with Time and Value Filter) > query workload: > number of involved sensor in each query: 1 > number of involved device in each query: 1 > time filter range: 250000 ms > value filter: > 1 > 500 query operations > example: > SELECT s_35 FROM root.perform.group_4.d_462 WHERE time >= 2018-08-30 > 03:10:00 AND time <= 2018-08-30 03:14:10 AND > root.perform.group_4.d_462.s_35 > 1.0 > > 4. exact: Exact Query > query workload: > number of involved sensor in each query: 1 > number of involved device in each query: 1 > 500 query operations > example: > SELECT s_75 FROM root.perform.group_7.d_731 WHERE time = 2018-08-30 > 02:25:00 > > 5. group: Group-By Query > query workload: > number of involved sensor in each query: 1 > number of involved device in each query: 1 > time filter range: 250000 ms > time unit: 20000 ms > aggregation function: max_value > 500 query operations > example: > SELECT max_value(s_38) FROM root.perform.group_11.d_1171 GROUP > BY(20000ms, 1535558400000,[2018-08-30 03:07:30,2018-08-30 03:11:40]) > > 6. latest: MAX_TIME Query > query workload: > number of involved sensor in each query: 1 > number of involved device in each query: 1 > aggregation function: max_time > 500 query operations > example: > SELECT max_time(s_0) FROM root.performf.group_0.d_2 > > 7. limit: limit Query > query workload: > number of involved sensor in each query: 1 > number of involved device in each query: 1 > time filter range: 250000 ms > 500 query operations > example: > SELECT * FROM root.perform.group_0.d_0 limit 5 offset 5 slimit 5 > soffset 5 > > 8. range: Range Query > query workload: > number of involved sensor in each query: 1 > number of involved device in each query: 1 > time filter range: 250000 ms > 500 query operations > example: > SELECT s_0 FROM root.performf.group_0.d_2 WHERE time >= 2010-01-01 > 12:00:00 AND time <= 2010-01-01 12:04:10 > > > Configurations: > > Data set is generated by ingestion test: > 20 storage groups > 2000 devices in total > 100 sensors per device > 50% out-of-order data > > Hardware: > 32G memory > 8 threads CPU > 1000Mbit ethernet > > IoTDB: > MAX_HEAP_SIZE="20G" > meta_data_cache_enable=true(as default) > filemeta_chunkmeta_free_memory_proportion=3:6:10(as default) > The rest parameters are default. > >
