test table test_order will be created. which consists of 36 columns:
8 bigint, 13 varchar, 10 decimal, 4 timestamp and 1 int.
Table random_source of the same schema, with random engine, will also be created, which will
be used as the random data source for the test table test_order.
for each iteration, 1000 random rows will be replaced into test_order, with the following arrangements
-
on conflictcolumns specified to 2 columnsone is of type bigint, the other is of type timestamp.
-
values of two columns will be set correlated to value of current iteration
-
failures during executing the
replace intostatement will be ignoredthose failures are mainly due to the conflicts of mutations.
the case driver will record the number of failures thought, so that later in the verification phase, the data can be verified more in detail.
roughly, the sql looks like the following:
replace into test_order on(id, insert_time)
select
id,
{iteration} as id1,
{iteration * 7} as id2,
...
from random limit 1000;
For each 7 iterations, an extra action will be taken:
data of 3 previous iterations will be replaced by them self, e.g.
replace into test_order on(id, insert_time)
(select * from test_order where id1 = 27
union all select * from test_order where id1 = 13
union all select * from test_order where id1 = 9)
as table data being compacted and re-clustered, this lead to data blocks being partially or totally updated.
table maintenance tasks will be executed concurrently, namely the following sqls:
optimize table test_order compact segment;
optimize table test_order compact;
optimize table test_order purge;
alter table test_order recluster;
during execution of the above sqls, errors will be ignored (mainly due to the conflicts of mutations). The case driver just keep trying executing each of the sqls as soon as possible (to simulate high concurrency scenario).
After iterations of replace into tasks done, the table maintenance tasks will be stopped.
Then the followings will be verified:
-
value of successfully executed replace into statements
-
count of
test_ordershould equal to the number of successfully executedreplace intostatements, multiplied by 1000.caveat: there might be false negative in this case
failure of execution the
replace intostatement at client side, does not mean that the execution is definitely failed at server side(network error, etc). -
count of each distinct value of
id1should equal to 1000, since for each iteration, 1000 rows are inserted with the same(but distinct) value ofid1.
-
-
value of correlated columns
for all the rows in
test_order, value ofid2should equal to value ofid1multiplied by 7. -
full table scan should work
NOTE:
after the setup phase, at any time, the following invariant should hold:
select count() from test_order where id2 != id1 * 7eq 0select count() from (select count() a, id1 from test_order group by id1) where a != 1000")eq 0select * from test_order ignore_resultshould work
-
set DSN
Set the environment variable
DATABAEND_DSNto the connection string of the database to be testede.g.
export DATABEND_DSN="databend://root:@localhost:8000/?sslmode=disable" -
kick off the test
cargo run -r -- [ITERATION]Where the
[ITERATION]is the number of iterations to run the test for. If not specified, the default is 1000 iterations.At the end of execution, if everything is OK, logs like the following should be printed to the console:
========================== ====verify table state==== ========================== CHECK: value of successfully executed replace into statements CHECK: value of correlated column CHECK: full table scanning =========================== ====== PASSED ==== ===========================Otherwise, error messages will be printed to the console.