It should also reduce memory pressure. Large states can cause significant memory pressure during checkpointing. Smaller states also mean faster recovery times since less data needs to be loaded back into memory from the state backend.

I would say before implementing this you might want to benchmark it. Spit vs. Not Split and see what performance improvements you get.

Aside from splitting you can also look at tuning RocksDB in terms of buffer size, block cache size etc. Also checkpoint interval and timeout settings.

If the state is designed in such a way that modifying one field requires loading or rewriting the entire object, the benefits of incremental checkpoints may be limited. So you should try to design your state to minimizes the amount of data rewritten when making updates. This will help optimize incremental checkpoints. Ideally with properly configured incremental checkpoints, only the change to the boolean field would be part of the incremental checkpoint, not the entire large object. But the actual behavior can be affected by how the state is updated and the specifics of your implementation.

I would say there are several factors to state design in Flink. At a minimum you need to consider State Size (how to minimize), Granularity of State which we discussed and should you choose to break down into smaller pieces you need to identify logical components within your state that you can update independently. Access patterns like how you do key lookups (RocksDB or MapState?) etc. or ListState in the case of ordered lists. (We don’t know for example if you are restricted to RocksDB or simply using that at the moment). There is also the possibility of using immutability in the update process. All these factor into proper state design in Flink. Without seeing your state structure and scale its difficult for anyone to advise more specifically.

You get simpler incremental checkpoints when your state objects are immutable, and changes result in new objects, the checkpointing process can more easily identify the differences between checkpoints. It only needs to save the deltas or references to the new versions, rather than trying to figure out what parts of a mutable object have changed.

Additionally Immutable objects are thread-safe since they cannot be changed after creation. This can simplify the design of your application, especially in highly concurrent environments like those involving distributed processing. And you also see this done a lot with other distributed systems. It’s also easier to reason about the application flow since the state at any point in time is a snapshot that won’t change unexpectedly. This can significantly aid in debugging and writing reliable tests.

That being said its not a panacea, and there are some tradeoffs. Implementing immutability might require some restructuring of how you manage your state updates. Instead of modifying fields directly within a large object, you might create a new instance of the object with the updated field(s). This could involve creating builder patterns, copy constructors, or leveraging libraries that support efficient creation of object copies with minimal overhead. You might see increase in memory consumption because of the additional object creation. Its important to benchmark the approach first and consider the trade offs carefully.

I would be interested to hear what others have to say about immutability for Flink State and what their experience has been with it. The criteria for when or when not to use it seems like a good discussion.