[jira] [Closed] (IOTDB-116) Performance statistic of IOTDB
[ https://issues.apache.org/jira/browse/IOTDB-116?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] suyue closed IOTDB-116. --- > Performance statistic of IOTDB > -- > > Key: IOTDB-116 > URL: https://issues.apache.org/jira/browse/IOTDB-116 > Project: Apache IoTDB > Issue Type: New Feature >Reporter: suyue >Priority: Minor > Labels: pull-request-available > Attachments: image-2019-06-14-09-33-08-958.png, > image-2019-06-17-17-08-32-776.png, image.png > > Time Spent: 20m > Remaining Estimate: 0h > > In order to better grasp the performance of database in practical > application, we add a module to count the time-consuming of each operation. > This module can statistic the avg time-consuming of each operation and the > proportion of each operation fall into a time range.A output example is in > below. This module uses asynchronous operation to reduce the impact on the > normal speed of the database.The queue size is controlled by a param in > iotdb-engine.properties, which is 'performance_stat_memory_in_kb'. The > output is in log_measure.log file. > !image-2019-06-14-09-33-08-958.png! -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Closed] (IOTDB-267) Reduce IO during the process of deserializing chunk header
[ https://issues.apache.org/jira/browse/IOTDB-267?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] suyue closed IOTDB-267. --- Resolution: Fixed > Reduce IO during the process of deserializing chunk header > -- > > Key: IOTDB-267 > URL: https://issues.apache.org/jira/browse/IOTDB-267 > Project: Apache IoTDB > Issue Type: Improvement >Reporter: suyue >Priority: Major > Labels: pull-request-available > Time Spent: 20m > Remaining Estimate: 0h > > When executing a query, IOTDB needs to read ChunkMetaData first and then use > it to read ChunkHeader and ChunkData. Currently, deserializing the chunk > header requires 2 disk read operations. One is reading chunkheader length, > the other is reading chunkheader content. So we considerate to reduce IO > operations in chunk header deserialization. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (IOTDB-267) Reduce IO during the process of deserializing chunk header
suyue created IOTDB-267: --- Summary: Reduce IO during the process of deserializing chunk header Key: IOTDB-267 URL: https://issues.apache.org/jira/browse/IOTDB-267 Project: Apache IoTDB Issue Type: Improvement Reporter: suyue When executing a query, IOTDB needs to read ChunkMetaData first and then use it to read ChunkHeader and ChunkData. Currently, deserializing the chunk header requires 2 disk read operations. One is reading chunkheader length, the other is reading chunkheader content. So we considerate to reduce IO operations in chunk header deserialization. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (IOTDB-253) Time expression
suyue created IOTDB-253: --- Summary: Time expression Key: IOTDB-253 URL: https://issues.apache.org/jira/browse/IOTDB-253 Project: Apache IoTDB Issue Type: Improvement Reporter: suyue In some real-time display systems, applications need to constantly query the latest period of data. For example, query data for the last 5 minutes. However, iotdb currently does not support time operation based on now(). -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Closed] (IOTDB-160) External sort in non-sequential data
[ https://issues.apache.org/jira/browse/IOTDB-160?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] suyue closed IOTDB-160. --- > External sort in non-sequential data > > > Key: IOTDB-160 > URL: https://issues.apache.org/jira/browse/IOTDB-160 > Project: Apache IoTDB > Issue Type: Improvement >Reporter: suyue >Priority: Major > Labels: pull-request-available > Time Spent: 20m > Remaining Estimate: 0h > > For the query of non-sequential data, each chunk is constructed separately as > reader, then merged and sorted. When non-sequential data is large, so the > number of chunks of merge is too large, it may cause the problem of > exhausting memory. So when the number of chunks merged at the same time > reaches a certain limit, the external method is adopted. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (IOTDB-160) External sort in non-sequential data
suyue created IOTDB-160: --- Summary: External sort in non-sequential data Key: IOTDB-160 URL: https://issues.apache.org/jira/browse/IOTDB-160 Project: Apache IoTDB Issue Type: Improvement Reporter: suyue For the query of non-sequential data, each chunk is constructed separately as reader, then merged and sorted. When non-sequential data is large, so the number of chunks of merge is too large, it may cause the problem of exhausting memory. So when the number of chunks merged at the same time reaches a certain limit, the external method is adopted. -- This message was sent by Atlassian JIRA (v7.6.14#76016)
[jira] [Created] (IOTDB-152) Reduce RPC communication for retrieving data types in queries
suyue created IOTDB-152: --- Summary: Reduce RPC communication for retrieving data types in queries Key: IOTDB-152 URL: https://issues.apache.org/jira/browse/IOTDB-152 Project: Apache IoTDB Issue Type: Improvement Reporter: suyue When executing the query statement, after sending the executeStatement request to the server to return the execResp, the client send several TSFetchMetadata requests to the server for fetching data types of the query columns. So we can return dataTypes in executeStatement request to avoid the following fetchmetaData requests. Thank Rui Lei for discovering this problem. -- This message was sent by Atlassian JIRA (v7.6.14#76016)
[jira] [Closed] (IOTDB-47) Aggregate Module
[ https://issues.apache.org/jira/browse/IOTDB-47?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] suyue closed IOTDB-47. -- > Aggregate Module > > > Key: IOTDB-47 > URL: https://issues.apache.org/jira/browse/IOTDB-47 > Project: Apache IoTDB > Issue Type: New Feature >Reporter: suyue >Assignee: suyue >Priority: Major > Labels: features, pull-request-available > Original Estimate: 168h > Time Spent: 20m > Remaining Estimate: 167h 40m > > Aggregate query is a kind of query commonly used in database applications. > IOTDB will support nine queries: count (), max_value (), max_time (), > min_value, min_time (), first (), last (), mean () and sum (). All > aggregation functions inherit the same super class, so if new aggregation > functions are needed in the future, they can be easily extended. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Closed] (IOTDB-59) GroupBy module
[ https://issues.apache.org/jira/browse/IOTDB-59?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] suyue closed IOTDB-59. -- > GroupBy module > -- > > Key: IOTDB-59 > URL: https://issues.apache.org/jira/browse/IOTDB-59 > Project: Apache IoTDB > Issue Type: New Feature >Reporter: suyue >Assignee: suyue >Priority: Major > > h3. Down-Frequency Aggregate Query > Groupby is used to partition the result set according to the user’s given > partitioning conditions and aggregate the partitioned result set. IoTDB > supports partitioning result sets according to time intervals, and by default > results are sorted by time in ascending order. You can also use the [Java > JDBC|http://iotdb.apache.org/Java-api-page,commingsoon] standard interface to > execute related queries. > The GROUP BY statement provides users with three types of specified > parameters: > * Parameter 1: Time interval for dividing the time axis > * Parameter 2: Time axis origin position (optional) > * Parameter 3: The display window(s) (one or more) on the time axis > The actual meanings of the three types of parameters are shown in Figure 1 > below. Among them, the paramter 2 is optional. Next we will give three > typical examples of frequency reduction aggregation: parameter 2 specified, > parameter 2 not specified, and time filtering conditions specified. > !https://user-images.githubusercontent.com/13203019/51577465-e8513380-1ef4-11e9-84c6-d0690f2a8113.jpg|width=597,height=213! > *Figure 1 The actual meanings of the three types of parameters* > h4. Down-Frequency Aggregate Query without Specifying the Time Axis Origin > Position > The SQL statement is: > ''' > select count(status), max_value(temperature) from root.ln.wf01.wt01 group by > (1d, [2017-11-01T00:00:00, 2017-11-07T23:00:00]); > ''' > which means: > Since the user does not specify the time axis origin position, the GROUP BY > statement will by default set the origin at 0 (+0 time zone) on January 1, > 1970. > The first parameter of the GROUP BY statement above is the time interval for > dividing the time axis. Taking this parameter (1d) as time interval and the > default origin as the dividing origin, the time axis is divided into several > continuous intervals, which are [0,1d], [1d, 2d], [2d, 3d], etc. > The second parameter of the GROUP BY statement above is the display window > paramter, which determines the final display range is [2017-11-01T00:00:00, > 2017-11-07T23:00:00]. > Then the system will use the time and value filtering condition in the WHERE > clause and the second parameter of the GROUP BY statement as the data > filtering condition to obtain the data satisfying the filtering condition > (which in this case is the data in the range of [2017-11-01T00:00:00, > 2017-11-07 T23:00:00]), and map these data to the previously segmented time > axis (in this case there are mapped data in every 1-day period from > 2017-11-01T00:00:00 to 2017-11-07T23:00:00:00). -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Closed] (IOTDB-60) Fill module
[ https://issues.apache.org/jira/browse/IOTDB-60?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] suyue closed IOTDB-60. -- > Fill module > --- > > Key: IOTDB-60 > URL: https://issues.apache.org/jira/browse/IOTDB-60 > Project: Apache IoTDB > Issue Type: New Feature >Reporter: suyue >Assignee: suyue >Priority: Major > > In single-point queries, there is often no value under that timestamp. > Usually, the result of this point can be filled with the point nearby. Iotdb > need support two filling methods, linear filling and previous filling. Linear > filling refers to filling the points with the average value of its nearly > previous point and nearly after point. Previous filling refers to filling the > points with the value of its nearly previous point. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
