You are viewing a plain text version of this content. The canonical link for it is here.
Posted to jira@kafka.apache.org by "Guozhang Wang (JIRA)" <ji...@apache.org> on 2018/02/15 19:42:00 UTC

[jira] [Issue Comment Deleted] (KAFKA-5285) Optimize upper / lower byte range for key range scan on windowed stores

     [ https://issues.apache.org/jira/browse/KAFKA-5285?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Guozhang Wang updated KAFKA-5285:
---------------------------------
    Comment: was deleted

(was: [~davispw] [~xvrl] Thinking about this a bit more, I think we can provide a better heuristic to define the upper and lower bound for window store {{fetch(keyFrom, keyTo, timeFrom, timeTo)}} indeed, which is to just consider the following four combinations:

1. keyFrom + minSuffix
2. keyTo + minSuffix
3. keyFrom + maxSuffix
4. keyTo + maxSuffix

where minSuffix = timeFrom + seq0, and maxSuffix = timeTo + seqMAX. And then we just pick the smallest and largest among these four as lower and upper range, to replace the current {{OrderedBytes}} implementations. WDYT?)

> Optimize upper / lower byte range for key range scan on windowed stores
> -----------------------------------------------------------------------
>
>                 Key: KAFKA-5285
>                 URL: https://issues.apache.org/jira/browse/KAFKA-5285
>             Project: Kafka
>          Issue Type: Improvement
>          Components: streams
>            Reporter: Xavier Léauté
>            Assignee: Xavier Léauté
>            Priority: Major
>              Labels: performance
>
> The current implementation of {{WindowKeySchema}} / {{SessionKeySchema}} {{upperRange}} and {{lowerRange}} does not make any assumptions with respect to the other key bound (e.g. the upper byte bound does not depends on lower key bound).
> It should be possible to optimize the byte range somewhat further using the information provided by the lower bound.
> More specifically, by incorporating that information, we should be able to eliminate the corresponding {{upperRangeFixedSize}} and {{lowerRangeFixedSize}}, since the result should be the same if we implement that optimization.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)