[jira] [Created] (IOTDB-1697) Record data set-out-of-order write mode currently can only select 1. If you select 0, there will be timestamp collisions, which will affect the correctness verification.

["xiaozhihong (Jira)" <ji...@apache.org>]

xiaozhihong created IOTDB-1697:
----------------------------------

             Summary: Record data set-out-of-order write mode currently can only select 1. If you select 0, there will be timestamp collisions, which will affect the correctness verification.
                 Key: IOTDB-1697
                 URL: https://issues.apache.org/jira/browse/IOTDB-1697
             Project: Apache IoTDB
          Issue Type: Improvement
          Components: Benchmark
            Reporter: xiaozhihong


execute steps:

Take the record data set (locally generated TEXT file) as an example;

This problem should not exist if the double write database is in principle.
Step1:

use the function of generating data sets (using out-of-order mode) to generate a certain amount of data.

Step2:

write the data set generated in the first step to IoTDB.

Step3:

use the query mode to verify whether the data in the IoTDB is consistent with the records in the local TEXT.

Issue 1:

If the out-of-order mode is turned on, roo.test.g_0.d_0.s_0 creates a data of 1 at time 1 benchmark, and then creates a value of 5 for time 1 when the subsequent out-of-order data is generated.

At this time, query select s_0 from roo.test.g_0.d_0 where time=1 in the IoTDB database, and the result is 5; but it does not match the first record.

If the tool reports an error, it means that the tool judgment criterion is incorrect (because the query is 5 is correct)

If the tool does not report an error, then explain why.

Notes:

There are currently two benchmark out-of-order generation modes

# 0 Disordered mode according to Poisson distribution (the problem described in the above steps will occur)

# 1 Batch insert out of order mode (the problem described in the above steps will not occur)

OUT_OF_ORDER_MODE=1

Issue 2:

Need to consider whether the 0 mode can also support correctness verification

Even if the timestamp collides, it must be able to support correctness verification.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)