Scan and DeleteRange methods for KVTxn
What I'm using: go client v2: https://pkg.go.dev/github.com/tikv/client-go/[email protected]/tikv
What I want: Quick range get method like Scan and range delete method like DeleteRange for TxnClient.
Other questions:
- Is it okay to use both RawKVClient and TxnClient at the same time? AFAIK it is not supported for v1 API
- What's the use case for DeleteRangeTask and RangeTaskRunner? Is it okay to use them concurrently with TxnClient?
Hi @Sandy4999 ,
- I think we can add a rawkv like scan method. But it needs to consider more details, for example, the data obtained by scan needs to be merged with the transaction's MemBuffer. In fact, the current iterator is also implemented internally in batches of scans, but the batchSize cannot be changed. If we make batchSize settable, I wonder if it will meet your needs.
- DeleteRange is supported for txnkv. We will add example about it. You may track the progress from https://github.com/tikv/client-go/issues/100
- RawKVClient and TxnClient cannot be both used in the same cluster. I think it won't change in the near future.
DeleteRangeTaskandRangeTaskRunnercan be used concurrently. As mentioned above, we will add some example.
Sounds great, thank you! And yes, it should be better if batchSize is settable for transactions cuz sometimes we need a pretty big scan buffer (say, scan more than half keys in TiKV), which is probably not suitable for general use.
@disksing There are two more features we need, not sure if they are implemented in TiKV:
- Inline append: append new bytes at the end of an existing value in the server-side, so clients don't have to do a get-modify-set.
- Add conflict range: sometimes we want to watch a certain range instead of existing keys, so that an optimistic transaction is restarted if some key within this range is modified, or new keys are inserted within this range.
The APIs of FoundationDB might be a reference: AppendIfFits and AddReadConflictRange
I think none of them is supported by TiKV. I guess Inline append should be easier to implement. It is kind like CAS method which is already supported by TiKV. Conflict Range is less likely to add to TiKV. Maybe you can consider using txnkv instead to take advantages of transactions utilities.
Okay I see, we will try some workarounds then. Please link here if there is new progress :)