hbase-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Anoop Sam John (JIRA)" <j...@apache.org>
Subject [jira] [Comment Edited] (HBASE-13393) Add facility to disable tags after parent goes in
Date Sat, 23 May 2015 03:12:18 GMT

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

Anoop Sam John edited comment on HBASE-13393 at 5/23/15 3:12 AM:
-----------------------------------------------------------------

We can do another smart way. By default we use KeyValueCodec which is not supporting passing
of tags with Cell from/to client. So when Mutation cells come into server, we use this Codec's
Decoder to read stream of bytes and convert them to Cells.  We make KeyValue objects now but
we can make NoTagsKeyValue as we are sure we are not supporting passing of tags with this
Codec.  The getTagsLength() usage is cheap in this class.
Still I have a concern over using volatile int and adding tagsLength from each Cell. We might
go out of range if too many cells we hold in memstore? Rare chance. May be we just need to
keep this info as a boolean state only?  This can relax the cost of getTagsLength() with KeyValue
also.
{code}
boolean isTags = false;
if(!isTags || cell.getTagsLength > 0 ){
  isTags = true;
}
{code}
In a system with cells having tags (say it is visibility or per cell ACL system) only for
the 1st cell the getTagsLength has to get called. (Remember here we are going to get KeyValue
objects not NoTagsKeyValue)
Only downside is we can not do reverse op on remove(Cell).   But IMO that is ok. Let us not
handle. A cell with tags was added but got removed because this transaction got failed.  All
other cells in this memstore are with no tags.  Still just because of this single Cell, we
will think that tags are present and we will write 0 tags length for all the cells when we
flush.  But this should be ok I believe.  The scenario itself is rare that only one cell added
was having tagslength and that only got removed.  Even if it happens, the next compaction
will handle and avoid tagsLength write in resulting new file.
The boolean also we can make non volatile only? 


was (Author: anoop.hbase):
We can do another smart way. By default we use KeyValueCodec which is not supporting passing
of tags with Cell from/to client. So when Mutation cells come into server, we use this Codec's
Decoder to read stream of bytes and convert them to Cells.  We make KeyValue objects now but
we can make NoTagsKeyValue as we are sure we are not supporting passing of tags with this
Codec.  The getTagsLength() usage is cheap in this class.
Still I have a concern over using volatile int and adding tagsLength from each Cell. We might
go out of range if too many cells we hold in memstore? Rare chance. May be we just need to
keep this info as a boolean state only?  This can relax the cost of getTagsLength() with KeyValue
also.
{code}
boolean isTags = false;
if(!isTags || cell.getTagsLength > 0 ){
  isTags = true;
}
In a system with cells having tags (say it is visibility or per cell ACL system) only for
the 1st cell the getTagsLength has to get called. (Remember here we are going to get KeyValue
objects not NoTagsKeyValue)
Only downside is we can not do reverse op on remove(Cell).   But IMO that is ok. Let us not
handle. A cell with tags was added but got removed because this transaction got failed.  All
other cells in this memstore are with no tags.  Still just because of this single Cell, we
will think that tags are present and we will write 0 tags length for all the cells when we
flush.  But this should be ok I believe.  The scenario itself is rare that only one cell added
was having tagslength and that only got removed.  Even if it happens, the next compaction
will handle and avoid tagsLength write in resulting new file.
The boolean also we can make non volatile only? 

> Add facility to disable tags after parent goes in
> -------------------------------------------------
>
>                 Key: HBASE-13393
>                 URL: https://issues.apache.org/jira/browse/HBASE-13393
>             Project: HBase
>          Issue Type: Sub-task
>            Reporter: stack
>            Assignee: stack
>         Attachments: HBASE-13393.patch
>
>
> We used to specify 'no tags' by choosing to write files that were version 2.  After parent
goes in, make it so can ask a v3 file not to write tags.



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

Mime
View raw message