store like RocksDB, it is easier to implement by uploading files of
>> specific time asynchronously.
>>
>> Moreover if you want to store your state basically in memory, then why
>> not using the HashMapStateBackend. It saves the overhead of serialization
>> and deserializ
nd. It saves the overhead of serialization and
> deserialization and may achieve better performance compared with Redis I
> guess.
>
>
> Best,
> Zakelly
>
> On Tue, Jan 30, 2024 at 2:15 PM Chirag Dewan via user <
> user@flink.apache.org> wrote:
>
> Hi,
>
th Redis I guess.
Best,Zakelly
On Tue, Jan 30, 2024 at 2:15 PM Chirag Dewan via user
wrote:
Hi,
I was looking at the FLIP-254: Redis Streams Connector and I was wondering if
Flink ever considered Redis as a state backend? And if yes, why was it
discarded compared to RocksDB?
If someone ca
tter performance compared with Redis I
> guess.
>
>
> Best,
> Zakelly
>
> On Tue, Jan 30, 2024 at 2:15 PM Chirag Dewan via user <
> user@flink.apache.org> wrote:
>
>> Hi,
>>
>> I was looking at the FLIP-254: Redis Streams Connector and I was
&g
erformance compared with Redis I
guess.
Best,
Zakelly
On Tue, Jan 30, 2024 at 2:15 PM Chirag Dewan via user
wrote:
> Hi,
>
> I was looking at the FLIP-254: Redis Streams Connector and I was
> wondering if Flink ever considered Redis as a state backend? And if yes,
> why was
Hi Chirag,
Indeed, the possibility of using Redis as a state backend for Flink has
been considered in the past. You can find a detailed discussion about this
topic in the JIRA issue FLINK-3035[1] as well as in the comments section of
this PR[2].
The outcome of these discussions was that Redis is
Hi,
I was looking at the FLIP-254: Redis Streams Connector and I was wondering if
Flink ever considered Redis as a state backend? And if yes, why was it
discarded compared to RocksDB?
If someone can point me towards any deep dives on why RocksDB is a better fit
as a state backend, it would be
