hbase-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "ramkrishna.s.vasudevan (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (HBASE-16444) CellUtil#getSumOfCellKeyElementLengths() should consider KEY_INFRASTRUCTURE_SIZE
Date Thu, 18 Aug 2016 08:13:20 GMT

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

ramkrishna.s.vasudevan commented on HBASE-16444:
------------------------------------------------

bq.So in these methods no need to add it as we dont know what kind of cell it is. IMO there
is no need for a change. What is the implication if not added?
It is not about implication. It is just unification. This method is going to be called in
the write path of any cell and we are sure of the Key structure that we are going to right.
For any cell the key part is going to be the same. 
Any specific reason why the INFRA_SIZE should not be calculated here and only the timestamp
and type is enough?  I think we are going to go with the assumption of the key structure
<RK len><RK><Fam len><Fam><Qual><TS><Type> - whatever
may be the type of cell. If this assumption is not going to hold true then even the Bloom
changes will have to be changed or another impl for the new type of Key has to be done. I
have not checked the other estimates** API and how they are being used now.

> CellUtil#getSumOfCellKeyElementLengths() should consider KEY_INFRASTRUCTURE_SIZE
> --------------------------------------------------------------------------------
>
>                 Key: HBASE-16444
>                 URL: https://issues.apache.org/jira/browse/HBASE-16444
>             Project: HBase
>          Issue Type: Bug
>            Reporter: ramkrishna.s.vasudevan
>            Assignee: ramkrishna.s.vasudevan
>            Priority: Minor
>
> Currently CellUtil#getSumOfCellKeyElementLengths() considers 
> {code}
>     return cell.getRowLength() + cell.getFamilyLength() +
>     cell.getQualifierLength() +
>     KeyValue.TIMESTAMP_TYPE_SIZE;
> {code}
> It can consider the 2 byte ROWLEN and 1 byte FAMILY_LEN also because with the current
way of things we are sure how our key is structured.
> But pls note that
> {code}
>     // This will be a low estimate.  Will do for now.
>     return getSumOfCellKeyElementLengths(cell);
> {code}
> It says clearly it is going to be a low estimate. But in the write path there should
be no harm in adding the complete KEY_INFRA_SIZE. 



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Mime
View raw message