[ 
https://issues.apache.org/jira/browse/FLINK-19709?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Flink Jira Bot updated FLINK-19709:
-----------------------------------
    Labels: auto-deprioritized-major features stale-minor  (was: 
auto-deprioritized-major features)

I am the [Flink Jira Bot|https://github.com/apache/flink-jira-bot/] and I help 
the community manage its development. I see this issues has been marked as 
Minor but is unassigned and neither itself nor its Sub-Tasks have been updated 
for 180 days. I have gone ahead and marked it "stale-minor". If this ticket is 
still Minor, please either assign yourself or give an update. Afterwards, 
please remove the label or in 7 days the issue will be deprioritized.


> Support KeyedSortedMapState in DataStream API
> ---------------------------------------------
>
>                 Key: FLINK-19709
>                 URL: https://issues.apache.org/jira/browse/FLINK-19709
>             Project: Flink
>          Issue Type: New Feature
>          Components: API / DataStream, Runtime / State Backends
>            Reporter: Sean Z
>            Priority: Minor
>              Labels: auto-deprioritized-major, features, stale-minor
>
> Current DataStream API doesn't have SortedMapState supported. There are lots 
> of use cases based on sorted time-series data like range-query or 
> higher/lower key fetch, and ordered data seems like a nature of time-series 
> stream processing. Therefore, we propose to support the KeyedSortedMapState 
> feature.
>   
>  There were some previous discussions FLINK-6219 about SortedMapState, and 
> the thread was closed because blink code might cover this feature. However, 
> the [blink 
> code|https://github.com/apache/flink/blob/blink/flink-runtime/src/main/java/org/apache/flink/runtime/state/keyed/KeyedSortedMapState.java]
>  wasn't merged into the master branch since then. The major concern is the 
> inconsistent comparison between heap/off-heap state backends. In RocksDB, the 
> comparison should be based on bytes, which makes generic key types support 
> challenging, and in heap state backend, the comparison is more about 
> Comparable interface.
>   
>  There are two possible solutions to this issue as [discussed in dev email 
> list|http://mail-archives.apache.org/mod_mbox/flink-dev/202010.mbox/%3CCABKsfK6meYPPbxChC_jWzYn2knLTJv%2BpjFcBkvnMf3mRWC6LWw%40mail.gmail.com%3E],
>   
>  1. There is a prototype feature called TemporalState which could limit the 
> key type to Long type. It makes sense for most of the use cases are about 
> timestamp as a key but it brings limitations to support generic key types. We 
> also need to gracefully handle negative long.
>   
>  2. We keep the different sorting behavior of different state backends and 
> set it to bytes comparison for given serialization by default in off-heap 
> state backends. Let users provide their own specific serializer if they want 
> to sort some customized type on RocksDB. This solution could start with blink 
> implementation, which has already supported  serializing various key types 
> (almost all the atomic types) into an ordered bytes. 
> [code|https://github.com/apache/flink/tree/blink/flink-libraries/flink-table/src/main/java/org/apache/flink/table/typeutils/ordered]
>   



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

Reply via email to