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-19309) Lower HConstants#MAX_ROW_LENGTH as guardrail in order to avoid HBASE-18987
Date Tue, 21 Nov 2017 14:53:00 GMT

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

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

Am seeing this issue now and did not realise there was a parent issue that caused this. I
read all the discussions there. I agree to all the points in HBASE-18987.
bq.So what if there a crazy very long table name? I feel like this has to be handled there
at split code area only. Get the split key which is less that max RK length. And then check
by adding the extra things like tabName, where we reach wrt put's rk length. Accordingly truncate
the split key.
This seems to be difficult in terms of impl but ideally we need to do some thing like this
only I believe.
Because in the place where we actually get the split key it is at the block index layer and
later in the Split code we get this split key and add all the meta data like table name.
Should we also add a restriction on the length of TableName? In terms of existing users this
is going to be a problem if they have a table with big name.



> Lower HConstants#MAX_ROW_LENGTH as guardrail in order to avoid HBASE-18987
> --------------------------------------------------------------------------
>
>                 Key: HBASE-19309
>                 URL: https://issues.apache.org/jira/browse/HBASE-19309
>             Project: HBase
>          Issue Type: Bug
>          Components: HFile, regionserver
>            Reporter: Esteban Gutierrez
>
> As discussed in HBASE-18987. A problem of having a row about the maximum size of a row
(Short.MAX_VALUE) is when a split happens, there is a possibility that the midkey could be
that row and the Put created to add the new entry in META will exceed the maximum row size
since the new row key will include the table name and that will cause the split to abort.
Since is not possible to raise that row key size in HFileV3, a reasonable solution is to reduce
the maximum size of row key in order to avoid exceeding Short.MAX_VALUE.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

Mime
View raw message