; It will be very useful if someone from the committers joins the topic and
> give us some insights what’s going to happen with that feature.
>
>
>
>
>
> Kind Regards,
>
> Georgi
>
>
>
>
>
>
>
> *From:* vino yang
> *Sent:* Thursday, April 25, 2
: dev ; user
Cc: Stefan Richter ; Aljoscha
Krettek ; kklou...@gmail.com Subject: [DISCUSS] Improve
Queryable State and introduce a QueryServerProxy component Hi all, I want to
share my thought with you about improving the queryable state and introducing a
QueryServerProxy component. I think the
5:18 PM
To: dev ; user
Cc: Stefan Richter ; Aljoscha Krettek
; kklou...@gmail.com
Subject: [DISCUSS] Improve Queryable State and introduce a QueryServerProxy
component
Hi all,
I want to share my thought with you about improving the queryable state and
introducing a QueryServerProxy component
Hi Aljoscha,
Thanks for agreeing this is a valuable idea. I know the committers and PMCs
are busy before Flink 1.9 even 2.0. We think it's a good improvement for
queryable state and even some interactive query scenarios.
I don't mind if the timeline will be pulled long.
Although, it could not be
Hi Everyone,
I think this is a good discussion and valuable ideas have come up. However, it
seems none of the committers and/or PMCs currently have time to work on this
subject. Till, who’s focusing on the distributed runtime side, which is touched
quite a bit by queryable state, is currently f
Hi Elias,
OK, I think we do not need to agree on this point of view. In order to make
the discussion more efficient, we need to focus a bit, let's talk about the
query architecture's improvement.
Best,
Vino
Elias Levy 于2019年4月30日周二 上午1:06写道:
> On Fri, Apr 26, 2019 at 8:58 PM vino yang wrote:
On Fri, Apr 26, 2019 at 8:58 PM vino yang wrote:
> I agree with your opinion that "*Flink jobs don't sufficiently meet these
> requirements to work as a replacement for a data store.*". Actually, I
> think it's obviously not Flink's goal.
>
I would not be so sure. When data Artisans introduced
Hi Yu,
OK, now I know your comments more clearly.
Now, answer your two questions:
1. the value of this work:
As I mentioned in the last reply mail to you: "we found the queryable state
is hard to use and it may cause few users to use this function. We may
think the reason and the result affect
TL;DR: IMO a more complete solution is to cover both query and meta request
serving in a new component. We could use the proposal here as step one but
we should have a global plan. And before improving a seemingly not widely
used feature, we'd better weigh the gain and efforts.
Let me clarify the
Hi yu,
Thanks for your reply. I have some inline comment.
Yu Li 于2019年4月28日周日 下午12:24写道:
> Glad to see discussions around QueryableState in mailing list, and it seems
> we have included a bigger scope in the discussion, that what's the data
> model in Flink and how to (or is it possible to) use
Glad to see discussions around QueryableState in mailing list, and it seems
we have included a bigger scope in the discussion, that what's the data
model in Flink and how to (or is it possible to) use Flink as a database. I
suggest to open another thread for this bigger topic and personally I think
Hi Elias,
I agree with your opinion that "*Flink jobs don't sufficiently meet these
requirements to work as a replacement for a data store.*". Actually, I
think it's obviously not Flink's goal. If we think that the database
contains the main two parts(inexactitude): data query and data store. Wha
On Fri, Apr 26, 2019 at 1:41 AM vino yang wrote:
> You are right, currently, the queryable state has few users. And I totally
> agree with you, it makes the streaming works more like a DB.
>
Alas, I don't think queryable state will really be used much in production
other than for ad hoc queries
> > Best,
> > Vino
> >
> >
> >
> > Shi Quan 于2019年4月26日周五 上午10:38写道:
> >
> >> Hi,
> >>
> >> How about take states from RocksDB directly, in this case, TM host is
> >> unnecessary.
> >>
> >> Best
> >>
: vino yang
>> Sent: Thursday, April 25, 2019 10:18:20 PM
>> To: dev; user
>> Cc: Stefan Richter; Aljoscha Krettek; kklou...@gmail.com
>> Subject: [DISCUSS] Improve Queryable State and introduce a
>> QueryServerProxy component
>>
>> Hi all,
>>
>>
take states from RocksDB directly, in this case, TM host is
> unnecessary.
>
> Best
>
> Quan Shi
>
>
> From: vino yang
> Sent: Thursday, April 25, 2019 10:18:20 PM
> To: dev; user
> Cc: Stefan Richter; Aljoscha Krettek; kklou...@g
Queryable State and introduce a QueryServerProxy
component
Hi all,
I want to share my thought with you about improving the queryable state and
introducing a QueryServerProxy component.
I think the current queryable state's client is hard to use. Because it needs
users to know the TaskMana
Hi all,
I want to share my thought with you about improving the queryable state and
introducing a QueryServerProxy component.
I think the current queryable state's client is hard to use. Because it
needs users to know the TaskManager's address and proxy's port. Actually,
some business users who d
18 matches
Mail list logo