[jira] [Commented] (KYLIN-2243) TopN memory estimation is inaccurate in some cases

["ASF subversion and git services (JIRA)" <ji...@apache.org>]

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

ASF subversion and git services commented on KYLIN-2243:
--------------------------------------------------------

Commit 1af62e46516b7b9a31d3de5a1a7867f9cb51799b in kylin's branch refs/heads/master from liapan
[ https://gitbox.apache.org/repos/asf?p=kylin.git;h=1af62e4 ]

KYLIN-3738 Edit cube measure may make the decimal type change unexpectly
revert KYLIN-2243 8c0c44b887e2caa21b097c2334f8d21c42462e80


> TopN memory estimation is inaccurate in some cases
> --------------------------------------------------
>
>                 Key: KYLIN-2243
>                 URL: https://issues.apache.org/jira/browse/KYLIN-2243
>             Project: Kylin
>          Issue Type: Bug
>            Reporter: Shaofeng SHI
>            Assignee: Shaofeng SHI
>            Priority: Major
>             Fix For: v2.0.0
>
>
> TopNCounterSerializer.maxLength() and TopNCounterSerializer.getStorageBytesEstimate() might be inaccurate, especially when there are multiple "group by" columns in one TopN measure and some uses long bytes encoding like "fixed_length:16"
> The inaccurate estimation may cause memory issue when using in-mem cubing, and will cause the estimation on final cube size inaccurate.
> The root cause is the data type like "top(100)" doesn't have the info of how long a key can be. So far it uses a default value 4 which is too small when the encoding is something like "fixed_length:16". The solution is extending the expression of data type to "top(100, 16)" to indicate that one key can be 16 bytes long. If the "scale" is absent, use 4 bytes as default.



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