[ 
https://issues.apache.org/jira/browse/FLINK-8639?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16369214#comment-16369214
 ] 

ASF GitHub Bot commented on FLINK-8639:
---------------------------------------

Github user StefanRRichter commented on a diff in the pull request:

    https://github.com/apache/flink/pull/5465#discussion_r169099355
  
    --- Diff: 
flink-contrib/flink-statebackend-rocksdb/src/main/java/org/apache/flink/contrib/streaming/state/RocksDBMapState.java
 ---
    @@ -319,6 +321,9 @@ private UV deserializeUserValue(byte[] rawValueBytes) 
throws IOException {
                /** The raw bytes of the value stored in RocksDB. */
                private byte[] rawValueBytes;
     
    +           /** The offset of User Key offset in raw key bytes. */
    +           private final int userKeyOffset;
    --- End diff --
    
    This value is basically a constant on a per-backend level and we could 
remember the value in the MapState itself, no need to replicate it into every 
entry. It can then still be recalled from there for `deserializeUserKey(...)`.


> Fix always need to seek multiple times when iterator RocksDBMapState
> --------------------------------------------------------------------
>
>                 Key: FLINK-8639
>                 URL: https://issues.apache.org/jira/browse/FLINK-8639
>             Project: Flink
>          Issue Type: Improvement
>          Components: State Backends, Checkpointing
>    Affects Versions: 1.4.0
>            Reporter: Sihua Zhou
>            Assignee: Sihua Zhou
>            Priority: Critical
>             Fix For: 1.5.0
>
>
> Currently, almost every time we want to iterator a RocksDBMapState we need to 
> do seek at least 2 times (Seek is a poor performance action for rocksdb cause 
> it can't use the bloomfilter). This is because `RocksDBMapIterator` use a 
> `cacheEntries` to cache the seek values every time and the `cacheEntries`'s 
> init size is 1.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

Reply via email to