THIS IS A TEST INSTANCE. ALL YOUR CHANGES WILL BE LOST!!!!
...
- TTL will be supported for both event time and processing time
- TTL starts to count down when the entry is created by default. Users can specifying TTL trigger policy (see example below) to decide if a state’s TTL will be refreshed upon read or/and update or/and read. More on this later.
- User state will stay at least its TTL amount of time, which means TTL policy in Flink State is exact or relaxed TTL. at least a relaxed TTL, or exact TTL for the better.
TTL Policy
How to count the start time of TTL of a user state? Or, in another way to rephrase it, does Flink support extending/refreshing TTL for a user state?
...
- TTL implementation is independent of state backends, it only relies on the abstraction of TimerService
- Because of (1), migration and compatibility can reuse existing solution
- This design will support both event time and processing time natively
- It has at most one timer for each keyed user state with TTL all the time
Note: the main design decision is to base this feature on Flink's timer service, and exact TTL is a by-product. Not the other way around. At V2, we can relax the TTL if there's any major perf improvement, e.g. by coalescing timers.
Cons:
- In TTL policy situation 2, we need to store a timer (basically a long) for each TTL keyed user state. There’ll be a little bit memory overhead.
...