You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@flink.apache.org by "aitozi (JIRA)" <ji...@apache.org> on 2018/10/15 02:26:00 UTC

[jira] [Commented] (FLINK-10095) Change the serialisation order in TTL value wrapper

    [ https://issues.apache.org/jira/browse/FLINK-10095?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16649655#comment-16649655 ] 

aitozi commented on FLINK-10095:
--------------------------------

Hi, [~azagrebin]
I have a little question here:
If we use the order uservalue first, we can also work directly with serialized value by skipping looking into the rest of 8 bytes at the end?So I think do not need to change the order of serialization, do you think so?  And can also optimize when expire the liststate.  

> 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)