Hi Faxian, True, we can resolve timestamp conflicts putting values into the same row, good point. Then re-ordering in case of internal clock jump changes behaviour comparing with the list state we have now. In this case, it can be similar to dispersing elements by hash and we can call it a bag, not list.
Best, Andrey On Tue, Apr 16, 2019 at 5:29 AM faxianzhao <faxianz...@gmail.com> wrote: > Hi Yun > I think whether atomic increased number or timestamp, the key point is > disperse the elements in the different keys. > My point is how to design a useful key. > For the atomic increased number, it will array the elements one by one but > I > think the key is useless. Because the max key is not the elements count, > when we implement the remove method. > Currently, for the CountEvictor, TimeEvictor and TTL scenario, we should > iteration all of the elements to find what we want. But if we use timestamp > key, we could terminal the iteration early to save performance or start > from > the available timestamp to iteration the rest elements. > > > > > -- > Sent from: http://apache-flink-mailing-list-archive.1008284.n3.nabble.com/ >
