ASF GitHub Bot commented on FLINK-9070:

Github user sihuazhou commented on the issue:

    @StefanRRichter , the reason I prefer this approach is that:
    - From the comment in RocksDB's source we can find that deleteRange() 
should be used for deleting big range, what if the entries num of the map is 
not that big.
    - From the comments we can also find that deleteRange() would hurt the read 
performance, so we should consider to set ReadOptions::ignore_range_deletions = 
true to avoid the negative effect by deleteRange(), but if we use it for 
MapState.clear(), it seems that we can't set 
ReadOptions::ignore_range_deletions = true.
    And current approach should not bring any downside, what do you think?

> Improve performance of RocksDBMapState.clear()
> ----------------------------------------------
>                 Key: FLINK-9070
>                 URL: https://issues.apache.org/jira/browse/FLINK-9070
>             Project: Flink
>          Issue Type: Improvement
>          Components: State Backends, Checkpointing
>    Affects Versions: 1.6.0
>            Reporter: Truong Duc Kien
>            Assignee: Sihua Zhou
>            Priority: Major
>             Fix For: 1.6.0
> Currently, RocksDBMapState.clear() is implemented by iterating over all the 
> keys and drop them one by one. This iteration can be quite slow with: 
>  * Large maps
>  * High-churn maps with a lot of tombstones
> There are a few methods to speed-up deletion for a range of keys, each with 
> their own caveats:
>  * DeleteRange: still experimental, likely buggy
>  * DeleteFilesInRange + CompactRange: only good for large ranges
> Flink can also keep a list of inserted keys in-memory, then directly delete 
> them without having to iterate over the Rocksdb database again. 
> Reference:
>  * [RocksDB article about range 
> deletion|https://github.com/facebook/rocksdb/wiki/Delete-A-Range-Of-Keys]
>  * [Bug in DeleteRange|https://pingcap.com/blog/2017-09-08-rocksdbbug]

This message was sent by Atlassian JIRA

Reply via email to