[
https://issues.apache.org/jira/browse/FLINK-10095?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16660258#comment-16660258
]
Andrey Zagrebin commented on FLINK-10095:
-----------------------------------------
Hi [~aitozi], the options for timestamp positioning introduce some trade-offs.
You are right if we have the timestamp at the end, we can expire the whole list
if the last element expires. This works if the list is not constantly appended
because it will update expiration of the last element and we have to
deserialise and check the head anyways to prevent growing indefinitely.
On the other hand, with the current order, we can look into the first element
of the list without deserialising it (it is relevant if serialised element does
not have fixed length) and stop list iteration if it is not expired because the
whole list is not expired then.
> Change the serialisation order in TTL value wrapper
> ---------------------------------------------------
>
> Key: FLINK-10095
> URL: https://issues.apache.org/jira/browse/FLINK-10095
> Project: Flink
> Issue Type: Improvement
> Components: State Backends, Checkpointing
> Reporter: Andrey Zagrebin
> Assignee: Andrey Zagrebin
> Priority: Major
> Labels: pull-request-available
> Fix For: 1.6.0
>
>
> The first implementation of TTL value wrapper has the following serialisation
> order: first user value, then last modification timestamp.
> This was planned for potential optimisation where we could peek at the last
> bytes of last element of list to check whether the whole list expired or not.
> After careful consideration, it is not the frequent case and the list is
> handled per entry mostly.
> Having the fixed part (the timestamp) at the beginning looks more promising
> in future as we can skip looking into the rest of bytes if needed when
> working directly with serialised value.
> This issue suggests to change the serialisation order.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
