[ 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)