Re: How to use RocksDBStateBackend predefined options
We already found the programmatic way to configure RocksDB was not so friendly in our Alibaba's production environment, and refactored it by wrapping customer configurations for RocksDB. We pre-wrapped configurations such as block cache size, whether to cache index&filter into block cache size, number of background flush threads, and could get the them from TaskManagerConfiguration if users want to change the default values. But I think our community's way using options factory could also make sense if sophisticated user want to make fine-grained tuning which might use configuration not included in our pre-wrapped configuration. We might combine these two kind of operations together.
I'd like to create a JIRA about this improvement, what's your opinions?
From: Thomas Weise <thw@xxxxxxxxxx>
Sent: Tuesday, November 13, 2018 1:53
Subject: Re: How to use RocksDBStateBackend predefined options
Sounds good. Perhaps it would also be good to allow the user to specify an
options factory in flink-conf.yaml for more flexibility?
On Mon, Nov 12, 2018 at 9:48 AM Stefan Richter <s.richter@xxxxxxxxxxxxxxxxx>
> Ufuk is right, for historical reasons there is currently only the
> programatic way but I think nothing speaks fundamentally against offering
> configuration via config in the future (maybe just a lot of config keys
> must be introduced to cover all options).
> > On 9. Nov 2018, at 22:52, Ufuk Celebi <uce@xxxxxxxxxx> wrote:
> > Hey Thomas,
> > On Fri, Nov 9, 2018 at 6:07 PM Thomas Weise <thw@xxxxxxxxxx> wrote:
> >> Is there a way to activate the predefined options via configuration /
> >> conf.yaml? Or only programmatically, like in ? The difficulty with
> >> programmatic route (assuming this works now), is that in my case the
> >> is Beam and I'm not writing the code that submits the job.
> > AFAIK no. You can only do it programmatically at the moment .
> > Having the option to configure all settings through the configuration
> > file seems to be a valid feature request to me.
> > @Stefan Richter (cc'd): Are there any reasons that speak against
> > exposing these options via the configuration file in your opinion?
> > Best,
> > Ufuk
> >  Looking at the code in  and , the only options that are
> > exposed via the configuration file are local directories and the timer
> > service factory.
> > 
> >