Aleksandr Savonin created FLINK-40584:
-----------------------------------------

             Summary: Bound RocksDB prefix iterators to avoid scanning 
unrelated tombstones
                 Key: FLINK-40584
                 URL: https://issues.apache.org/jira/browse/FLINK-40584
             Project: Flink
          Issue Type: Bug
          Components: Runtime / State Backends
            Reporter: Aleksandr Savonin


The RocksDB state backend creates all prefix iterators with a plain {{new 
ReadOptions()}} and never sets {{iterate_upper_bound}}. A RocksDB 
{{Seek(prefix)}} returns the first *visible* key at or after the prefix. 
Without an upper bound it keeps stepping over deletion markers and overwritten 
entries until it finds a visible key anywhere later in the column family, or 
reaches the end. Flink checks the key prefix in Java only after the seek has 
returned, so that work cannot be avoided.

Restore after a downscale: the timer service constructor 
({{KeyGroupPartitionedPriorityQueue}} peeking every key group) issues one seek 
per key group, i.e. tens of thousands of seeks at a typical max parallelism. If 
the timer column family holds tens of megabytes of tombstones and no live 
timers, which is the normal state right after a large batch of timers has fired 
(for example after a bulk load of the versioned table), every seek scans to the 
end of the column family. 



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

Reply via email to