[
https://issues.apache.org/jira/browse/FLINK-19438?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17203058#comment-17203058
]
Kostas Kloudas edited comment on FLINK-19438 at 9/28/20, 7:36 AM:
------------------------------------------------------------------
[~sheep] thanks for opening the issue. Queryable State is a feature mainly
intended for debugging purposes and currently we do not actively add new
features. In general, we recommend to go through the State Processor API, as
you mentioned.
Supporting features like the one you mention has already been proposed. But the
increased complexity of trying to support everything through Queryable State is
one of the reasons why the State Processor API was introduced. This API intends
(among other things) to decouple to Processing/Write Path of state from the
Querying Path so that we can add features to one without impacting the other.
As an example of how one can (negatively) affect the other, you can see
https://issues.apache.org/jira/browse/FLINK-5961, where Queryable State would
require increased locking to guard against concurrent updates, which, in turn,
could negatively impact performance during stream processing.
was (Author: kkl0u):
[~sheep] thanks for opening the issue. Queryable State is a feature mainly
intended for debugging purposes and currently we do not actively add new
features. For other cases we recommend to go through the State Processor API,
as you mentioned.
Supporting features like the one you mention has already been proposed. But the
increased complexity of trying to support everything through Queryable State is
one of the reasons why the State Processor API was introduced. This API intends
(among other things) to decouple to Processing/Write Path of state from the
Querying Path so that we can add features to one without impacting the other.
As an example of how one can (negatively) affect the other, you can see
https://issues.apache.org/jira/browse/FLINK-5961, where Queryable State would
require increased locking to guard against concurrent updates, which, in turn,
could negatively impact performance during stream processing.
> Queryable State needs to support both read-uncommitted and read-committed
> --------------------------------------------------------------------------
>
> Key: FLINK-19438
> URL: https://issues.apache.org/jira/browse/FLINK-19438
> Project: Flink
> Issue Type: Wish
> Components: Runtime / Queryable State
> Reporter: sheep
> Priority: Major
>
> Flink exposes its managed keyed (partitioned) state to the outside world and
> allows the user to query a job’s state from outside Flink. From a traditional
> database isolation-level viewpoint, the queries access uncommitted state,
> thus following the read-uncommitted isolation level.
> I fully understand Flink provides read-uncommitted state query in order to
> query real-time state. But the read-committed state is also important (I
> cannot fully explain). From Flink 1.9, querying even modifying the state in
> Checkpoint has been implemented. The state in Checkpoint is equivalent to
> read-committed state. So, users can query read-committed state via the state
> processor api.
> *Flink should provide users for configuration of isolation level of
> Queryable State by integration of the two levels of state query.*
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
