Do not do truncate table operation by default

[vponomaryov]

If it is needed to truncate a DB table, then just use
following new parameter:

  -truncate-table

With this change it will be possible to use multiple scylla-bench
concurrent commands which won't truncate each other's data.

Closes: #30
Closes: #130

[dkropachev]

@vponomaryov , if you want to run them in validation mode it can work only by chance. If in regular mode, table won't be truncated.

To make it work in parallel on the same table we need somehow split targeted primary key values between runners.

[vponomaryov]

@vponomaryov , if you want to run them in validation mode it can work only by chance. If in regular mode, table won't be truncated.

To make it work in parallel on the same table we need somehow split targeted primary key values between runners.

Different concurrent commands use index offsets.
So, data is not overlapped. And chance is 100% in this case.

[dkropachev]

@vponomaryov , if you want to run them in validation mode it can work only by chance. If in regular mode, table won't be truncated.
To make it work in parallel on the same table we need somehow split targeted primary key values between runners.

Different concurrent commands use index offsets. So, data is not overlapped. And chance is 100% in this case.

partition-offset - works only for sequential workload

[vponomaryov]

@vponomaryov , if you want to run them in validation mode it can work only by chance. If in regular mode, table won't be truncated.
To make it work in parallel on the same table we need somehow split targeted primary key values between runners.

Different concurrent commands use index offsets. So, data is not overlapped. And chance is 100% in this case.

partition-offset - works only for sequential workload

Changed the logic to consider the workload type.

[dkropachev]

@vponomaryov , if you want to run them in validation mode it can work only by chance. If in regular mode, table won't be truncated.
To make it work in parallel on the same table we need somehow split targeted primary key values between runners.

Different concurrent commands use index offsets. So, data is not overlapped. And chance is 100% in this case.

partition-offset - works only for sequential workload

Changed the logic to consider the workload type.

What I meant is that if your purpose to run couple of s-b in parallel targeting same table, it should be solved in a such a way that would cover all the cases, not only sequential.

From first look it should be pretty easy, there is alreayd concept of threadId that makes internal thread to target particular partitions only, if we somehow make it offset for every s-b instance

[vponomaryov]

@dkropachev done

[fruch]

LGTM

[dkropachev]

You also forgot about RangeScan,
It should go into RangeOffset and RangeCount

I also would prefere different CLI, something like:

   --worker-id N

where partitionOffset := (workerID - 1) * partitiionCount and truncateTable := workerID != 0

[dkropachev]

Suggested change

	pkOffset := int64(threadId) + basicPkOffset
	pkOffset := int64(threadId) + basicPkOffset
	pkCount += basicPkOffset

[vponomaryov]

Why do you propose to summarize the partition "offset" with the partition "count"?
Both serve different goals.

[fruch]

You also forgot about RangeScan, It should go into RangeOffset and RangeCount

I also would prefere different CLI, something like:

   --worker-id N

where partitionOffset := (workerID - 1) * partitiionCount and truncateTable := workerID != 0

how worker ID is related to the question ?, user should be able to say, should the stress tool truncate or not, same as in c-s. I fail to see how this is related to the title of this PR.

[vponomaryov]

You also forget about RangeScan, It should go into RangeOffset and RangeCount

I didn't forgot about "scan". It is explicitly mentioned to not support partition offsets.
Why? I am not aware about the use cases for it.

The main use case here is ability to disable truncation of a table with clear purpose - running multiple scylla-bench commands against single DB table for having cumulative "population" effect and not cumulative "breaking" one.

I also would prefere different CLI, something like:

   --worker-id N

where partitionOffset := (workerID - 1) * partitiionCount and truncateTable := workerID != 0

I have 2 concerns with this proposal:

1. Why should user count number of workers if he may avoid it? I don't see sense in it.
2. Truncation of a table should not be dependent on worker numbers at all. User decides whether he needs it or not, without relation to workers number.

[fruch]

• lets split this one to it's two commit, and them test separately

[vponomaryov]

• lets split this one to it's two commit, and them test separately

Splitted the second commit to another PR here:

• Make all write-capable workloads support partition offset #150

[dkropachev]

@vponomaryov , my assumption was that data validation won't work if s-b instances are writing to the same table, which is not the case, which changes a lot and now I am ok with your cli

[roydahan]

seems like we can merge.